Kapsamı ve Tehdit Modelini Tanımlayın

Üretim öncesi güvenlik değerlendirmesi yalnızca modelin doğru yanıt verip vermediğini ölçmemelidir. Uygulamanın hangi verilere eriştiği, hangi araçları çağırabildiği ve çıktının hangi sistemlere aktarıldığı açıkça belgelenmelidir. Tehdit modelini şu sorularla başlatın:

• Kullanıcı girdisi, web sayfası, e-posta, dosya veya RAG dokümanı güvenilmeyen içerik olarak mı kabul ediliyor?
• Modelin araç çağrıları para harcama, kayıt silme, mesaj gönderme veya yetki değiştirme gibi etkiler doğuruyor mu?
• Hassas veri prompt, bağlam, log veya hata mesajına istemeden taşınabilir mi?
• Bir saldırgan sistem talimatını değiştiremese bile modeli riskli bir araca yönlendirebilir mi?

Her araç için izin verilen parametreleri, kullanıcı onayı gerektiren işlemleri ve tamamen yasaklanan eylemleri ayrı tanımlayın. Model çıktısını doğrudan yetki olarak kullanmayın; araç adı, parametreler, oturum yetkisi ve kaynak erişimi sunucu tarafında bağımsız politika kontrollerinden geçsin.

Prompt Injection Savunmasını Katmanlı Tasarlayın

Prompt injection savunması tek bir sistem talimatına veya “talimatları görmezden gel” ifadesine bırakılmamalıdır. Güvenilmeyen içerik talimat değil veri olarak işaretlenmeli; sistem politikası, kullanıcı isteği, alınan doküman ve araç çıktısı birbirinden ayrılmalıdır. Bununla birlikte asıl güvenlik sınırı model metni değil, uygulama mimarisidir.

Önerilen akış:

• Girdileri sınıflandırın ve güven seviyelerini açıkça taşıyın.
• Araçları allowlist ile sınırlandırın; ad ve parametreleri şema doğrulamasından geçirin.
• Riskli işlemlerde açık kullanıcı onayı, oturum yetkisi ve gerekirse ikinci bir kontrol servisi kullanın.
• RAG içeriğindeki “önceki talimatları yok say” benzeri metinleri güvenilir politika kabul etmeyin.
• Başarısız veya şüpheli denemeleri güvenlik olayı olarak izleyin; yalnızca yanıtı değiştirmekle yetinmeyin.

Değerlendirmeye doğrudan saldırıların yanında dolaylı injection senaryoları da ekleyin: kötü amaçlı bir dokümanın özetletilmesi, araç çıktısına gömülü komutlar ve ayrı ayrı masum görünen adımların birleşerek riskli eyleme dönüşmesi. Çok adımlı akışlarda her adımın yetki sınırını yeniden kontrol edin.

Ölçülebilir Eval Seti ve Saldırı Kapsamı

Eval seti başarılı demoların toplamı olmamalıdır. Her kayıt; senaryo türü, tehdit kategorisi, risk seviyesi, beklenen davranış, kabul kriteri ve gözlenen sonucu içermelidir. Prompt geliştirmede kullanılan örnekleri üretim regresyon setinden ayırın; aksi halde ezberleme ve veri sızıntısı fark edilmeyebilir.

Asgari metrikler şunlardır:

• Güvenli reddetme oranı: Yasaklı istekte eylemsiz ve anlaşılır yanıt verme oranı.
• Yanlış pozitif oranı: Meşru isteklerin gereksiz engellenme oranı.
• Araç politika ihlali: Yetkisiz araç, geçersiz parametre veya onaysız kritik işlem sayısı.
• Hassas veri sızıntısı: Çıktı ve loglarda beklenmeyen kişisel, gizli veya sistem içi veri görülme oranı.
• Dayanıklılık: Farklı dil, yazım hatası, uzun bağlam ve çok adımlı varyasyonlarda tutarlılık.

Dağıtım öncesi sabit regresyon setini çalıştırın. Yeni bulguları ayrı bir challenge setine ekleyin. Her başarısızlığı yalnızca prompt değişikliğiyle kapatmak yerine; model davranışı, yetkilendirme eksikliği, araç doğrulaması, veri sınıflandırması veya gözlemlenebilirlik açığı olarak kök nedene göre sınıflandırın. Kritik metrikler için örneğin “araç politika ihlali sıfır”, hassas veri sızıntısı için ise tanımlı bir üst sınır ve otomatik dağıtım durdurma koşulu belirleyin.

Gizlilik, Gözlemlenebilirlik ve Olay Analizi

Gözlemlenebilirlik güvenlik için gereklidir; ancak ham prompt ve yanıtları sınırsız saklamak yeni bir veri riski oluşturur. Log politikasında maskelenecek alanlar, saklama süresi, erişim rolleri ve silme prosedürü önceden belirlenmelidir.

• Kimlik, iletişim bilgisi, erişim belirteci ve finansal verileri loglamadan önce maskeleyin veya çıkarın.
• Prompt, araç çağrısı, politika kararı, model sürümü ve gecikmeyi korelasyon kimliğiyle ilişkilendirin; hassas içeriği gereksiz yere kopyalamayın.
• Model sağlayıcısına gönderilen verinin kapsamını ve saklama davranışını doğrulayın.
• Eval sonuçlarını kullanıcı verisinden ayırın ve erişimi en az yetki ilkesiyle sınırlayın.
• Log bütünlüğünü, erişim kayıtlarını ve alarm üretimini düzenli olarak test edin.

Olay incelemesi için istek sınıfı, risk kararı, kullanılan araç, politika sonucu, insan onayı gerekip gerekmediği, hata türü ve sürüm bilgisi yeterli olmalıdır. Saldırı içeriğini yeniden üretmeden analiz yapılabilmesi için hassas metin yerine maskeleme, özetleme veya içerik parmak izi kullanın.

Guardrail’leri Üretimde Doğrulayın

Guardrail başarısını “model çoğu zaman reddetti” şeklinde değerlendirmeyin. Güvenlik, faydalılık ve gecikme için ölçülebilir eşikler; ihlal, ret oranı ve anomali alarmları tanımlayın. Kritik işlemlerde fail-closed davranış kullanın: doğrulama servisi çalışmıyorsa işlem gerçekleşmemeli, yalnızca sınırlı ve güvenli bir yanıt dönmelidir.

Canlıya geçiş kontrolü:

• Sabit eval setinde güvenlik ve faydalılık eşiklerini karşılaştırın.
• Kimlikten arındırılmış üretim örnekleriyle yeniden test yapın.
• Alarm eşiklerini, olay önem seviyelerini ve geri alma prosedürünü belgeleyin.
• Model, prompt, araç şeması ve politika değişikliklerini sürümlendirin.
• Kırmızı takım bulgularını regresyon testine dönüştürün.
• Aşamalı dağıtım, trafik bölümlendirme ve hızlı geri alma mekanizması kullanın.

En güvenli tasarımda model nihai otorite değildir. Model önerir; kimlik doğrulama, yetkilendirme, veri erişimi ve kritik işlem onayı deterministik servisler tarafından uygulanır. Böylece yeni bir model davranışı veya injection varyasyonu, uygulamanın güvenlik sınırını tek başına aşamaz.