DeepSeek V4 Pro ajanlarının güvenliği neden kullandıkları çalışma katmanına bağlı?

Kuruluşlar DeepSeek V4 Pro ajanlarını değerlendirirken yalnızca modeli değil, eksiksiz bir model–harness–görev–ortam yapılandırmasını incelemeli. Web, mobil uygulama, API, OpenAI Responses API veya Codex entegrasyonu üzerinden erişilebilmesi, bir çalışma zamanının modelle iletişim kurabildiğini gösterebilir. Ancak bu durum; istemlerin, araçların, izinlerin, belleğin, yeniden denemelerin ve dış sistemlerdeki yan etkilerin tüm ortamlarda aynı davrandığını kanıtlamaz.

Operasyonel kural basit: Yalnızca kendi güvenlik değerlendirmesinden geçmiş, sürümü ve ayarları sabitlenmiş belirli bir yapılandırmayı onaylayın.

Harness, etkin ajanı nasıl değiştiriyor?

Bir ajan, kullandığı temel modelden ibaret değildir. “Harness” olarak adlandırılan çalışma katmanı; modelin talimatları nasıl aldığına, araçları nasıl seçtiğine, verilere nasıl eriştiğine, hataları nasıl yönettiğine ve dış sistemleri nasıl etkileyebildiğine karar verir.

Risk profilini değiştirebilecek başlıca unsurlar şunlardır:

• sistem istemleri ve adaptörler;
• araç tanımları ve araçların gerçek uygulamaları;
• izin kapsamları ve onay kapıları;
• dosya sistemi kökleri ve ağ erişimi;
• kimlik bilgileri ve kimlik doğrulama kaynakları;
• alt süreçler ve üretilen kodun çalıştırılması;
• yeniden deneme, zaman aşımı ve eşzamanlılık mantığı;
• oturum durumu, özetler, önbellekler ve kalıcı bellek.

Bu nedenle aynı DeepSeek V4 Pro arka ucu, farklı harness’ler veya yürütme ortamları üzerinden kullanıldığında farklı bir risk profili sergileyebilir. Ortak bir API şeması entegrasyon uyumluluğudur; güvenlik sertifikası değildir.

AgentS4D sonuçları ne gösteriyor, ne göstermiyor?

AgentS4D, tek tek model yanıtlarını değil, uçtan uca çalışma zamanı yapılandırmalarını değerlendirdi. Çalışmada dört ajan harness’i ve beş model arka ucuyla 328 risk enjekte edilmiş vaka test edildi; toplam 6.560 yalıtılmış çalıştırmada 4.461 güvensiz sonuç, yani yüzde 68,0 oranı raporlandı. Ayrıca 4.344 çalıştırma, yani yüzde 66,22’si, hem güvensiz hem de görevi tamamlamış olarak değerlendirildi. 13

Buradaki temel ders şu: Görevin başarıyla tamamlanması, yürütmenin güvenli olduğu anlamına gelmez. Bir ajan istenen dosyayı veya çıktıyı üretirken aynı anda yasaklı bir değişiklik yapabilir, hassas verileri yanlış işleyebilir, bir kontrolü aşabilir ya da başka bir güvensiz yan etki oluşturabilir.

Bu oranlar DeepSeek V4 Pro’nun üretim ortamındaki olay oranı olarak sunulmamalı. Çalışma, kontrollü bir sandbox ortamında kasıtlı olarak risk eklenmiş vakalar kullandı ve sonuçları birden fazla model–harness eşleşmesi üzerinden topladı. Gerçek üretim ortamlarında görev dağılımı, güvenlik kontrolleri, düşmanca içerikle karşılaşma olasılığı, korunan varlıklar ve “zarar” tanımı farklı olacaktır. Bulgular, çalışma zamanı güvenliğinin doğrudan ölçülmesi gerektiğine dair kanıttır; her dağıtımın yaşayacağı olayların tahmini değildir. 135

Bir ajanın hatasının etkisini sınırlayın

Güvenlik kontrolleri, model veya araç beklenmedik davransa bile hataların sonuçlarını mümkün olduğunca küçük tutmalıdır.

Özel ve en az yetkili kimlikler kullanın

Ajanlar, ortamlar ve kiracılar için ayrı kimlikler oluşturun. Çalışanların genel amaçlı kimlik bilgilerini, üretim yöneticisi erişimini veya farklı işlerde yeniden kullanılabilecek geniş kapsamlı sırları ajana vermeyin. Her kimliği yalnızca ilgili görevin gerektirdiği kaynak ve işlemlerle sınırlandırın.

Dosya sistemini ve ağı kısıtlayın

• Yalnızca ajana ayrılmış bir çalışma alanını bağlayın.
• İlgisiz yolları sadece gizlemek yerine erişilemez hale getirin.
• Ağ hedeflerini, yöntemleri, portları ve gerektiğinde dışarı gönderilebilecek veri hacmini izin listesine bağlayın.
• Okuma, taslak oluşturma, hazırlık ortamına yazma ve üretim ortamına yazma yetkilerini birbirinden ayırın.
• Sırları bir kimlik bilgisi aracısında veya kısa ömürlü token sisteminde tutun.
• Uzun ömürlü kimlik bilgilerini istemlere, çalışma alanı dosyalarına, ortam değişkenlerine veya araç çıktılarına koymayın.

Silme, yayımlama, ödeme, erişim değişikliği, dağıtım veya dış iletişim gibi yüksek etkili işlemler bir yürütme katmanı politika kontrolünden geçmeli ya da açık bir insan onayı gerektirmelidir.

Yürütme zincirinin tamamını inceleyin

Saldırı yüzeyi yalnızca birinci taraf araçlardan oluşmaz. Alt süreçler, kabuk komutları, üretilen kod, paket kurulumu, uzaktaki araç sunucuları, eklentiler ve beceri kodu da dış sistemlerde yan etki yaratabilir.

Aynı politika bu yolların tamamına uygulanmalı. Özellikle kabuk veya üretilen kodun dosya sistemi, ağ, yetkilendirme, kayıt ve onay kontrollerini aşmasını engelleyin.

Araçları modelin dışında da zorunlu kurallara bağlayın

Model tarafından üretilen bir araç çağrısı güvenilmeyen bir istektir. Yetkilendirme ve güvenlik kurallarını model değil, araç sunucusu uygulamalıdır.

Araç şemalarını dar tutun ve şu kontrolleri kullanın:

• sınırlı enum değerleri ve uzunluk limitleri;
• normalleştirilmiş yollar ve açık kaynak kimlikleri;
• hedef izin listeleri;
• sayfalama ve sonuç boyutu sınırları;
• modelin dışında bağımsız argüman doğrulaması;
• çağrıyı yapan kimlik, kiracı, hedef ve işlem için sunucu tarafında yetkilendirme.

Planlama veya önizleme araçlarını, gerçek etki yaratan araçlardan ayırın. Yıkıcı veya geri alınması zor işlemlerde:

• önizleme ve onay ya da onay token’ı isteyin;
• mümkün olduğunda kalıcı silme yerine geçici silme, karantina veya geri alınabilir iş akışları kullanın;
• idempotency anahtarları talep edin;
• aynı istek yeniden gönderildiğinde ne olacağını önceden tanımlayın;
• yeniden denemelerin aynı etkiyi tekrarlamaması için kalıcı işlem makbuzları döndürün.

Görünüşte geçerli bir JSON araç çağrısı bile yetkisiz bir hedef, tehlikeli bir yol, aşırı geniş bir kapsam veya insan incelemesi gerektiren bir işlem içerebilir.

Durum ve bellek davranışını dağıtımdan önce tanımlayın

Durum bilgisi, riski oturumlar, görevler, kullanıcılar ve ortamlar arasında taşıyabilir. Mesajlar, yüklenen dosyalar, çalışma alanı dosyaları, özetler, araç sonuçları, önbellekler ve kalıcı belleğin yaşam döngüsünü yazılı olarak tanımlayın ve uygulayın.

En azından şu kurallar açık olmalı:

• Yalıtım: Durumu kullanıcı, kiracı, görev ve ortama göre ayırın; oturumlar arasında örtük paylaşım yapılmasına izin vermeyin.
• Saklama: Yaşam süresi, şifreleme, erişim kontrolü ve silme kurallarını belirleyin.
• Sıfırlama: Çalışmalar arasında bağlamı, belleği, çalışma alanı durumunu, kimlik bilgilerini ve önbellekleri temizlemenin belgelenmiş bir yolunu sağlayın.
• Yeniden denemeler ve zaman aşımı: Sayıları ve bütçeleri sınırlayın; yeniden denemeler idempotency’yi korumalı ve yetkileri sessizce genişletmemelidir.
• Eşzamanlılık: Paylaşılan dosyalar, onaylar ve dış işlemler için kilitleme ve çakışma yönetimini tanımlayın.

Durumun sıfırlanma biçimini güvenlik sınırının bir parçası olarak ele alın. Eski talimatlar, kimlik bilgileri veya araç sonuçları yeni bir görevin içine beklenmedik biçimde dönebiliyorsa, yalnızca yanıtları test etmek model yükseltmesi veya istem değişikliğinin oluşturduğu yeni riski kaçırabilir.

Her risk taşıyıcısını güvenilmeyen girdi sayın

İstem enjeksiyonu yalnızca kullanıcının doğrudan mesajından gelmez. Risk taşıyan talimatlar şu kanallara gömülebilir:

• yüklenen belgeler ve depo dosyaları;
• alınan web sayfaları;
• harici beceriler ve eklentiler;
• araç hizmetlerinin yanıtları;
• kalıcı bellek;
• özetler ve önbelleğe alınmış bağlam;
• kullanıcı tarafından sağlanan metin.

Bu içeriği ayrıştırın, etiketleyin ve veri olarak alıntılayın. İçeriğin ajanın yetkisini, politikasını, araç seçimini, kimlik bilgisi kullanımını veya onay gerekliliklerini değiştirmesine izin vermeyin. Bu ayrım yalnızca modelin kötü niyetli talimatları fark etmesine bırakılmamalı; çalışma zamanı tarafından zorunlu kılınmalıdır.

Harness’e özel sürüm öncesi kontrol listesi

Bir dağıtımı onaylamadan önce tam yapılandırmayı dondurun ve kayda geçirin:

1. Model ve yönlendirme: Model kimliği ve sürümü, sağlayıcı rotası, çıkarım ayarları veya çaba seviyesi ve uyumluluk adaptörleri.
2. Harness davranışı: Harness sürümü, sistem istemi, oturum mantığı, yeniden deneme ve zaman aşımı kuralları, alt süreç politikası ve bellek uygulaması.
3. Araçlar ve politikalar: Araç tanımları ve sürümleri, politika sürümleri, onay eşikleri, yetkilendirme mantığı ve araç sunucularının güven sınırları.
4. İzinler: Kimlikler, kapsamlar, dosya sistemi kökleri, ağ hedefleri, kimlik bilgisi kaynakları ve üretime yazma yolları.
5. Durum semantiği: Yalıtım, saklama, sıfırlama, önbellek davranışı, eşzamanlılık ve oturumlar arası sınırlar.
6. Adversarial kapsam: Her risk taşıyıcısı üzerinden istem enjeksiyonu, confused-deputy girişimleri, kimlik bilgisi açığa çıkması, yol geçişi, SSRF veya dışa veri sızdırma istismarı, kötü niyetli araç yanıtları, yeniden deneme kaynaklı tekrarlar, bellek zehirleme ve onay atlatma testleri.
7. Kanıt: Sabit bir çalıştırma kimliği altında istem ve politika sürümleri, araç çağrıları ve sonuçları, onaylar, politika kararları, çalışma alanı farkları, dışarı yapılan istekler, kullanılan kimlik, nihai çıktılar, tamamlanma sonucu ve güvenlik sonucu.

Tamamlanma ile güvenliği ayrı ayrı puanlayın. Doğru nihai çıktı, güvensiz bir yan etkiyi telafi etmemelidir; AgentS4D sonuçlarının merkezindeki ders budur. 12

Yapılandırma değiştiğinde testleri tekrarlayın

Onaylanan hedef, kalıcı bir “DeepSeek V4 Pro ajanı” etiketi değil, sürümü sabitlenmiş belirli bir yapılandırmadır. Aşağıdaki unsurlardan herhangi biri değiştiğinde yapılandırmaya özel test paketini yeniden çalıştırın:

• model veya sağlayıcı rotası;
• çıkarım ayarları veya çaba seviyesi;
• sistem istemi veya adaptör;
• harness ya da oturum mantığı;
• araçlar veya uzaktaki araç sunucuları;
• izin ve onay politikaları;
• kimlik bilgisi yönlendirmesi;
• bellek, yeniden deneme, zaman aşımı veya eşzamanlılık davranışı;
• ağ ya da dosya sistemi sınırları.

Bu yaklaşım, çalışma zamanı güvenliğini model kalitesi hakkındaki geniş bir varsayım olmaktan çıkarır ve gerçek dünyada etki yaratabilecek tam ortama bağlı, ölçülebilir bir sürüm kararına dönüştürür.