Sürekli başarısız olan çerçeveleme
Agent güvenliği tartışmalarının çoğu hâlâ prompt üzerinde yoğunlaşıyor. Sorulan soru, bir modelin zararlı metin üretmeye ikna edilip edilemeyeceği; önerilen kontrol ise bir sınıflandırıcı ya da sistem talimatı. Bu çerçeveleme, bir agent'a kimlik bilgisi ve bir araç verildiği anda çöküyor. Bir tool call üreten prompt injection, bir içerik moderasyonu olayı değildir. Bu, agent'ın izin kümesine karşı, yorumlayıcısı tesadüfen bir dil modeli olan bir uzaktan kod çalıştırmadır.
Bu ayrım önemlidir çünkü önlemler farklıdır. Prompt filtreleri girdiler üzerinde çalışır ve olasılıksaldır. İzin sınırları yetenekler üzerinde çalışır ve deterministiktir. Yalnızca ilkini devreye alan bir ekip, yanlış katmanı savunuyor demektir.
Saldırganlar bu geçişi çoktan yaptı. Kart hırsızlığı için kullanılan agent sürülerine ilişkin raporlar konuşmayı değil altyapıyı anlatıyor: hesap açan, ödeme kimlik bilgilerini tutan ve değeri alt servisler üzerinden yönlendiren düzenlenmiş süreçler. Agent'lar iş yükünün kendisidir. Prompt ise yalnızca ona açılan arayüzdür.
Kimlik sağlayıcıları da aynı sonuca yakınsıyor. Agent kimliği üzerine yapılan çalışmalar — agent'lara kendi principal'larını vermek, token'larını kapsamlandırmak, eylemlerini denetlemek — tam da kimlik bilgisi taşıyan bir agent'ın bir kimlik yaşam döngüsüne ihtiyaç duyan bir iş yükü olması nedeniyle var. Doğru çerçeve budur ve bu yazı da bu çerçeveden savunuyor.
Yanal hareket neye benzer
Yanal hareket, bir saldırganın ilk erişimden sonra kendisine verilmeyen sistemlere ulaşmak için kullandığı teknikler bütünüdür. Agent'lar için ilk erişim genellikle agent'ın okuduğu içerik üzerinden başarılı bir injection'dır: getirilen bir belge, bir araç yanıtı, bir web sayfası, bir ticket gövdesi. Buradan itibaren agent'ın kendi izinleri saldırganın izinleri hâline gelir.
Bir veri kümesine okuma erişimi ve alt bir araca — bir ticket sistemi, bir mesajlaşma API'si, bir kod barındırma servisi — yazma erişimi olan bir agent düşünün. İki izin de tek başına aşırı değildir. Birleştiğinde ise bir sızdırma yolu oluştururlar: veri kümesini oku, sonucu alt aracın kabul edeceği bir alana kodla ve dışarı yaz. Her bir çağrı tek tek belirtilen kapsam içindedir. Bileşimi değildir.
Bu, bir veritabanını okuyup harici bir uç noktaya yazabilen bir servis hesabının agent karşılığıdır. Hiçbir olgun güvenlik ekibi bu eşleşmeyi bir egress kontrolü olmadan kabul etmez. Agent dağıtımları ise bunu rutin olarak kabul eder, çünkü araç listesi bir yapılandırma dosyasında düzenli görünür.
Bunu daha da kötüleştiren iki çarpan var.
Birincisi, paylaşılan araç kimlik bilgileri. Birden fazla agent aynı araca aynı secret ile kimlik doğruladığında, tek bir ihlalin etki alanı tüm filodur. İhlal edilen agent'ı diğerlerini iptal etmeden iptal etmenin bir yolu yoktur ve sonradan bir çağrıyı belirli bir agent'a atfetmenin de bir yolu yoktur. Denetim kaydı bir principal'ı değil, bir servis hesabını kaydeder.
İkincisi, uzun ömürlü token'lar. Çok günlük bir ömre sahip bir token, tek bir başarılı injection'ı kalıcı bir dayanağa dönüştürür. Saldırganın yeniden injection yapmasına gerek yoktur; onu üreten konuşma bittikten sonra da çalışmaya devam eden bir kimlik bilgisine sahiptir. Haftalarla ölçülen rotasyon pencereleri, geçici bir olayı kalıcı bir erişim iznine dönüştürür.
Gerçekten bağlayıcı olan kontroller
Etki alanını azaltan kontroller, herhangi bir ayrıcalıklı iş yüküne uygulananların aynısıdır; yalnızca agent'ın çağrı desenine uyarlanmıştır.
Agent başına, araç başına, kısa ömürlü kimlik bilgileri
Her agent kendi kimliğini taşımalı ve bu kimlik yalnızca ihtiyaç duyduğu belirli araçlarla kapsamlandırılmalıdır. Kimlik bilgileri bir görevin başında verilmeli ve sonunda sona ermeli; geçerli oldukları aracı adlandıran açık bir audience kısıtlamasıyla birlikte. Salt okunur bir analitik uç noktası için üretilmiş bir token, doğru şekilde sunulsa bile mesajlaşma API'si tarafından reddedilmelidir.
Bu, standart iş yükü kimliği pratiğidir. Ödünleşim operasyoneldir: kısa ömürlü kimlik bilgileri, agent'ların erişebileceği bir token verme yolu gerektirir ve bu yol bir bağımlılık hâline gelir. Verme mekanizması kullanılamazsa agent'lar çalışmayı durdurur. Ekipler, bozulmuş bir agent'ın uzun ömürlü bir kimlik bilgisinden daha mı iyi olduğuna karar vermelidir ve yanıt genellikle evettir — ama bunun tasarlanması gerekir, varsayılması değil.
Ağ katmanında egress allowlist'leri
Araç düzeyindeki kısıtlamalar gereklidir ve yetersizdir. Agent'ın çalışma zamanı rastgele giden bağlantılar açabiliyorsa, ihlal edilmiş bir agent hiçbir araç politikasının yönetmediği bir kanaldan sızdırabilir. Egress, ağ katmanında agent'ın meşru olarak ihtiyaç duyduğu hedeflerle sınırlandırılmalı ve DNS çözümlemesi de buna uyacak şekilde kısıtlanmalıdır.
Buradaki dürüst ödünleşim sürtünmedir. Allowlist'ler bir araç yeni bir uç nokta eklediğinde, bir tedarikçi CDN değiştirdiğinde ya da meşru bir iş akışı yeni bir host'a ulaştığında bozulur. Maliyet gerçek ve tekrarlayıcıdır. Yine de sınırsız bir egress yolunun maliyetinden düşüktür, ancak ekipler allowlist'i tek seferlik bir yapılandırma olarak görmek yerine bakımı için bütçe ayırmalıdır.
##
code-on-screen-dark-9fc1eb-81348e.jpg)
Her tool call, onu yetkilendiren principal, kullanılan kimlik bilgisi, geçirilen parametreler ve döndürülen sonuçla birlikte kaydedilmelidir. Log append-only olmalı ve agent'ın yazamayacağı bir yerde saklanmalıdır. Agent'ın değiştirebildiği bir trajectory log'u denetim izi değildir.
Mekanizma, formattan daha önemlidir. Kullanışlı bir trajectory kaydı üç şeyi birbirine bağlar: agent kimliği, belirli kimlik bilgisi örneği ve araç çağrısı. Kimlik bilgisi örneği olmadan, bir rotasyondan önce yapılan bir çağrıyı sonrasında yapılandan ayırt edemezsiniz. Agent kimliği olmadan, bir olayı paylaşılan bir hesap yerine tek bir agent'a kapsamlandıramazsınız.
Bir güvenlik kontrolü olarak değerlendirme
Agent'lar için güvenlik değerlendirmesi, servisler için kullanılan deseni izlemelidir: girdinin düşmanca olduğunu varsayın ve düşmanın neye ulaşabildiğini ölçün.
Agent'a bir API'yi red-team'ler gibi red-team yapın. Agent'ın okuduğu her kanaldan — getirilen belgeler, araç çıktıları, kullanıcı mesajları, dosya içerikleri — injection yapın ve hangi tool call'ların oluştuğunu gözlemleyin. Amaç kötü metin üreten prompt'lar bulmak değildir. Yetkisiz çağrılar üreten girdileri bulmaktır.
Reddetmeyi değil, containment'ı puanlayın. Bir reddetme oranı, agent'ın ne sıklıkla geri çevirdiğini söyler. Bir containment skoru ise başarılı bir injection'ın ne kadar yayıldığını söyler: kaç araca ulaştığını, kaç kimlik bilgisini kullanabildiğini, ortaya çıkan erişimin ne kadar sürdüğünü. Reddetme oranı bir kalite metriğidir. Containment bir güvenlik metriğidir ve etki alanına karşılık gelen de odur.
Pratik çıktı, injection başına bir containment zarfıdır: X noktasında başarılı bir injection verildiğinde, hangi araçlara ulaşılabilir, hangi kimlik bilgileri kullanılabilir ve ortaya çıkan erişimin ömrü nedir. Yukarıdaki kontrollerle küçülttüğünüz şey bu zarftır ve paydaşlara raporladığınız da budur.
Saldırı yüzeyini yayımlayın
Bir agent dağıtımı, sistem prompt'unun yanında bir saldırı yüzeyi belgesiyle birlikte sunulmalıdır. Belge, agent'ın hangi girdileri güvenilmez olarak ele aldığını, hangi araçları çağırabildiğini, her aracın kimlik bilgisinin neye ulaşabildiğini, egress'in nereye izin verildiğini ve başarılı bir injection altında containment zarfının neye benzediğini belirtmelidir.
Bu bir açıklama alıştırması değildir. Bir tasarım artefaktıdır. Ulaşılabilir araç kümesini yazmak, her kenarın gerekli olup olmadığı sorusunu zorunlu kılar ve olay müdahale ekiplerine başlangıç haritası verir. Bir sistem prompt'u amaçlanan davranışı tanımlar. Bir saldırı yüzeyi belgesi ise prompt kontrol altında değilken sistemin gerçekte ne yapabildiğini tanımlar.
İki belge birbirinin yerine geçmez. Prompt arayüz sözleşmesidir. Saldırı yüzeyi güvenlik sözleşmesidir. Agent sistemleri her ikisine de ihtiyaç duyar ve ikincisi, birincisini hiç okumayan bir düşman tarafından test edilecek olandır.