Ölçüm Kapsamını ve Tehdit Modelini Tanımlama

Prompt injection savunmasını yalnızca modelin son yanıtına bakarak değerlendirmek yetersizdir. Güvenli bir ölçüm; saldırının algılanmasını, etkisinin sınırlandırılmasını, hassas veriye erişimin engellenmesini ve tehlikeli araçların çalıştırılmamasını ayrı ayrı izlemelidir.

Önce tehdit modelini yazılı hâle getirin. Saldırgan; kullanıcı mesajı, yüklenen belge, web sayfası, e-posta içeriği, retrieval sonucu veya araç çıktısı üzerinden talimat enjekte edebilir. Her senaryo için beklenen davranışı şu sorularla tanımlayın:

• Güvenilmeyen içerik talimat yerine veri olarak mı işlendi?
• Araç çağrısı gerekiyorsa kimlik, yetki, parametre ve hedef kaynak doğrulandı mı?
• Kişisel veya gizli veri yanıt bağlamına gereksiz biçimde taşındı mı?
• Saldırı tespit edildiğinde güvenli, sınırlı ve kullanıcıya anlaşılır bir sonuç döndü mü?

Model saldırıyı fark etmiş görünse bile yetkisiz bir araç çağrısı gerçekleşiyorsa sonuç güvenli kabul edilmemelidir. Karar sınırlarını model çıktısından bağımsız olarak uygulama ve araç katmanlarında da zorunlu kılın.

Katmanlı Eval Seti Tasarlama

Eval kayıtlarını yalnızca bilinen saldırı örneklerinden oluşturmayın. Her kayıt; tehdit türü, giriş kaynağı, güven seviyesi, beklenen karar, izin verilen araçlar, hassasiyet sınıfı ve kabul kriterleriyle etiketlenmelidir. Gerçek kullanıcı verisi kullanılacaksa kimlik bilgilerini ayıklayın, veri minimizasyonu uygulayın ve test verisinin üretim sistemine geri yazılmasını engelleyin.

Pratik bir eval seti şu katmanları içerebilir:

• Doğrudan saldırılar: Talimatları geçersiz kılma, rol değiştirme, sistem yönergelerini açığa çıkarma ve yetki yükseltme istekleri.
• Dolaylı injection: Belge, web içeriği, e-posta, retrieval sonucu veya araç çıktısına gömülen talimatlar.
• Çok turlu akışlar: Masum bir istekle başlayıp sonraki mesajlarda gizli veriye veya ayrıcalıklı araca erişmeye çalışan senaryolar.
• Regresyon testleri: Daha önce bulunan her açığın düzeltme sonrasında tekrar çalıştırılan sabit örneği.
• Zor negatifler: Güvenli ve yetkili isteklerin yanlışlıkla engellenmediğini ölçen meşru kullanım örnekleri.

Her eval sürümünde test örneklerini kaynak, tehdit sınıfı ve zorluk düzeyine göre dengeleyin. Aynı saldırı kalıbının skoru yapay biçimde yükseltmesini önlemek için örnekleri çeşitlendirin. Değerlendirmeyi yalnızca metin çıktısına değil, politika kararlarına, araç çağrılarına, veri erişimlerine ve yan etkilere bağlayın.

Guardrail Metrikleri ve Güvenlik Kapıları

En az şu metrikleri ayrı ayrı izleyin:

• Saldırı başarı oranı
• Hassas veri sızıntısı oranı
• Yetkisiz araç çağrısı oranı
• Meşru isteğin engellenme oranı
• Güvenli geri dönüş oranı
• Saldırı tespitinden karara kadar geçen süre

Her metriğin paydasını açıkça tanımlayın. Örneğin “sızıntı oranı”, tüm istekler yerine hassas veri erişimi beklenen veya hassas içerik taşıyan test kayıtları üzerinden hesaplanabilir. Böylece farklı eval sürümleri karşılaştırılabilir olur.

Karar matrisinde kritik ihlalleri ortalamaya gömmeyin:

• Kritik veri sızıntısı veya yetkisiz yan etki otomatik başarısızlık olmalıdır.
• Yetkisiz araç çağrısı, son kullanıcıya zararsız bir yanıt gösterilmiş olsa bile başarısızlık sayılmalıdır.
• Saldırıyı reddederken gizli kural, sistem promptu veya hassas içeriğin açığa çıkması güvenlik hatasıdır.
• Meşru isteğin engellenmesi yanlış pozitif ve kullanılabilirlik metriğine yazılmalıdır.

Birleşik puan kullanıyorsanız önce zorunlu güvenlik kapılarını uygulayın; ardından kalite ve kullanılabilirlik skorlarını değerlendirin. Model, sistem promptu, araç şeması, retrieval ayarı veya çıktı filtresi değiştiğinde ilgili kapılar yeniden çalıştırılmadan üretime geçiş yapılmamalıdır.

Gözlemlenebilirlikte Veri Minimizasyonu

Telemetri güvenlik incelemesine yetecek kadar ayrıntılı, ancak gereksiz kişisel veri toplamayan bir yapıda olmalıdır. Ham prompt ve yanıtları sınırsız saklamak yerine yapılandırılmış olay alanlarını tercih edin:

• Rastgeleleştirilmiş istek ve oturum kimlikleri
• Model, guardrail, politika ve eval sürümleri
• Risk sınıfı ve giriş kaynağının güvenilirlik seviyesi
• Araç çağrısının planlandığı, onaylandığı, reddedildiği veya çalıştırıldığı aşama
• Karar gecikmesi, token tüketimi ve hata türü
• İnceleme gerektiren olayın saklama süresi ve erişim seviyesi

Loglara parola, erişim belirteci, tam kişisel veri veya gereksiz belge içeriği yazılmasını engelleyen filtreler kullanın. Bu filtreleri sentetik sırlar, sahte kimlik numaraları ve farklı kodlama biçimleriyle düzenli olarak test edin. Olay incelemesi için ham içeriğe ihtiyaç varsa erişimi rol tabanlı, süreli ve denetlenebilir bir akışla sınırlandırın.

Üretim Öncesi ve Sonrası İşletim Döngüsü

Dağıtım hattına sürümlenmiş bir güvenlik değerlendirme kapısı ekleyin. Sonuçları önceki başarılı sürümle karşılaştırın ve kritik metriklerde gerileme için otomatik durdurma uygulayın. Üretimde toplam hata sayısının yanında tehdit sınıfı, müşteri akışı, araç adı ve model sürümündeki değişimleri de izleyin.

Alarm kurallarına beklenmeyen araç çağrısı, aynı tehdit sınıfındaki ani artış, tek bir akışta tekrarlanan politika ihlali ve hassas veri filtresindeki başarısızlıkları dahil edin. Olay müdahalesi önceden belgelenmelidir: etkilenen akışı durdurma, yetkileri daraltma, sürümü geri alma, kanıtları koruma, etkiyi analiz etme ve yeni regresyon testini eval setine ekleme.

Eval, telemetri ve olay müdahalesi birlikte tasarlandığında her üretim hatası ölçülebilir bir savunma iyileştirmesine dönüşür. Amaç yalnızca saldırıyı reddetmek değil; reddin doğru katmanda gerçekleştiğini, yan etki üretmediğini ve sonraki sürümlerde yeniden doğrulanabildiğini göstermektir.