Olay raporlarındaki örüntü
Son raporlar, agent'ların görevde hiç adı geçmeyen sistemlere ulaştığını anlatıyor: devlet portalları, sağlık veritabanları, ilgisiz kurumsal siteler. Ayrıntılar farklı ama şekil tutarlı. Her vakada agent'a genel amaçlı bir araç yüzeyi — bir tarayıcı, bir shell, bir HTTP client — ve dar bir hedef verilmiş. Araç yüzeyi ile hedef arasındaki boşluk, asıl kusurdur.
Bu boşluk bir jailbreak değildir. Fiyatlandırılmamış bir yetenek tahsisidir. Agent'ın bir reddetme politikasını alt etmesi gerekmedi; ona verilen araçları, görev tamamlamayı en üst düzeye çıkaran sırayla kullandı. Ulaştığı sistemlere ulaşılabilirdi çünkü deployment'ta hiçbir şey ulaşılamaz olduklarını söylemiyordu.
Bu ayrım, nasıl karşılık vereceğimiz açısından önemlidir. Hata bir jailbreak olarak çerçevelenirse çözüm daha uzun bir reddetme listesi, daha güçlü bir system prompt, daha iyi bir classifier olur. Hata yanlış fiyatlandırılmış bir yetenek tahsisi olarak çerçevelenirse çözüm bir bütçedir: agent'ın neye ulaşabileceğinin açık, çalıştırma başına bir sayımı ve bunun modelin dışında uygulanması.
Prompt düzeyinde reddetme neden bir araya gelmez
Reddetme davranışı eğitilmiştir, olasılıksaldır ve deployment başına değil model başına değerlendirilir. Harici bir host'a bağlanma yönündeki doğrudan bir isteği reddeden bir model, aynı eylem daha büyük bir görevin alt adımı olarak çerçevelendiğinde ya da eylemin beklendiğini ima eden bağlamı zaten biriktirmiş bir tool-calling döngüsü tarafından üretildiğinde uyum sağlayabilir.
Daha da önemlisi, bir agent araçları adımlar arasında zincirlediğinde, geçerli politika orijinal prompt'un niyeti değil, her aracın izinlerinin birleşimidir. Rastgele URL'ler çekebilen bir tarayıcı aracı, rastgele komutlar çalıştırabilen bir shell aracı ve kimlik bilgileri ekleyebilen bir HTTP client birlikte, üçünün birleşimi olan bir erişilebilir küme üretir. Prompt bu birleşimi küçültmez. Yalnızca içinden tercih edilen bir yol önerir.
Prompt'ta yaşayan her kontrol, görev tamamlamayı optimize eden bir sisteme yapılmış bir öneridir. Öneriler davranışı yönlendirmek için faydalıdır; bir containment sınırı değildir. Bir containment sınırı, agent'ın hedefini paylaşmayan bir şey tarafından uygulanmalıdır — bir proxy, bir policy engine, bir sandbox supervisor.
Tasarım birimi olarak yetenek bütçesi
Pratik alternatif, erişilebilir kümeyi birinci sınıf bir artefakt olarak ele almak ve açıkça sınırlamaktır. Her çalıştırma için şunları sayın:
- Ağ hedefleri: hostname'ler, IP aralıkları, portlar, protokoller. "Web" değil, somut bir allowlist.
- Dosya sistemi yolları: okuma ve yazma ayrı ayrı, mümkün olduğunda mount flag'leriyle.
- Kimlik bilgili API'ler: hangi token'ların eklendiği, hangi scope'larla ve ne kadar süreyle.
Bunların birleşimi blast radius'tur. Tasarım sorusu "iyi bir reddetme yazdık mı?" değil, "bu çalıştırmanın blast radius'u nedir ve görevi hâlâ tamamlayan en küçüğü bu mu?"dur.
Blast radius'u sınırlamak, agent başına değil tool call başına allowlist anlamına gelir. Agent düzeyinde bir allowlist, her kompozisyon adımından sağ çıkan statik bir tahsistir. Call başına bir allowlist, kullanım noktasında yeniden değerlendirilir; kompozisyonun gerçekte gerçekleştiği yer burasıdır.
Bütçelerin sessizce genişlediği yer kompozisyondur
Somut bir mekanizma: agent runtime ile her giden tool call arasında bir policy proxy durur. Her call bir çalıştırma tanımlayıcısı taşır. Proxy, çalıştırmaya göre anahtarlanmış bir bütçe belgesi tutar; izin verilen hedefleri, yolları ve scope'ları listeler. Her call'da hedefi bütçeye karşı kontrol eder, kararı kaydeder ve ya iletir ya da reddeder.
Agent araçları bir araya getirdiğinde — örneğin bir tarayıcı sonucunu kullanarak bir shell komutu oluşturduğunda — birleştirilmiş eylem, yeni bir hedefe sahip yeni bir call'dır. Proxy bunu aynı bütçeye karşı değerlendirir. Birleştirilmiş hedef bütçede yoksa, agent ona nasıl ulaşmış olursa olsun call reddedilir. Prompt düzeyindeki kontrollere dayanan sistemlerde bütçelerin sessizce genişlediği nokta burasıdır: modelin bütçeye dair bir temsili yoktur, dolayısıyla ona uyamaz.
Faydalı bir disiplin, araç grafiği her değiştiğinde bütçeyi yeniden türetmektir. Bir araç eklemek, bir scope'u genişletmek veya yeni bir kimlik bilgisi eklemek artımlı bir yama değil, yeniden türetme tetiklemelidir. Bütçe, elle tutulan bir liste değil, türetilmiş bir artefaktır.
Dürüst ödünleşim
Sıkı bütçeler meşru görevleri bozar. Araştırma yapan bir agent'ın başlangıçtaki allowlist'te olmayan bir host'a ulaşması gerekebilir. Bir deployment'ta hata ayıklayan bir agent'ın orijinal scope dışındaki bir yola dokunan bir shell komutuna ihtiyacı olabilir. Sıkı bir bütçenin maliyeti operasyonel sürtünmedir: daha fazla reddetme, daha fazla insan incelemesi, daha fazla yeniden türetme döngüsü.
Alternatif — gevşek bir bütçe — çalıştırması daha ucuz ve savunması daha zordur. Ödünleşim, soyut olarak güvenlik ile yetenek arasında değil; şimdiki reddetmelerin maliyeti ile sonradan gelecek bütçe dışı bir başarının maliyeti arasındadır. Agent sistemleri sevk eden bir stüdyo, hangi maliyeti ödemeye raz
Kaçışı tespit edilebilir kılmak için ne loglanmalı
Tespit, doğru olayların loglanmasına bağlıdır. Üç kategori önemlidir:
- Reddedilen denemeler, yalnızca başarılı call'lar değil. Bir reddetme, agent'ın amaçladığı eylemin bütçesini aştığının sinyalidir. Reddetme oranı, yanlış fiyatlandırılmış bir bütçenin öncü göstergesidir.
- Her call için araç, hedef ve adım indeksi. Bir yörüngeyi yeniden oluşturmak için gereken minimum budur.
- Call anında yürürlükte olan bütçe belgesi. O olmadan bir yörünge, daha sıkı bir bütçeye karşı çevrimdışı yeniden oynatılamaz.
Yeniden oynatmayı mümkün kılan şey adım indeksidir. Bir yörünge ve bir bütçe verildiğinde, çevrimdışı bir yeniden oynatma şunu yanıtlayabilir: agent ilk kez hangi adımda bütçe dışı bir eylem denedi ve daha sıkı bir bütçe daha önce neyi reddederdi? Bu, bütçeleri canlı sistemlere karşı agent'ı yeniden çalıştırmaktan daha ucuz bir şekilde ayarlamanın yoludur.
Pratik bir kural: bütçe dışı her başarıyı bir olay bileti değil, bir sürüm engelleyici olarak ele alın. Bütçe dışı bir başarı, bütçe ile uygulamanın anlaşmazlığa düştüğü anlamına gelir; bu da kontrol düzleminde bir doğruluk hatasıdır. Anlaşmazlık anlaşılana kadar pipeline'ı durdurmalıdır.
Bunun pratikte değiştirdiği şey
Containment'ı bir yetenek bütçesi problemi olarak çerçevelemek, işi prompt mühendisliğinden politika mühendisliğine taşır. Teslimatlar değişir:
- Bir reddetme listesi değil, bir bütçe şeması ve bir türetme süreci.
- Agent başına değil, call başına allowlist uygulayan bir policy proxy.
- Reddetmeleri, hedefleri ve adım indekslerini yakalayan bir loglama pipeline'ı.
- Kaydedilmiş bir yörüngeyi aday bir bütçeye karşı yeniden değerlendirebilen bir yeniden oynatma aracı.
Bunların hiçbiri modelin işbirliğini gerektirmez. Mesele de bu. Model, görevi nasıl tamamlayacağı konusunda istediği kadar yaratıcı olabilir; hangi yolların erişilebilir olduğunu bütçe belirler. Reddetme listesi yönlendirme için hâlâ faydalıdır ama sınır değildir. Sınır bütçedir ve bütçe, bir ekibin inceleyebileceği, sürümleyebileceği ve sıkılaştırabileceği bir tasarım artefaktıdır.
Son olaylar, bir şey onu aşana kadar sınırın genellikle örtük olduğunu hatırlatıyor. Onu açık kılmak — çalıştırma başına, call başına, reddetmeler loglanarak — tasarım gereği containment altında olan bir sistem ile umutla containment altında olan bir sistem arasındaki farktır.