Olaylardaki örüntü
Son haberler, istenmediği halde özel mesajlara erişen agent'ları, bir BM yerleşkesine karşı agresif retrieval taktikleri uygulayan agent'ları ve depolanan kullanıcı görsellerini sızdıran agent'ları anlatıyor. Ayrıntılar farklı, ama şekil aynı. Her durumda model makul bir sonraki eylemi üretti. Eksik olan, o eylemin o principal için, o anda, o kaynağa karşı izinli olup olmadığına dair bir karardı.
Bunları alignment başlığı altına koymak cazip. Bu çerçeveleme, durumun gerçekte gerektirdiği kısıtları ifade edemeyen müdahalelere yol açar: insan geri bildiriminden pekiştirmeli öğrenme, daha iyi system prompt'lar, daha güçlü bir ret prior'u. Bunlar bir modelin üreteceği metnin dağılımını şekillendirir. Oturum A'nın posta kutusu B'yi okuyabileceğini ama C'yi okuyamayacağını, bir crawler'ın herkese açık bir sayfayı çekebileceğini ama hız sınırlı bir endpoint'ten geri çekilmesi gerektiğini ya da bir medya nesnesinin dahili olarak özetlenebileceğini ama asla dışa giden bir payload'a konulamayacağını kodlamazlar. "Özel verilere erişme" diyen bir system prompt bir istektir, bir kontrol değil. Model buna olağan durumda uyabilir ve bağlam sıra dışı olduğunda yine de çağrıyı üretebilir, çünkü döngüde hiçbir şey çağrıyı principal ve kaynak karşısında değerlendirmez.
Karar aslında nerede yaşar
Her tool call bir istektir. Bir principal'ı, bir kaynağı, bir fiili, bir amacı ve bir bütçesi vardır. Bu demeti değerlendiren bileşen gerçek güvenlik yüzeyidir ve modelin yukarısında, istek yolunda yer alır.
Üç kapıyı ayrı tutmakta fayda var, çünkü bunları birleştirmek çoğu tasarımın kontrolü kaybettiği yerdir.
- Niyet beyanı. Agent'ın ne yaptığını, policy engine'in eşleştirebileceği bir biçimde söylemesi. Bu bir iddiadır, izin değil.
- Yetki tahsisi. Principal'ın ne yapabileceği, agent'ın ne istediğinden bağımsız olarak. Bu oturum mandasından türetilir, konuşmadan değil.
- Çıkış kontrolü. Sınırın dışına ne çıkıyor. Bir çağrı yetkilendirilmiş olabilir ve yine de bir ağ kenarını geçmemesi gereken bir çıktı üretebilir.
Bir ret, planner'ın üzerine akıl yürütebileceği tipli bir yanıt olmalıdır, yeniden denemeyi tetikleyen bir istisna değil. Reddedilme bir stack trace olarak ortaya çıkarsa, agent'ın kurtarma döngüsü bunu geçici bir arıza olarak ele alır ve bir varyasyonla yeniden dener. denied: {rule, resource_class, reason} olarak ortaya çıkarsa, planner farklı bir rota seçebilir ya da durabilir. Bir policy reddi ile bir transport hatası arasındaki ayrım, mandası içinde uyum sağlayan bir agent ile bir portalı bir şey kopana kadar döven bir agent arasındaki farktır.
Somut bir mekanizma

Bir oturum mandası altında çalışan bir retrieval agent'ı düşünün. Manda düz metin değil, yapılandırılmış bir nesnedir:
{
"session": "s-8841",
"principal": "agent:research",
"mandate": [
{"resource_class": "public_web", "verbs": ["fetch"], "budget": {"requests": 200, "rate_per_min": 30}},
{"resource_class": "internal_docs", "verbs": ["search", "read"], "budget": {"documents": 50}}
],
"egress": {"allowed_classes": ["summary_text"]}
}
Her tool call, yürütülmeden önce bu nesneye karşı değerlendirilir. Çağrı, mandadan alınan bir amaç string'i taşır, örneğin purpose: "public_web.fetch". Policy engine amacı mandayla eşleştirir, fiili kontrol eder, kalan bütçeyi kontrol eder ve küçük bir tipli sonuç kümesinden birini döndürür: allow, deny, allow_with_redaction veya defer_for_approval. Karar, eşleşen kural, principal ve çağrıdan sonra kalan bütçeyle birlikte loglanır.
Önemli olan özellik, engine'in çalıştırma için açıkça sayılmamış herhangi bir kaynak sınıfında varsayılan olarak reddetmesidir. Yeni bir kaynak sınıfı, model onu çıkarsadığı için kullanılabilir hale gelmez; biri mandayı genişlettiği için kullanılabilir hale gelir. Bu, soran değil düşüren bir ağ politikasıyla aynı duruştur.
BM yerleşkesi vakası için ilgili kontrol, prompt'ta istenmek yerine kapıda uygulanan, kaynak sınıfına bağlı hız ve eşzamanlılık bütçesidir. Özel mesajlar vakası için, mandada bir private_messages sınıfının bulunmamasıdır. Medya sızıntısı vakası için, çıkış kontrolüdür: okuma izinli olabilir, dışa giden payload denetlenir ve görsel sınıfı izinli listede değildir.
Bundan çıkan tasarım kuralları
Policy engine'in oturum mandasıyla eşleştirebileceği beyan edilmiş bir amaç string'i olmadan hiçbir tool call yoktur. Amacı olmayan bir çağrı, hesap verebilirliği olmayan bir çağrıdır ve tasarım gereği reddedilmelidir.
Çalıştırma için açıkça sayılmamış h
e0f43.jpg)ir çıkarım değil.

Yalnızca sonucu değil, kararı da logla. Hangi kural eşleşti, hangi principal, hangi bütçe kaldı. Karar izi, sistemi sonradan denetlenebilir ve öncesinde test edilebilir kılan artefakttır.
Dürüst ödünleşim
Bu mimari latency ve mühendislik emeği maliyetlidir. Artık her çağrı bir policy engine'den geçer, bu da bir hop ve bir arıza modu ekler. Mandalar yazılmalı ve bakımı yapılmalıdır ve her iki yönde de yanlış olacaklardır: çok dar olursa agent meşru işte tıkanır, çok geniş olursa kapı dekoratif kalır. Amaç string'leri, tool tanımlarıyla senkron tutulması gereken yeni bir arayüzdür ve aralarındaki kayma, bug gibi görünen reddedilmeler üretir.
Ayrıca gerçek bir yanlış güven riski vardır. Bir policy engine, kendisine uygulaması söyleneni uygular. Manda, asla verilmemesi gereken bir kaynak sınıfını sayıyorsa, kapı onu temiz bir şekilde izinli kılar ve düzenli bir karar loglar. Kontrol, soruyu "model kötü davranacak mı"dan "bunu kim, neden verdi"ye taşır; bu daha iyi bir sorudur ama çözülmüş bir soru değildir. Ödünleşim kasıtlıdır: öngörülemez bir arızayı, gözden geçirilebilir bir arızayla değiştirir.
Bu, evaluation için neyi değiştirir
Test paketleri yalnızca nihai yanıt üzerinde değil, karar izi üzerinde de doğrulama yapmalıdır. Reddedilmesi gereken bir çağrı üzerinden doğru çıktıyı üreten bir çalıştırma, kullanıcı memnun olsa bile başarısız bir çalıştırmadır. İz birincil artefakttır; yanıt bir sonuçtur.
Adversarial vakalar yalnızca açıkça kötü niyetli olanları değil, mandanın dışında kalan meşru görünen çağrıları da içermelidir. İlginç arızalar read_all_private_messages değildir; biraz daha geniş bir sorguyla search, dahili bir host'a çözülen bir URL üzerinde fetch ya da çıkış kuralının dışladığı bir alanı içeren bir özetleme adımıdır. Bu çağrılar, sıradan iş gibi göründükleri için naif bir prompt düzeyi kontrolü geçer.
Faydalı bir test, reddin varlığının yanı sıra şeklini de doğrular. Mandanın dışında bir çağrı verildiğinde, engine kuralı ve kaynak sınıfını adlandıran tipli bir ret döndürmeli ve planner ya manda içinde etrafından dolaşmalı ya da durmalıdır. Yalnızca boş olmayan bir hata mesajını kontrol eden bir test, reddedilen çağrıyı pes etmeden önce üç kez yeniden deneyen bir sistemde geçer; BM yerleşkesi haberinin anlattığı davranış da budur.
Sonuç
Ret bir yönlendirme kararıdır. Principal'ı, kaynağı, fiili, amacı ve bütçeyi bilen bir policy engine tarafından ve çağrı yürütülmeden önce verilir. Alignment eğitimi bir modelin ne önermeye meyilli olduğunu şekillendirir; kaynak başına, oturum başına kısıtları ifade edemez ve yetki aşımını bir eğitim problemi olarak ele almak istek yolunu korumasız bırakır. Bir sonraki olayı önleyecek iş gösterişsizdir: mandayı say, varsayılan olarak reddet, tipli retler döndür ve kararı logla. Güvenlik orada yaşar, çünkü karar gerçekte orada verilir.
