Belge, asistandan e-posta göndermesini istiyor
Asistana tedarikçi belgesini özetleme görevi veriliyor. Belgenin içindeki bir paragraf ise konuşmanın dışarıdaki bir adrese gönderilmesini söylüyor. Bu paragraf incelenecek içeriktir; işi veren kişinin talimatı değildir. İkisini eşdeğer sayan sistem bir güven sınırını geçmiş olur.
OWASP, doğrudan prompt injection ile dış içerikten gelen dolaylı talimatları ayırıyor. Ayrıca tek bir prompt kuralının sorunu çözmediğini belirtiyor. Prompt injection rehberi riskin çerçevesini veriyor.
Dolayısıyla tasarım sorusu, model saldırıyı fark edecek kadar iyi mi sorusundan daha somut: Hangi girdi, hangi işlemi etkileyebilir? Belge bütünüyle sıradan görünse de bu sorunun cevabı olmalı.
Bilginin yolu ile yetkinin yolunu ayır
Getirilen bir sayfa teslim tarihini bildirebilir veya bir politikayı açıklayabilir. Ancak asistanın hangi müşteri hesabına erişeceğini, dosyanın nereye gönderileceğini ya da onay gerekip gerekmediğini belirlememeli. Bu kararlar uygulamanın güvenilir bağlamına ve kullanıcının gerçek talebine dayanmalı.
Varsayımsal bir satın alma asistanında, verilen görev ile getirilen tedarikçi içeriği ayrı tanımlanabilir. Her iddianın kaynağı korunur. Belgeden alınan cümle, özete veya işlem önerisine taşındığında hâlâ belgenin iddiası olarak kalır.
Amaç bilgi getirmeyi engellemek değil, getirilen metnin sessizce yetkiye dönüşmesini önlemek. Açık sınırlar normal hataları da anlaşılır kılar. Gerçek bir kullanım kılavuzundaki eski talimatın zarar vermesi için kötü niyetli olması gerekmez.
Kontrolü işlemin yapılacağı yere koy
Sonuç doğuran bir işlemden önce öneri uygulamanın kontrolünden geçmeli. Kontrol, mevcut kullanıcıyı, hedef kaydı, izin verilen eylemi ve önerilen alıcıyı bilmeli. Belge bunun onaylandığını söylüyor cümlesi, yetki kanıtı sayılmamalı.
Tedarikçi örneğinde özet oluşturmak için e-posta gönderme aracına ihtiyaç yok. Gönderim gerçekten işin parçasıysa uygulama izinli alıcıyı zorunlu tutabilir ve dışarı çıkacak içeriği gösterebilir. Gereksiz işlemleri kaldırmak, bütün araçları açıp modelin yanlış olanları reddetmesini ummaktan daha denetlenebilir bir tasarımdır.
İnsan incelemesi de sonuç somutlaştığında yapılmalı. Oturum başında verilen genel bir onay, ileride bilinmeyen bir dosyanın bilinmeyen adrese gönderilmesini anlamlı biçimde onaylamaz.
Sıradan giriş yollarını da test et
Yalnızca açıkça saldırgan bir paragrafla yapılan deneme, içeriğin biçim değiştirdiği yerleri kaçırır. Aynı talimatı alıntılanmış yazışmada, belge başlığında, arama sonucunda ve araç hata mesajında deneyelim. Amaç uygulamanın kendi dönüşümleri sırasında kaynağı koruyup korumadığını görmek.
Son cevapla birlikte önerilen işlem de kaydedilmeli. Zararsız görünen yanıtın arkasında, başka bileşenin tesadüfen engellediği tehlikeli bir girişim bulunabilir. Tersine, asistan artık asıl görevi yapamıyorsa belgeyi reddetmesi tek başına başarı değildir.
Kabul ölçütünde hem sınırın korunması hem işin yapılabilmesi bulunmalı. Sistem kaynaklı bir özet üretmeli, eksik bilgiyi belirtmeli ve yetkisiz sonuç doğurmamalı.
Bu hafta gerçek bir işlemin izini sür
Gönderme, değiştirme veya silme yetkisi olan bir akış seçelim. Kullanıcı talebinden dış sayfalara ve araç cevaplarına kadar bu karara ulaşabilen bütün metinleri çıkaralım. Hangilerinin bilgi verdiğini, hangilerinin gerçekten yetki sağladığını işaretleyelim.
Ardından güvenilmeyen kaynağa bir talimat ekleyip yürütülmeden önce önerilen işlemi izleyelim. Uygulama yetkisiz eylemi reddederken meşru görevi sürdürebiliyor mu, bunu doğrulayalım. Sınırı bakım yapacak kişinin test edebileceği biçimde yazalım. Prompt'a eklenen sert bir uyarı, ancak sistem kimin karar vermeye yetkili olduğunu biliyorsa işe yarar.
