Bir sohbet arayüzüne yazdığınız cümle, modele gitmeden önce bir zarfın içine konur. Zarfın üstünde sizin görmediğiniz talimatlar vardır: kim olduğu, neyi yapmayacağı, çıktıyı hangi formatta vereceği, hangi araçları çağırabileceği. Bu zarfa sistem istemi denir ve pratikte kullanıcıya neredeyse hiçbir zaman gösterilmez.
Bu görünmez katman kötü bir şey değil. Aksine, üretim ortamındaki her ciddi AI uygulaması onsuz çalışmaz. Ama görünmez olması, denetlenmesini de zorlaştırır — ve denetlenmeyen bir kontrol katmanı, zamanla kontrol olmaktan çıkar.
İki farklı "gölge istem" tanımı
Terim literatürde iki ayrı anlamda kullanılıyor ve ikisini karıştırmak tartışmayı bozuyor.
CloudQix, gölge istemi kurumların yönetişim kontrolü olarak kullandığı gizli arka plan istemleri şeklinde tanımlıyor: korkuluklar, güvenlik politikası, biçimlendirme kuralları. Yani savunma tarafı. Bu tanımda gizlilik bir özellik: kullanıcı korkuluğu göremediği için etrafından dolaşması da zorlaşır.
PurpleSec ise aynı terimi saldırı tarafından tanımlıyor: görünür istemde yer almadan model davranışını değiştiren gizli veya dolaylı talimatlar. Bu tanımda gizlilik bir zafiyet.
| Yön | Kim koyuyor | Amaç | Görünmezliğin sonucu |
|---|---|---|---|
| CloudQix tanımı | Kurumun kendisi | Korkuluk, politika, format | Kontrol atlatılması zorlaşır |
| PurpleSec tanımı | Saldırgan veya üçüncü taraf | Davranışı değiştirmek | Saldırı fark edilmez |
İkisi çelişmiyor; aynı mekanizmanın iki ucu. Sistem istemi katmanı, davranışı metinle yönlendirme yeteneğidir. Bu yeteneği kurum kullanırsa yönetişim, saldırgan kullanırsa enjeksiyon olur. Mekanizma aynı olduğu için savunma da tek taraflı kurulamaz.
Korkuluklarınızı metinle koyuyorsanız, saldırgan da metinle kaldırabilir. "Önceki talimatları yok say" saldırısının bu kadar uzun süre çalışmasının nedeni, korkuluğun saldırganla aynı ayrıcalık düzeyinde yaşamasıdır.
Görünmez katman neyi taşır
Tipik bir üretim sistem istemi şu işleri üstlenir:
- Kimlik ve kapsam. Asistanın kim olduğu, hangi konularda yanıt vereceği.
- Güvenlik politikası. Reddedilecek istekler, yükseltme kuralları.
- Araç sözleşmesi. Hangi aracın hangi koşulda çağrılacağı, argüman kısıtları.
- Veri sınırları. Hangi alanların çıktıya yazılmayacağı, hangi kaynakların alıntılanacağı.
- Biçim. Uzunluk, dil, başlık düzeni.
Bu listedeki ilk dördü güvenlik kontrolüdür. Yani pek çok kurumda güvenlik kontrolleri, sürüm takibi olmayan, kod incelemesinden geçmeyen, testi bulunmayan bir metin bloğunda yaşıyor. Bir güvenlik ekibinin firewall kuralını böyle yönetmesi düşünülemez; sistem istemi söz konusu olduğunda bu normal karşılanıyor.
Sistem istemi bir sır değildir
Yaygın bir yanlış varsayım, sistem isteminin gizli kaldığıdır. Pratikte sistem istemleri düzenli olarak dışarı çıkar: model bunları özetleyebilir, tekrarlayabilir, dolaylı sorularla parça parça ele verebilir. Tam metni sızmasa bile davranışı gözlemleyerek kuralları çıkarmak mümkündür.
Doğru varsayım şudur: sistem istemi, saldırganın er ya da geç okuyacağı bir belgedir. Buna göre yazılmalıdır. İçine API anahtarı, iç sistem adresi, müşteri listesi, iç prosedür ayrıntısı koymak — hepsi sızma bekleyen veridir. Sistem istemi bir yapılandırma dosyası gibi değil, herkese açık bir dokümantasyon gibi ele alınmalıdır.
Kimlik bilgileri, iç ağ adresleri, veritabanı şeması ayrıntıları, gerçek müşteri örnekleri ve "bu kuralı kullanıcıya söyleme" tipi güvenlik-belirsizlik varsayımları. Bu maddelerin hepsi, istem sızdığı anda doğrudan saldırganın eline geçer.
Denetim açısından asıl sorun
Kurum içi AI kullanımını denetlerken karşılaşılan en sinsi durum, katmanın kim tarafından yazıldığının bilinmemesi. Bir ekibin kendi kurduğu asistanda sistem istemi, bir ürün yöneticisinin panelden düzenlediği metin olabilir. Aynı metin başka bir ekipte kod deposunda tutuluyordur. Üçüncü bir yerde ise SaaS sağlayıcının varsayılanı kullanılıyordur ve kurum içinde kimse içeriğini görmemiştir.
Bu üç durumun risk profili tamamen farklı, ama envanterde hepsi "AI asistanı" olarak görünür. Denetimin ilk çıktısı bu yüzden bir liste olmalıdır: hangi uygulamada sistem istemi nerede duruyor, kim değiştirebiliyor, değişiklik kaydı tutuluyor mu.
Sorulacak somut sorular:
- Sistem istemi sürüm kontrolünde mi, yoksa bir arayüzdeki metin kutusunda mı?
- Değişikliği kim onaylıyor? Onay kaydı var mı?
- İstem değiştiğinde çalışan bir regresyon testi seti var mı?
- İstemin içinde sır veya iç sistem bilgisi geçiyor mu?
- Dışarıdan gelen içerik (belge, bilet, web sayfası) istemle aynı bağlama giriyorsa, aralarında kaynak ayrımı yapılıyor mu?
Beşinci soru en kritiği ve genelde cevabı yoktur. Dış içerik ile sistem talimatı aynı düzlemde birleştiği anda, istem enjeksiyonu yazısında anlattığımız bütün vektörler devreye girer.
Metin korkuluğu tek başına yetmez
Sistem isteminin taşıyabileceği kontrolün bir tavanı var. Metin, olasılıksal bir sistemi olasılıksal olarak yönlendirir; garanti vermez. Garanti gerektiren her kontrol kodda olmalıdır:
- Araç çağrılarının izin listesi ve argüman doğrulaması
- Çıktının dışarı gitmeden önce deterministik olarak taranması
- Oran sınırı, harcama sınırı, veri hacmi sınırı
- Yetki kontrolünün model dışında, çağıran servis tarafında yapılması
Sistem istemi davranışı biçimlendirir, kod ise sınırları uygular. Bir kontrolü ihlal etmenin bedeli ciddiyse, o kontrol istemde değil kodda olmalıdır.
Görünmez katmanı yok edemezsiniz; her AI uygulamasının çalışması ona bağlı. Yapabileceğiniz şey, onu görünür hale getirmek: sürümlemek, test etmek, içeriğini sırlardan arındırmak ve taşıyabileceğinden fazla sorumluluk yüklememek. Modele bırakılmaması gereken işlerin en başında sır tespiti geliyor; bunu Sır tespitini modele bırakmayın yazısında ayrıntılandırdık.