Bir dil modeli, kendisine gelen metnin hangi kısmının veri, hangi kısmının talimat olduğunu ayırt edemez. Model için ikisi de aynı token dizisidir. İstem enjeksiyonu literatürünün tamamı, bu tek cümlenin sonuçlarından ibarettir.
Klasik bir enjeksiyon saldırısında — SQL enjeksiyonunda mesela — sorgu dili ile kullanıcı verisi arasında en azından teorik bir sınır vardır; parametreli sorgu bu sınırı zorunlu kılar. Dil modellerinde böyle bir sınır yoktur. Sistem istemi, kullanıcı mesajı, araçtan dönen çıktı, indirilen bir web sayfası: hepsi aynı bağlam penceresinde düz metin olarak birleşir. Modelin "bu satır bana emir vermeye yetkili değil" diyebilmesi için, yetkiyi metnin kendisinden çıkarması gerekir. Bu da tanımı gereği kandırılabilir bir mekanizmadır.
Görünür istem ile gerçek istem arasındaki fark
PurpleSec, gölge istemi (shadow prompting), görünür istemde hiç yer almadan modelin davranışını değiştiren gizli veya dolaylı talimatlar olarak tanımlıyor. Tanımın kritik kısmı "görünür istemde yer almadan" ibaresi: kullanıcı ekranda ne yazdığını görür, modelin gerçekte ne okuduğunu görmez.
PurpleSec'in saydığı saldırı vektörleri şunlar:
| Vektör | Talimat nereye saklanıyor |
|---|---|
| Bağlam hafızası | Önceki oturumlardan taşınan, kullanıcının artık görmediği notlar |
| Değiştirilmiş sistem istemleri | Uygulama katmanında kullanıcıya gösterilmeyen yönergeler |
| Harici bağlayıcılar | Konektör veya eklentiden dönen içerik |
| Belge metadata'sı | PDF, DOCX, resim dosyalarının görünmeyen alanları |
| HTML etiketleri | display:none, yorum satırları, alt metinler |
| Gizlenmiş Unicode | Sıfır genişlikli karakterler, homoglifler, yön işaretleri |
Bu listenin ortak paydası dikkat çekici: hiçbiri modelin kendisindeki bir açık değil. Hepsi, metnin modele ulaşma yolundaki bir taşıyıcı. Yani enjeksiyon bir model zafiyeti değil, bir boru hattı zafiyeti.
Ne kadar işe yarıyor
PurpleSec'in aktardığı bir arXiv çalışması, gizlenmiş metnin birden fazla yapay zeka modeli üzerinde yüzde 98,6 başarı oranına ulaştığını bildiriyor. Bu sayıyı ihtiyatla okumak gerekir — çalışmayı doğrudan okumuş değiliz, PurpleSec'in aktarımına dayanıyoruz — ama büyüklük mertebesi bile tek başına anlamlı. Yüzde 98'ler seviyesindeki bir başarı oranı, savunmanın "modelin fark etmesini ummak" üzerine kurulamayacağı anlamına gelir.
Aynı mekanizmanın pratikte ne yapabildiğine dair iki gösterim var. HiddenLayer, bağlayıcılar, eklentiler ve belge metadata'sı üzerinden kurulan düşmanca zincirlerin kod asistanlarına kod değiştirttiğini ve veri sızdırdığını gösterdi. Google Antigravity üzerinde ise HTML etiketlerine ve bilet sistemlerine yerleştirilen gizli istemlerle bir istismar gösterimi yapıldı. İkisinin de ortak özelliği, saldırganın kullanıcıyla hiç konuşmaması: zararlı talimat, kurbanın zaten okuttuğu bir kaynağın içinde bekliyor.
Kullanıcı bir Jira biletini asistanına özetletiyorsa, bileti okumak beklenen davranıştır. Biletin içindeki gizli talimatın çalışması kullanıcının dikkatsizliğinden değil, sistemin veri ile talimatı ayıramamasından kaynaklanır. "Çalışanları eğitelim" bu sınıf için geçerli bir kontrol değildir.
Filtreler neden tutmuyor
Enjeksiyonun ikinci cephesi, güvenlik filtrelerinin kendisi. Brown Üniversitesi'nde yapılan bir araştırma, GPT-4'ün güvenlik filtrelerinin İngilizce dışına çevrilmiş girdilerle aşılabildiğini ve bu yolun yüzde 79 oranında uygulanabilir zararlı çıktı ürettiğini bulmuştu. Bulgu, techpolicy.press'te Eryk Salvaggio tarafından 19 Ekim 2023 tarihinde aktarıldı.
Buradaki ders çeviriyle sınırlı değil. Filtre, eğitim dağılımının yoğun olduğu yerde iyi çalışır; kenarlarda zayıflar. Çeviri bir kenar. Base64, sıfır genişlikli karakterler, alışılmadık biçimlendirme de birer kenar. Savunma katmanı modelin kendi anlama kapasitesine bağlıysa, o kapasitenin zayıfladığı her yerde savunma da zayıflar. Bu, filtrelerin işe yaramadığı anlamına gelmez; tek başına yeterli olmadığı anlamına gelir.
Savunma nerede durur
Gerçekçi bir savunma hattı üç ilkeye dayanır.
Talimat kaynağını sınıflandır
Modele giren her metin parçası için kaynağı bilinmelidir: kullanıcı mı yazdı, sistem mi koydu, dış bir kaynaktan mı geldi. Dış kaynaklı metin, taşıdığı talimatlar açısından hiçbir zaman güvenilir sayılmamalıdır. Bu ayrımı model içinde yapmaya çalışmak yerine, bağlamı kuran uygulama katmanında yapmak gerekir.
Yetkiyi metinden değil koddan al
Enjeksiyonun zarara dönüşmesi için modelin bir şey yapabilmesi gerekir: dosya yazmak, istek atmak, mesaj göndermek. Zarar, model çıktısında değil, o çıktının tetiklediği eylemde oluşur. Dolayısıyla asıl kontrol noktası araç çağrısıdır. Hangi aracın hangi koşulda, hangi onayla çalışacağı kodda tanımlıysa, en başarılı enjeksiyon bile yalnızca metin üretmiş olur.
Deterministik tarama yap
Girdide ve çıktıda ne olduğunu anlamak için modele soru sormayın. Gizli Unicode, gizlenmiş HTML, kimlik bilgisi kalıpları — hepsi düzenli ifadeyle, ayrıştırıcıyla, imza listesiyle deterministik olarak yakalanabilecek şeylerdir. Kendi ölçümümüzde bir LLM sınıflandırıcının, aktif bir üretim API anahtarını sıradan iş metni olarak etiketlediğini gördük; ayrıntısını Çalışanlar yapay zekaya ne yapıştırıyor? yazısında paylaştık. Tespit işini modele bırakmak, kandırılabilir bir mekanizmayı savunma katmanına terfi ettirmektir.
"Modelimiz enjeksiyona dayanıklı mı" yanlış sorudur. Doğru soru şudur: modelin bağlamına dışarıdan metin giren kaç yol var ve bu yollardan gelen metin hangi araçları tetikleyebiliyor? Cevabı yazılı olmayan her organizasyon, saldırı yüzeyini bilmiyor demektir.
Özet
İstem enjeksiyonu egzotik bir araştırma konusu değil, dil modeli mimarisinin doğrudan sonucu. Talimat ile veri aynı kanaldan aktığı sürece bu sınıf kapanmayacak. Yapılabilecek şey, kanalı tanımak ve zararın oluştuğu yeri — eylem katmanını — deterministik kontrollerle çevrelemek.
Aynı gizli katmanın savunma tarafında nasıl kullanıldığını Gizli sistem istemleri yazısında, kavramın gölge AI ile farkını ise Gölge AI nedir, farkı ne yazısında ele aldık.