Tehdit Modelini Tool Sınırlarından Başlatın

AI agent güvenliği yalnızca zararlı prompt’ları engellemekten ibaret değildir. Modelin hangi aracı, hangi veriyle, hangi kullanıcı adına ve hangi yan etkiyle çağırabildiği açıkça tanımlanmalıdır. Her tool için yazılı bir tehdit modeli oluşturun:

• Hangi kaynaklara erişebilir? Erişim kapsamı en az ayrıcalık ilkesiyle sınırlandırılmış mı?
• Araç yalnızca okuma mı yapıyor, yoksa kayıt silme, ödeme başlatma veya mesaj gönderme gibi kalıcı etki mi oluşturuyor?
• Modelin ürettiği parametreler sunucu tarafında yeniden doğrulanıyor mu?
• Kullanıcı girdisi, RAG belgesi, e-posta veya web içeriği talimat olarak yorumlanabilir mi?
• İşlem başarısız olduğunda sistem güvenli biçimde duruyor mu, yoksa varsayılan bir yetkiyle devam mı ediyor?

Okuma, yazma ve silme işlemlerini ayrı yetki sınıfları olarak tanımlayın. Yüksek etkili araçlarda kullanıcı onayı, bağımsız politika servisi, işlem tutarı veya kayıt kapsamı sınırı ve idempotency anahtarı bulunmalıdır. Modelin “onaylandı” demesi gerçek yetkilendirme kanıtı değildir; yetki, kimlik ve kapsam sunucu tarafında doğrulanmalıdır.

Tool’ları mümkünse ayrı servis hesapları, kısa ömürlü kimlik bilgileri, ağ politikaları ve sandbox sınırlarıyla çalıştırın. Bir aracın çıktısını sonraki araca doğrudan yetki kanıtı olarak aktarmayın. Her çağrıda kullanıcı, tenant, kaynak kapsamı ve işlem amacı yeniden kontrol edilmelidir.

Prompt Injection’a Karşı Katmanlı Savunma

Prompt injection savunmasını tek bir sistem mesajına bırakmayın. Güvenilmeyen içerik ile politika ve araç talimatlarını mimari olarak ayırın. RAG dokümanları, e-postalar ve web sayfaları veri olarak işaretlenmeli; bu kaynaklardaki komutlar yürütülebilir talimat kabul edilmemelidir.

Uygulanabilir bir akış şu şekilde kurulabilir:

• Girdiyi kaynağına göre sınıflandırın: kullanıcı talimatı, güvenilmeyen belge, araç çıktısı veya sistem politikası.
• Tool çağrısından önce bağımsız bir politika kontrolü çalıştırın.
• Araç şemasında izin verilen alanları, veri tiplerini, uzunlukları ve değer aralıklarını zorunlu kılın.
• Harici içeriği model talimatlarıyla aynı ayrıcalıklı kanalda taşımayın.
• Şüpheli veya belirsiz durumda çağrıyı durdurun; güvenli ret ya da insan incelemesi yoluna geçin.

Örneğin destek agent’ı, bir e-posta gövdesindeki “tüm kayıtları dışa aktar” ifadesini kullanıcı yetkisi saymamalıdır. Bu durum doğrudan ve dolaylı injection senaryosu olarak eval setine eklenmelidir. Savunma yalnızca metin sınıflandırmasına değil, dışa aktarma kapsamının sunucu tarafında doğrulanmasına da dayanmalıdır.

Eval Setini Saldırı ve Fayda Dengesiyle Kurun

Eval yalnızca doğru yanıtı ölçmemeli; güvenli ret, doğru tool seçimi, parametre doğruluğu ve yetki sınırlarına uyumu da değerlendirmelidir. Testleri şu boyutlarda etiketleyin:

• Injection türü: doğrudan, dolaylı, çok adımlı veya araç çıktısı üzerinden.
• Etkisi: veri sızıntısı, yetkisiz işlem, yanlış yönlendirme veya hizmet kesintisi.
• Beklenen davranış: reddetme, güvenli özetleme, onay isteme veya insan incelemesi.
• Sonuç: politika ihlali, yanlış pozitif, yanlış negatif ve gereksiz ret.
• Şiddet: düşük, orta, yüksek veya kritik.

Her testte nihai metnin yanında seçilen aracın, parametrelerin, politika kararının ve gerçek yan etkinin kaydını değerlendirin. Kritik bir veri dışa aktarma senaryosunda başarı kriteri ikna edici bir açıklama değil, yetkisiz çağrının hiç gerçekleşmemesidir. Ölçülebilir eşikler belirleyin: kritik işlemlerde yetkisiz çağrı oranı sıfır olmalı; yanlış ret oranı ise görev ve risk sınıfına göre ayrıca izlenmelidir.

Test setini sabit bırakmayın. Üretim olaylarından anonimleştirilmiş örneklerle genişletin; kişisel ve kurumsal bilgileri maskeleyin, gizli değerleri sentetik kayıt veya canary değerlerle değiştirin. Üretim verisini doğrudan eval ortamına taşımayın.

Gözlemlenebilirlik ve Gizliliği Birlikte Tasarlayın

Güvenlik telemetrisi olmadan guardrail’lerin etkisi ölçülemez. Ancak ham prompt ve araç çıktılarının sınırsız loglanması yeni bir veri sızıntısı yaratabilir. Log tasarımında veri minimizasyonu, rol tabanlı erişim ve sınırlı saklama süresi temel alınmalıdır.

Asgari ölçüm alanları şunlar olabilir:

• İstek ve trace kimliği; doğrudan kullanıcı kimliği yerine takma ad.
• Model, politika ve tool sürümü.
• Politika sonucu, ret nedeni kategorisi ve insan onayı gerekip gerekmediği.
• Gecikme, hata türü, token tüketimi ve tool çağrısı sayısı.
• Hassas verinin kendisi yerine türü, konumu ve tespit sonucu.

İzleme panolarında injection reddetme oranındaki ani düşüşü, tenant başına olağandışı çağrıları, başarısız yetkilendirme artışını, yüksek etkili işlemlerde onay atlamalarını ve guardrail sonrası tekrarlanan denemeleri izleyin. Ham içerik zorunluysa erişimi sınırlandırın, denetim kaydı tutun ve saklama süresini önceden belirleyin.

Üretime Alma ve Geri Dönüş Planı

Yeni model, prompt veya guardrail doğrudan tüm trafiğe açılmamalıdır. Pasif gözlem, sınırlı trafik, kademeli yayılım ve tam dağıtım aşamalarını ayrı ayrı değerlendirin. Her aşamada güvenlik regresyonlarını, görev başarımını, gecikmeyi ve maliyeti birlikte karşılaştırın.

• Kritik tool’larda fail-closed davranış doğrulandı mı?
• Politika servisi kullanılamadığında yetki varsayılan olarak reddediliyor mu?
• Yeni modelin çözemediği kritik saldırı sınıfı var mı?
• Rollback, tool devre dışı bırakma ve insan incelemesine yönlendirme test edildi mi?
• Olay müdahalesi için sahiplik, eşik ve iletişim adımları tanımlı mı?

En güçlü guardrail, modeli iyi niyetli göstermeye çalışan tek bir metin değil; yetkiyi modelden ayıran, tool’ları dar kapsamda çalıştıran, güvenilmeyen veriyi izole eden, davranışı ölçen ve gerektiğinde güvenli biçimde duran sistem tasarımıdır.