LLM Uygulamalarında
Prompt Injection Tehdit Modeli

Yanlış tanım: bu sadece prompt problemi değil

Prompt injection çoğu zaman "modele kötü talimat yazmak" gibi anlatılıyor. Bu tanım başlangıç için anlaşılır olabilir, ama kurumsal bir LLM uygulamasını korumak için yetersizdir. Çünkü üretimde çalışan sistemlerde model nadiren tek başına durur. Modelin önünde kullanıcı arayüzü, arkasında veri tabanı, yanında RAG katmanı, kimi zaman tool calling, bazen bellek, çoğu zaman da başka sistemlere akan bir çıktı vardır.

Bu yüzden doğru soru "model bu talimata kanar mı?" değildir. Daha doğru soru şudur: Bu uygulamada güven sınırı nerede başlıyor, nerede bitiyor ve model hangi noktada dış veriyi talimat gibi yorumlayabilir?

Bir chatbot yalnızca bilgi veriyorsa risk sınırlıdır. Aynı chatbot müşteri verisine erişiyor, sözleşme özetliyor, destek talebi açıyor, e-posta gönderiyor veya ödeme aracına bağlanıyorsa artık prompt injection bir içerik problemi değil, uygulama güvenliği problemidir. Bu noktada klasik güvenlik refleksi geri gelir: varlıklar, yetkiler, giriş noktaları, güven sınırları ve denetim kayıtları.

Güven sınırlarını çizmek

LLM uygulamasında tehdit modeli çıkarmanın ilk adımı, sistemdeki güven sınırlarını görünür hale getirmektir. Kullanıcıdan gelen metin güvenilmezdir. Harici web sayfaları güvenilmezdir. E-postalar, PDF'ler, dokümanlar, ticket içerikleri ve RAG deposuna giren tüm parçalar güvenilmezdir. Modelin ürettiği tool parametreleri de güvenilmezdir; çünkü o parametreler saldırgan tarafından yönlendirilmiş olabilir.

Bu basit ayrım yapılmadığında savunma yanlış yere kurulur. Sistem promptuna uzun bir "güvenlik talimatı" yazılır ve bunun uygulamayı koruyacağı düşünülür. Oysa sistem promptu yalnızca model davranışını yönlendirir; uygulama seviyesinde yetki kontrolü yerine geçmez. Bir kullanıcıya yetkisi olmayan veriyi göstermemek, modelin iyi niyetine bırakılamaz. Bir ödeme aracının hangi miktarda, hangi hesaba işlem yapabileceği prompt ile değil, uygulama politikasıyla sınırlandırılır.

Sağlam bir tehdit modeli, modelin etrafındaki her kanalı ayrı ayrı işaretler: kullanıcı girdisi, sistem promptu, geliştirici promptu, RAG bağlamı, tool tanımları, tool parametreleri, bellek, çıktı filtresi ve log hattı. Her kanal için iki soru sorulur: Buradan gelen içerik talimat olarak yorumlanabilir mi? Buradan gelen içerik bir eylemi tetikleyebilir mi?

Altı saldırı yüzeyi

1. Kullanıcı girdisi

En görünür yüzey doğrudan kullanıcı mesajıdır. Saldırgan modeli rol değiştirmeye, önceki talimatları yok saymaya, sistem içeriğini açıklamaya veya güvenlik politikasını gevşetmeye zorlar. Bu yüzey hâlâ önemlidir, ama tek başına tüm resmi anlatmaz. Sadece kullanıcı mesajını filtreleyen sistemler, daha derinden gelen saldırıları kaçırır.

2. Harici veri ve RAG bağlamı

RAG sistemleri modeli dış dokümanlarla besler. Bu doküman bir sözleşme, destek kaydı, web sayfası, PDF, wiki notu veya e-posta olabilir. Eğer bu veri içinde modele yazılmış bir talimat varsa, model bunu "okunacak veri" yerine "uygulanacak emir" gibi yorumlayabilir. Dolaylı prompt injection riskinin özü budur.

Burada savunmanın yalnızca metin temizleme olmadığını görmek gerekir. Kaynağın güvenilirliği, dokümanın kim tarafından yüklendiği, hangi kullanıcıya hangi parçanın gösterildiği, retrieval sonucunun hangi puanla geldiği ve modelin bu parçayı hangi bağlamda kullandığı birlikte izlenmelidir.

3. Tool calling ve fonksiyon parametreleri

Model bir aracı çağırabiliyorsa, prompt injection artık eyleme dönüşebilir. Saldırganın amacı yalnızca modelden bir cevap almak değil, yanlış aracı yanlış parametreyle çalıştırmak olabilir. E-posta gönderme, dosya okuma, veritabanı sorgulama, ödeme başlatma, ticket açma veya kod çalıştırma gibi yetkiler bu yüzeyi kritik hale getirir.

Bu yüzden modelin ürettiği tool parametresi, kullanıcı girdisi kadar şüpheli kabul edilmelidir. Model "bu kullanıcı bu veriye erişebilir" dedi diye sistem erişim vermemelidir. Yetki kontrolü, model çıktısından bağımsız ve uygulama tarafında yapılmalıdır.

4. Bellek ve oturum durumu

LLM uygulamaları konuşma geçmişini, kullanıcı tercihlerini veya önceki görevleri bellekte tutabilir. Bu bellek doğru yönetilmezse saldırı kalıcı hale gelir. Bir oturumda verilen kötü talimat sonraki oturuma sızabilir; bir kullanıcıya ait bağlam başka kullanıcıya taşınabilir; masum görünen bir tercih kaydı sonraki kararları etkileyebilir.

Bellek katmanı için temel kural şudur: her kayıt türünün amacı, süresi ve erişim sınırı açık olmalıdır. Modelin belleğe yazdığı şeyler denetlenmeli, kritik kararları etkileyen bellek kayıtları ayrıca onaylanmalıdır.

5. Çıktıyı tüketen sistemler

Bazı uygulamalarda model çıktısı doğrudan başka bir sisteme gider. Bir rapor üretir, otomatik e-posta taslağı oluşturur, SQL üretir, komut satırı önerir, müşteri temsilcisi ekranına aksiyon yazar. Bu çıktıyı başka bir sistem güvenilir kabul ederse, prompt injection dolaylı olarak ikinci sisteme taşınır.

Bu nedenle çıktı yalnızca kullanıcıya gösterilen metin değildir; downstream sistemlerin tükettiği bir veri paketidir. Format doğrulaması, izin verilen aksiyon listesi, insan onayı ve kayıt mekanizması bu katmanda devreye girer.

6. Log ve gözlemlenebilirlik hattı

Log hattı çoğu zaman savunma unsuru gibi görülür, ama yanlış tasarlanırsa yeni risk üretir. Promptlar, cevaplar, kişisel veriler ve tool parametreleri ham halde kaydediliyorsa, olay araştırması için kurulan yapı ikinci bir veri sızıntısı kaynağına dönüşebilir. Loglar hem güvenlik ekibinin görebileceği kadar detaylı hem de kişisel veri ve sır yönetimi açısından kontrollü olmalıdır.

Red team testi nasıl başlamalı?

LLM red team testi, rastgele jailbreak denemeleriyle başlamamalıdır. Önce uygulamanın yapısı çıkarılır. Model hangi rollerde konuşuyor? Hangi veri kaynaklarına erişiyor? Hangi araçları çağırabiliyor? Kullanıcı yetkisi model kararına nerede dahil oluyor? Modelin çıktısı hangi sisteme gidiyor? Bu sorular cevaplanmadan yapılan test, yalnızca demo üretir; gerçek risk haritası çıkarmaz.

İyi bir test planı dört eksende ilerler. Birinci eksen talimat çakışması: kullanıcı talimatı, sistem talimatı ve doküman içindeki talimat karşı karşıya geldiğinde model hangisini izliyor? İkinci eksen veri sınırı: model yetkisiz veriyi bağlama alıyor mu, alıyorsa kullanıcıya taşıyor mu? Üçüncü eksen eylem sınırı: model izinli olmayan aracı çağırmaya veya izinli aracı yanlış parametreyle kullanmaya yönlendirilebiliyor mu? Dördüncü eksen kalıcılık: saldırı oturum bittikten sonra bellekte veya sistem durumunda iz bırakıyor mu?

Bu yaklaşım saldırgan bakışını korur ama çalışan payload dağıtmayı gerektirmez. Kuruma gereken şey "şu cümleyi yazarsan kırılır" listesinden çok, hangi mimari kararın hangi riski doğurduğunu gösteren net bir tehdit modelidir.

Blue team neyi kontrol eder?

Blue team tarafında savunma üç seviyede kurulur: önleme, izleme ve müdahale. Önleme tarafında dış veri ile talimat ayrıştırılır; RAG kaynakları etiketlenir; tool calling izin listesine bağlanır; parametre doğrulaması yapılır; kritik aksiyonlar insan onayına gider. Modelin "bunu yapabilirim" demesi yeterli değildir, uygulama katmanı gerçekten izin vermelidir.

İzleme tarafında yalnızca kullanıcı mesajı ve model cevabı tutulmaz. Retrieval sonuçları, kullanılan kaynaklar, çağrılan araçlar, parametreler, karar anındaki kullanıcı yetkisi, çıktı filtresi sonucu ve hata mesajları birlikte kaydedilir. Bu kayıtlar olmadan prompt injection olayı yaşandığında geriye dönük analiz eksik kalır.

Müdahale tarafında ise LLM uygulamasına özel playbook gerekir. Bir prompt injection denemesi yakalandığında hangi oturumlar durdurulacak? Hangi bellek kayıtları temizlenecek? Hangi RAG dokümanı karantinaya alınacak? Hangi tool çağrıları geriye dönük incelenecek? Klasik SOC playbook'u bu soruları doğrudan cevaplamaz; AI uygulaması için ayrı karar noktaları gerekir.

Kurumsal kontrol listesi

Bir LLM uygulaması üretime alınmadan önce aşağıdaki sorulara net cevap verilmelidir:

• Model hangi veri kaynaklarına erişiyor?
• Bu kaynakların hangisi kurum içi, hangisi kullanıcı yüklemesi, hangisi harici web kaynağı?
• RAG sonucunda modele giden her parçanın kaynağı ve güven seviyesi loglanıyor mu?
• Model hangi araçları çağırabiliyor?
• Her araç için izin listesi, parametre doğrulaması ve oran sınırı var mı?
• Kritik aksiyonlarda insan onayı gerekiyor mu?
• Belleğe yazılan bilgiler tür, süre ve erişim sınırına göre ayrılıyor mu?
• Model çıktısı başka sistemler tarafından otomatik tüketiliyor mu?
• Prompt, cevap, retrieval ve tool çağrıları olay araştırması için yeterli seviyede kaydediliyor mu?
• Bu loglar kişisel veri ve sır yönetimi açısından kontrol altında mı?
• Prompt injection alarmı geldiğinde hangi playbook çalışıyor?
• Bu kontroller düzenli red team testiyle doğrulanıyor mu?

Bu soruların cevabı yoksa sistem "LLM kullanıyor" olabilir, ama güvenli şekilde LLM kullanıyor demek zordur.

Sonuç

Prompt injection, LLM uygulamalarında yalnızca model davranışını ilgilendiren bir konu değildir. Modelin bağlı olduğu veri, araç, bellek ve çıktı zinciri kadar geniş bir saldırı yüzeyidir. Bu yüzden savunma da aynı genişlikte kurulmalıdır.

Red team tarafı bu zincirdeki etki noktalarını arar. Blue team tarafı bu noktalara kontrol, kayıt ve müdahale mekanizması koyar. Kurumsal LLM güvenliği bu iki taraf birlikte ele alındığında anlam kazanır.

AltaySec'te bu konuya yaklaşımımız net: LLM güvenliği yalnızca "modeli ikna etme" tartışması değildir; kurumların üretime aldığı yapay zekâ sistemlerinin gerçekten nereden etkilenebileceğini ve bu etkilenmeyi nasıl azaltacağını ortaya koyan bir uygulama güvenliği disiplinidir.