Prompt injection system prompt’ları alt ediyor; bir geliştirici de agent güvenliğini mimaride yeniden kurdu

Savunmaları aşan bir test talebi

LLM destekli bir destek kutusu asistanını yayına almaya hazırlanan bir geliştirici, önce bir red-team egzersizi yaptı. dev.to’daki saha notu yazısında anlatıldığı üzere, özellik gelen talepleri özetliyor, müşterinin son siparişlerini getiriyor ve üç araç ile özenle yazılmış bir system prompt desteğiyle bir yanıt taslağı hazırlıyordu. Test, kapanış paragrafı doğrudan asistana seslenen ve yanıtına müşterinin eksiksiz sipariş geçmişini eklemesini ile dışarıdaki bir siteye bağlantı iliştirmesini söyleyen bir talepti. Model bu talimatların bir kısmını atladı ama yeterince çoğuna uydu ki yazar, system prompt’u bir güvenlik mekanizması olarak görmeyi bıraktı ve özelliği bu varsayıma dayanarak yeniden kurdu.

Hiçbir prompt sınırı çizemez

Yazı, prompt injection’ı bir dil modelinin üçüncü taraf metne emir olarak muamele etmesi olarak tanımlıyor. Doğrudan sohbete yazılabilir ya da bir e-posta, talep, kazınmış sayfa, kayıtlı belge veya araç yanıtı içinde dolaylı olarak gelebilir — ürünler için tehlikeli olan dolaylı biçimdir. Temel sorun mimariseldir: system prompt, kullanıcı mesajı ve getirilen içerik aynı context window içinde yer alır ve model, arada hiçbir izin denetimi olmadan, eğitimde öğrenilmiş örüntülerle neye uyacağını tartar. Kodu veriden protokol düzeyinde ayıran parameterized query’lerin çözdüğü SQL injection’ın aksine, LLM’lerde eşdeğer bir mekanizma yoktur.

Yazar ucuz önlemleri hâlâ uyguluyor — güvenilmeyen metnin açık etiketlerle sarılması, etiketli içeriğin veri olduğunu bildiren bir prompt ve bir talebin kendi bloğunu kapatamaması için benzer görünümlü etiketlerin ayıklanması — ama bunlar yalnızca isabet oranını düşürür. Saldırganın geçen tek bir ifade bulması yeterlidir.

Yayın öncesi kontrol listesi olarak üçlü

Yazı, Simon Willison’ın Haziran 2025’te adlandırdığı risk modeline, “öldürücü üçlüye” dayanıyor: bir agent, aynı anda özel verilere erişimi, güvenilmeyen içeriğe maruziyeti ve dış dünyaya bir kanalı olduğunda veri hırsızlığı aracına dönüşür. Bu ayaklardan herhangi birini kaldırın ve hırsızlık yolu çöker — injection hâlâ yerini bulsa bile. Yazar artık her LLM özelliğini yayına almadan önce bu üç ayak üzerinden puanlıyor — anonim ziyaretçiler için bir URL özetleyicisi düşük riskli sayılırken, repository erişimi ve açık ağı olan bir kodlama agent’ı üçüne de vuruyor ve sandbox’a ihtiyaç duyuyor.

Destek özelliği de üçüne birden vuruyordu. Çözüm daha akıllı bir prompt değil, giden bacağı tamamen silmekti: model yalnızca bir taslak üretiyor ve göndermeyi bir insan yapıyor. Dış kanalların gözden kaçması kolaydır, diyerek yazı giden HTTP araçlarını, e-posta ve webhook araçlarını, render edilen görsel ve bağlantıları ile modelin yazdığı ve başka bir sisteme eşitlenen her kaydı sayıyor.

Araçlar uygulamayı değil kullanıcıyı devralır

Yazıya göre her araç, oturum açmış kullanıcının izinleriyle çalışmalı ve kimin verisinin okunacağını belirleyen her şey — kimlik, tenant, alıcı — sunucuda oturumdan çözülmeli, asla model üretimi argümanlardan alınmamalıdır. Uygulama, araç kümesini sunucu tarafı bağlamını içine kapatan bir factory’de istek başına kuruyor; böylece modelin başka bir müşteriye ulaşabileceği bir argüman yoktur; model yalnızca bir kullanıcının meşru olarak yazabileceği değerleri seçer, örneğin katı bir şemayla sınırlanan sonuç sayısı gibi. Ardından üç kural daha gelir: argümanları katı biçimde doğrula ve hatalı değerleri zorlamak yerine reddet, görülmemiş veri sızamasın diye mümkün olan en az alanı geri döndür, ve okuma ile yazma araçlarını ayrı kümelerde tutarak yazma araçlarını yalnızca güvenilmeyen içerik tüketmemiş çalışmalara ekle.

Eylem yerine öneri, çıktıda güvensizlik

Sohbet dışında durum değiştiren her araç — mesaj gönderme, karttan para çekme, kayıt silme, pull request açma, webhook çağırma — çalışma güvenilmeyen içeriğe dokunduğunda eylemi gerçekleştirmek yerine bir öneri üretmelidir. Onay’a tıklayan bir insan, yerleştirilmiş bir talimatın hiçbir kaldıracı olamayacağı tek kapıdır; tabii onay ekranı gerçekte ne olacağını gösteriyorsa; örneğin yanıt aracı bir alıcı argümanı almaz, çünkü sunucu talebi kimin açtığını zaten bilir.

Çıktı, girdiyle aynı kuşkuyu hak eder. Model yanıtından gelen bir Markdown görselini doğrudan render etmek, hiçbir kullanıcı etkileşimi olmadan görsel URL’si üzerinden veri sızdırabilir; bu yüzden yazı görsel ve bağlantıların allowlist’lenmesini öneriyor.

Neden önemli

Bu, bir uygulayıcının güvenlik araştırmacılarının uzun süredir savunduğunu doğrulamasıdır: prompt injection, talimatlar ile verinin tek bir token akışını paylaştığı bugünkü modellerin yapısal bir özelliğidir ve ifade biçimi bunu yamayamaz. Agent yayına alan ekipler eski güvenlik pratiğinden ödünç almalıdır — en az ayrıcalık, sunucu tarafı yetkilendirme, ayrı okuma ve yazma yolları, yan etkilerde insan kapıları ve model çıktısına düşmanca muamele. Üçlü kontrol listesi uygulamak için ucuzdur ve etkileyici bir demoyu veri sızıntısına çeviren tasarım hatalarını tam olarak yakalar.