Dolaylı istem enjeksiyonuna karşı mimari

Altay Kargo'nun destek asistanı her gün yüzlerce bilet okuyor. Biletleri müşteriler yazıyor ve asistan hangisini kimin, hangi niyetle yazdığını ayırt edemiyor. Bir gün güvenlik ekibi, bir biletin içine modele hitap eden bir talimat gizlendiğini fark eder.

Talimat asistanı yüksek bir iade yapmaya ve bir kaydı dış bir adrese göndermeye yönlendiriyor. Asistan talimatı okur, ama iade onay kuyruğuna düşer, e-posta da reddedilir.

Hasar olmaz, çünkü önceki üç dersin önlemleri yerindedir. Bu derste o önlemleri tek bir mimaride birleştirirsin. Önce saldırının neden filtreyle durdurulamadığını görürsün. Ardından altı tasarım desenini tanır, bir biletin sistemdeki yolunu adım adım izler ve son olarak tespit ile test düzenini kurarsın.

İlk derste dış belgenin, kullanıcı mesajıyla aynı kanaldan modele girdiğini gördün. Saldırgan bu kanalı kullanıcıya hiç görünmeden kullanabilir. Bir destek biletine, bir web sayfasına ya da bir e-postaya, modele okutulacağını bilerek bir talimat yazar.

Model bu belgeyi okurken içindeki talimatı da kullanıcının isteği kadar gerçek bir emir gibi işleyebilir. OWASP'ın 2025 listesi bu riski LLM01 koduyla sayar ve iki türe ayırır. Doğrudan enjeksiyonda kullanıcının kendi istemi modelin davranışını değiştirir.

Dolaylı enjeksiyonda model, web sitesi ya da dosya gibi dış bir kaynaktan gelen girdiyi işlerken yönlendirilir. Saldırgan sohbete hiç katılmaz, sisteme oturum da açmaz. Modelin okuyacağı bir yere yazması yeter.

Güvenilmeyen içeriğin kaynakları sanıldığından çoktur: müşteri bileti, gelen e-posta, özetlenen web sayfası, RAG ile getirilen belge ve bir aracın döndürdüğü sonuç. Sonuncusu en sık unutulanıdır. Bir kargo takip aracı, dış bir sistemden gelen açıklama alanını modele geri taşıyorsa o alan da bir giriş kapısıdır. Model bu parçaları tek bir metin akışı olarak okur.

CWE-1427 kaydı sorunu tam bu noktada tanımlar: istem öyle kurulur ki model, dışarıdan gelen veriyi geliştiricinin talimatından ayıramaz. OWASP da modellerin olasılıksal doğası yüzünden kesin bir önleme yönteminin olup olmadığının belirsiz olduğunu yazar. Bu yüzden soru, talimatın modele ulaşıp ulaşmayacağı değil, ulaştığında ne yapabileceğidir.

Bu saldırıyı yalnız metinde arayan bir filtreyle durdurmak zordur. Saldırgan cümleyi binlerce farklı biçimde yazabilir: başka bir dilde, kodlanmış hâlde, harfleri karıştırılmış olarak. Filtre her seferinde bir adım geride kalır.

Sınıflandırıcı modeller daha iyi sonuç verir, ama onlar da olasılıksaldır. OWASP'ın istem enjeksiyonu önleme rehberi bunu açıkça yazar: koruma amaçlı bir model de sonuçta bir modeldir ve kendisi de istem enjeksiyonuna açıktır. Sistem istemine eklenen uyarı cümlesi de aynı sınıra takılır.

PortSwigger, isteme dayalı savunmaya güvenmemeyi önerir, çünkü özenle kurulmuş bir istem bu uyarıyı genellikle aşar. Filtre ve sınıflandırıcı yine de işe yarar: gürültüyü azaltır, uyarı üretir. Ama güvenlik sınırını onlar çizmez, mimari çizer.

Mimari dört katmanla çalışır ve bu katmanlar önceki üç dersin önlemleridir. Birinci katman yetki sınırıdır. Talimat modeli ikna etse bile araç izin listesine, şemaya, oturuma ve eşiğe bakar.

İkinci katman daraltmadır. Model bir sırrı hiç görmüyorsa, talimat o sırrı isteyemez. Model yalnız gerekli alanları görüyorsa, talimatın kullanabileceği malzeme de azalır.

Üçüncü katman insan onayıdır. Geri alınamaz ya da yüksek etkili eylem, talimat nereden gelirse gelsin bir insana sorulur.

Dördüncü katman izlemedir. Her araç çağrısı, onu tetikleyen girdiyle birlikte kayda yazılır. İlk üç katman hasarı olay sırasında sınırlar. Dördüncüsü hasarı sonradan anlamayı ve aynı açığı kapatmayı mümkün kılar.

Beurer-Kellner ve arkadaşları Haziran 2025'te ajanları istem enjeksiyonuna karşı korumak için altı tasarım deseni yayımladı. Desenlerin ortak fikri şudur: ajan güvenilmeyen bir girdiyi okuduktan sonra, o girdi sonuç doğuran bir eylemi tetikleyememeli. İlk desen Eylem Seçici'dir.

Model yalnız önceden tanımlı eylem listesinden birini seçer, araç çıktısını hiç geri okumaz. İade asistanında model, sipariş durumunu göster ya da temsilciye aktar gibi sabit eylemlerden birini seçer.

İkinci desen Planla ve Yürüt'tür. Ajan, güvenilmeyen veriyi okumadan önce planını sabitler. Bilet okunmadan önce yalnız sipariş bulma ve iade önerme adımları planlanır. Biletteki talimat plana yeni bir adım ekleyemez.

Üçüncü desen LLM Map-Reduce'tur. Her bilet ayrı bir model örneğinde işlenir ve yalnız kısıtlı bir sonuç, örneğin evet ya da hayır, birleştirme adımına geçer.

Dördüncü desen Çift LLM'dir. Ayrıcalıklı model araçlara erişir ama güvenilmeyen veriyi hiç okumaz. Karantinadaki model ise veriyi okur ama hiçbir araca erişemez. Karantina çıktısı ayrıcalıklı modele metin olarak değil, sembolik bir değişken olarak geçer.

Beşinci desen Kod Üret ve Yürüt'tür. Ayrıcalıklı model, kullanıcının isteğinden araçları çağıran küçük bir program yazar. Program güvenilmeyen veri üzerinde çalışır ama akışı veriye göre değişmez. Altıncı desen Bağlam Küçültme'dir.

Kullanıcının ilk istemi, eylem seçildikten sonra bağlamdan çıkarılır. Böylece sonraki adımda o istemdeki bir talimat yanıtı etkileyemez. Her desenin bir kullanışlılık bedeli vardır.

Eylem Seçici güçlü bir koruma verir, ama esnekliği ciddi biçimde kısıtlar. Sonucu önceki adıma bağlı görevler Planla ve Yürüt ile zorlaşır. Desen seçimi, görevin ne kadar esneklik istediğine göre yapılır.

Altay Kargo'nun güvenlik ekibi iade asistanını Çift LLM ile Planla ve Yürüt desenlerini birleştirerek yeniden kurdu. Biletin görünen kısmı sıradan bir hasar bildirimidir: paket ezik gelmiş, müşteri iade istiyor. Gizli kısım ise modele hitap ediyor.

Aşağıdaki tablo, bilet 8801'in sistemdeki yolunu gösteriyor. Her satır bir bileşeni, o bileşenin gördüğü veriyi ve ürettiği çıktıyı yazar. Tabloyu okurken tek bir soruya odaklan: biletin metni hangi adımlara ulaşıyor, hangilerine ulaşamıyor?

Adım  Bileşen                      Gördüğü                  Ürettiği
1     Bilet kuyruğu                müşterinin metni         bilet:8801
2     Karantina modeli (araçsız)   bilet metni              {"kategori":"hasar","takip_no":"AK204118"}
3     Şema ve iş kuralı            karantina çıktısı        geçerli karar ya da insan kuyruğu
4     Planlayıcı model (araçlı)    kategori, takip no       iade_yap(takip_no=AK204118)
5     İade aracı                   takip no, oturum         tutar sipariş kaydından: 350 TL
6     Eşik ve onay                 tutar                    500 TL'ye kadar otomatik, üstü kuyruk
7     Denetim kaydı                bütün adımlar            tetikleyen=bilet:8801

Biletin metni yalnız 2. adıma ulaşır. Karantina modelinin elinde hiçbir araç yoktur. Gizli talimat bu modeli ikna etse bile yapabileceği tek şey, iki alanlı bir JSON üretmektir.

3. adım bu JSON'u şemayla ve iş kuralıyla sınar. Kategori dört değerden biri olmalı, takip numarası bileti açan müşteriye ait olmalı.

4. adımdaki planlayıcı bilet metnini hiç görmez, yalnız doğrulanmış iki alanı görür. 5. adım en önemli tasarım kararını taşır.

Tutar modelden gelmez, sipariş kaydından okunur. Talimat tutarı büyütmeye çalışsa da büyütebileceği bir alan yoktur.

Geriye kalan risk kategoridir: talimat gecikmeyi hasar gibi gösterebilir. Bu yüzden kategori yalnız yönlendirmeyi değiştirir, tutarı belirlemez. Bedel de açıktır. Planlayıcı biletteki ayrıntılı bir soruya cevap veremez, onu temsilci okur.

Eski mimaride aynı bilet çok farklı bir yol izlerdi. Gömülü talimat asistanı 5000 TL iade yapmaya yönlendiriyor. Asistan talimatı okur ve iade aracını çağırmaya karar verebilir. Ama araç tutarın eşiği aştığını görür ve işlemi otomatik geçirmez.

İkinci derste kurduğun kapı, talimatın kaynağına bakmadan devreye girer. Yeni mimari aynı kapıyı korur ve önüne ikinci bir duvar ekler. Talimat artık iade aracına ulaşan değerleri de seçemez.

Aynı biletteki ikinci talimat, bir kaydı dış bir adrese e-postayla göndermeyi istiyor. E-posta aracı da eşikli iade aracıyla aynı mantıkla çalışır. Talimat nereden gelirse gelsin araç kendi izin listesine bakar ve yalnız tanıdığı alan adlarına gönderim yapar. Modelin ikna olup olmadığı bu denetimi hiç etkilemez.

Kararı model değil, aracın sabit listesi verir. Bu denetim öldürücü üçlünün dışarıyla iletişim ayağını da keser. Aşağıdaki istekte alıcıyı değiştirip aracın tepkisini gör.

Mimari hasarı sınırlar, ama denemeyi görmek de istersin. Her araç çağrısı, onu tetikleyen girdinin kimliğiyle kayda yazılır: bilet 8801, e-posta 4410, sayfa özeti 77. Bu alan olmadan bir olayın kaynağını bulmak samanlıkta iğne aramaya döner.

Kayıtta üç belirti aranır. Birincisi beklenmeyen alıcıdır: izin listesi dışı bir alan adına gönderim denemesi. İkincisi bölünmüş işlemdir: aynı kaynaktan kısa sürede gelen, eşiğin hemen altında kalan iadeler.

Üçüncüsü kanarya jetonudur. Sistem istemine ya da gizli bir belgeye, başka hiçbir yerde geçmeyen rastgele bir dizge koyarsın. Bu dizge bir yanıtta, bir araç parametresinde ya da dışarı giden bir istekte görünürse bağlamın sızdığını anlarsın.

Savunmayı yalnız tasarımla değil testle de doğrularsın. AgentDojo, bu iş için kurulmuş açık bir kıyas ortamıdır. 97 gerçekçi görev ve 629 güvenlik test durumuyla, bir ajanın güvenilmeyen veriyi işlerken saldırıya ne kadar dayandığını ölçer.

Kendi sistemin için de benzer bir set kurarsın. Gömülü talimat taşıyan örnek biletler, beklenen davranışlarıyla birlikte depoda durur. Her model, istem ya da araç değişikliğinde bu senaryolar sürekli entegrasyon hattında koşar.

Bir senaryo beklenen sonucu vermezse değişiklik birleşmez. Senaryolar zamanla büyür: üretimde görülen her yeni deneme, anonimleştirilip sete eklenir. Değerlendirme yöntemlerinin ayrıntısını AI Güvenliği yolundaki değerlendirme modülü işler.