Jailbreak Savunması
Neden Tek Bir Sistem Prompt'u ile Çözülmez?

Sistem promptu ne yapar, ne yapmaz?

Sistem promptu, modelin davranışını yönlendiren ana talimat katmanıdır. Modelin nasıl konuşacağını, hangi rolü üstleneceğini, hangi sınırları önemseyeceğini ve hangi tür isteklere cevap vermeyeceğini tarif eder. Bu yüzden jailbreak savunmasında önemlidir. Ama sistem promptu bir erişim kontrolü, veri koruma mekanizması veya işlem onay sistemi değildir.

Bir uygulama, hassas veriyi modele verdiğinde sistem promptuna "bunu paylaşma" yazmak veri güvenliği değildir. Bir agent ödeme aracına bağlıysa sistem promptuna "yetkisiz ödeme yapma" yazmak işlem güvenliği değildir. Bunlar model davranışını iyileştirir, ama kararın uygulama tarafında kontrol edilmesi gerekir.

Bu ayrımı yapmayan ekipler, promptu güvenlik duvarı gibi kullanmaya başlar. O noktada savunma metinsel bir temenniye dönüşür. Güvenlik ise temenni değil, zorlayıcı kontroldür.

Yanlış güven hissi

Jailbreak savunmasındaki en yaygın hata, modelin sistem promptuna uyduğu birkaç testten sonra sistemin güvenli kabul edilmesidir. Bu kısa vadede rahatlatıcıdır; ama üretim ortamında saldırgan tek bir talimat biçimiyle gelmez. Rol yapma, çeviri, özetleme, format dönüştürme, bağlam karıştırma, dolaylı veri, uzun konuşma ve tool çağrısı gibi farklı yolları dener.

Daha sert sistem promptu yazmak bazı saldırıları durdurabilir. Ama saldırı yüzeyi yalnızca modelin "ne söyleyeceği" değilse, savunma da yalnızca modelin "ne söylememesi gerektiği" üzerine kurulamaz. LLM uygulaması veri okuyor, araç çağırıyor, bellek tutuyor veya başka sisteme çıktı veriyorsa, jailbreak savunması uygulama güvenliği disiplinine dönüşür.

Altı savunma katmanı

1. Politika katmanı

Önce neyin yasak, neyin sınırlı, neyin onay gerektirdiği açık yazılmalıdır. Bu politika yalnızca sistem promptunda değil, uygulama kodunda ve ürün kararlarında da karşılık bulmalıdır. Örneğin bir kurum içi asistan müşteri verisini özetleyebilir ama dışarıya e-posta atamaz; bu bir prompt cümlesi değil, ürün politikasıdır.

2. Bağlam ayrıştırma

Modelin gördüğü her metin talimat değildir. RAG dokümanı, e-posta, PDF, web sayfası veya kullanıcı yüklemesi veri olarak işaretlenmeli; bu verinin içindeki talimatların sistem talimatı gibi davranması engellenmelidir. Bağlam ayrıştırma yapılmadığında dolaylı jailbreak denemeleri etkili hale gelir.

3. Input ve output kontrolü

Girdi tarafında saldırı niyeti, çıktı tarafında politika ihlali ve hassas veri sızıntısı kontrol edilir. Bu kontroller yalnızca kelime listesiyle yapılırsa zayıf kalır; niyet, bağlam, kullanıcı rolü ve işlem etkisi birlikte değerlendirilmelidir. Yine de basit kurallar küçümsenmemelidir: bazı riskler hızlı ve deterministik kontrollerle daha iyi yakalanır.

4. Tool ve yetki sınırı

Model bir aracı çağırabiliyorsa, jailbreak savunmasının en kritik katmanı burasıdır. Hangi araç çağrılabilir, hangi parametrelerle çağrılabilir, hangi kullanıcı yetkisiyle çağrılabilir ve hangi durumda insan onayı gerekir? Bu sorular sistem promptunda değil uygulama tarafında cevaplanmalıdır.

5. Telemetri ve alarm

Jailbreak girişimi yalnızca engellenecek bir olay değildir; öğrenilecek bir sinyaldir. Kullanıcı mesajı, model cevabı, RAG kaynağı, tool çağrısı, çıktı filtresi, karar skoru ve oturum bilgisi birlikte kaydedilmelidir. Aksi halde olay yaşandığında "ne oldu?" sorusunun cevabı eksik kalır.

6. Olay müdahalesi

Bir jailbreak denemesi başarılı olursa ne yapılacak? Oturum durdurulacak mı, bellek temizlenecek mi, RAG dokümanı karantinaya alınacak mı, tool çağrıları geri alınacak mı, kullanıcı hesabı kısıtlanacak mı? Bu kararlar olaydan önce yazılmalıdır. Olay sırasında playbook yazılmaz.

Fazla engelleme de güvenlik sorunudur

Jailbreak savunmasında yalnızca saldırıyı kaçırmak değil, masum kullanıcıyı sürekli engellemek de sorundur. Kurum içi ekipler, işlerini aksatan güvenlik katmanlarını hızla devre dışı bırakır. Bu nedenle savunma tasarımı iki hedefi birlikte taşımalıdır: saldırı yüzeylerinden etkilenmemek ve normal iş akışını gereksiz yere bozmamak.

Bu denge için kararlar kategorilere ayrılmalıdır: bazı istekler doğrudan engellenir, bazıları güvenli formata dönüştürülür, bazıları uyarı ile devam eder, bazıları insan onayına gider, bazıları yalnızca loglanır. Her şeyi bloklamak kolay görünür, ama üretim ortamında sürdürülebilir değildir.

Operasyona bağlanmayan savunma yaşamaz

Jailbreak savunması bir kez yazılıp unutulacak bir prompt değildir. Yeni model sürümleri, yeni kullanıcı davranışları, yeni doküman türleri ve yeni tool entegrasyonları savunmayı sürekli değiştirir. Bu yüzden savunma yaklaşımı operasyonla bağlanmalıdır: hangi metrikler izleniyor, hangi alarmlar üretiliyor, hangi bulgular ürüne geri dönüyor?

Blue team tarafı burada devreye girer. Güvenlik ekibi yalnızca kırılan örneği bilmekle yetinmez; bu örneğin hangi logda görüneceğini, hangi alarmı tetikleyeceğini ve hangi müdahale adımını başlatacağını da bilir. Savunmanın canlı kalması bu döngüye bağlıdır.

Kurumsal kontrol listesi

• Sistem promptu ile uygulama politikası birbirinden ayrıldı mı?
• RAG ve harici veri kaynakları talimat değil veri olarak işaretleniyor mu?
• Tool çağrıları izin listesi ve parametre doğrulamasıyla sınırlandırılıyor mu?
• Kritik eylemler insan onayına bağlandı mı?
• Çıktı filtresi yalnızca kelime listesine değil bağlama da bakıyor mu?
• Başarılı ve başarısız jailbreak denemeleri loglanıyor mu?
• Loglar kişisel veri ve sır yönetimi açısından kontrol altında mı?
• Bir jailbreak olayı için hazır müdahale playbook'u var mı?
• Savunma düzenli red team testiyle güncelleniyor mu?

Sonuç

Sistem promptu jailbreak savunmasının önemli bir parçasıdır, ama tek başına savunma değildir. Güvenlik, modelin uyması beklenen metinden çok uygulamanın zorunlu kıldığı kontrollere dayanır.

Sağlam yaklaşım; politika, bağlam ayrıştırma, input/output kontrolü, tool yetkisi, telemetri ve olay müdahalesini birlikte kurar. LLM uygulamasını üretime taşıyan kurumlar için gerçek savunma bu katmanlı yapıyla başlar.