Sandbox Sözleşmeleri: Bir Agent Üretim Uç Noktasına Dokunmadan Önce Neyi Kanıtlamalı

Arıza deseni: yetki verildi, niyet doğrulanmadı

Bu tekrarlayan bir desendir. Bir agent bir sistemi tarama yetkisine sahiptir, sonra o sistem üzerinde işlem yapar. Ya da bir kaydı okuma yetkisine sahiptir, sonra bir kayıt yazar. Olayların çoğu, agent'a verilen fiil ile gerçekte yürüttüğü fiil arasındaki bu boşlukta yaşar. Yetki genellikle örtüktür: okuma-yazma kapsamlı bir kimlik bilgisi, genel bir http_request imzasına sahip bir tool, bir ağ segmentindeki her şeye erişebilen bir servis hesabı. Niyet ise genellikle doğrulanmamıştır: "bu belirli çağrının, bu belirli uç noktaya karşı, bu belirli payload ile, süreçten çıkmadan önce kontrol edildiğini" söyleyen hiçbir artefakt yoktur.

Sonradan yapılan loglama bu boşluğu kapatamaz. Loglar ne olduğunu söyler; çağrıyı reddetmez. Bir agent ile bir üretim uç noktası arasındaki tek kontrol bir system prompt'taki bir cümleyse, o kontrol tavsiye niteliğindedir. Dağılım kayması altındaki bir model, getirilen bir belgede taşınan bir prompt injection veya sapmış bir planner, tavsiyeyi bir öneri olarak değerlendirir. Reddin, agent'ın itiraz edemeyeceği bir yerde gerçekleşmesi gerekir.

Bir sandbox sözleşmesinin dört maddesi vardır

Sandbox sözleşmesi, bir tool sınırına bağlı, makine tarafından kontrol edilebilir bir ön koşuldur. Bir politika belgesi değil, bir prompt da değildir. Dört maddesi vardır ve dördü de modelin dışında uygulanır.

Kapsam

Kapsam, agent'ın kullanabileceği uç noktaların ve fiillerin tam kümesidir ve bir allowlist olarak ifade edilir. Bir denylist başarısız olur çünkü her tehlikeli eylemi numaralandırması gerekir ve tehlikeli eylemlerin uzayı açık uçludur. Bir allowlist ise kapalı başarısız olur: adı geçmeyen her şey reddedilir. Somut olarak kapsam, (method, host, path-pattern, credential-id) gibi tuple'lardan oluşan bir kümedir ve istek oluşturulmadan önce eşleştirilir. Serbest biçimli bir URL sunan bir tool kapsamlandırılmamıştır; fazladan adımları olan bir proxy'dir.

Hız ve etki alanı

Hız, pencere başına kaç çağrıya izin verildiğidir; etki alanı ise ilk anormallikte ne olacağıdır. İkisi birlikte ele alınır çünkü yavaş bir sızıntı ile bir patlama farklı arıza modlarıdır. Bir sözleşme, uç nokta sınıfı başına bir token bucket ve ilk sözleşme ihlalinde yumuşak bir uyarı yerine sert bir durma belirtmelidir. Dürüst ödünleşim şudur: sıkı limitler meşru toplu işleri bozar, bu yüzden ekipler ya önemsiz kalacak kadar gevşek ya da kullanılamayacak kadar sıkı tek bir global hız yerine, kendi sözleşmesini taşıyan az sayıda önceden onaylanmış toplu işlemle sonuçlanır.

Geri döndürülebilirlik

Bir tool'un gerçekleştirebileceği her eylem idempotent, telafi edilebilir veya yasak olarak sınıflandırılmalıdır. İdempotent eylemler (bir okuma, bir arama) serbestçe yeniden denenebilir. Telafi edilebilir eylemler (silinebilen bir oluşturma, geri çekilebilen bir mesaj) varsayılmayan, test edilmiş tanımlı bir telafi yoluna ihtiyaç duyar. Yasak eylemler (geri döndürülemez ödemeler, kimlik bilgisi rotasyonu, toplu silme) planner ne kadar kendinden emin olursa olsun asla bir agent'a devredilmez. Bu madde, "agent bir hata yaptı" durumunu bir olaydan bir geri alma işlemine dönüştüren şeydir.

Attestation

Attestation, bir sonraki adımın kilidinin açılmasından önce agent'ın döndürmesi gereken kanıttır. Çoğu ekibin atladığı madde budur ve sözleşmeyi bir filtre değil bir sözleşme yapan da bu maddedir. Bir yazma işlemi commit edilmeden önce agent yapılandırılmış bir kayıt döndürür: sözleşme id'si, çözümlenen uç nokta, payload'ın bir hash'i, dry-run diff'i ve kullanılan kimlik bilgisinin kimliği. Gateway bu kaydı sözleşmeye karşı doğrular ve ancak ondan sonra gerçek çağrı için kimlik bilgisini verir. Attestation olmadan gateway kapsamı uygulayabilir ama planlanmış bir eylemi

System prompt'ta değil, tool gateway'de uygulayın. Prompt'lar tavsiye niteliğindedir; gateway'ler değildir. Gateway, kimlik bilgilerini tutan, uç noktayı çözümleyen ve çağrının devam edip etmeyeceğine karar veren süreçtir. Agent, gateway'den geçmeden uç noktaya ulaşabiliyorsa, sözleşme dekoratiftir.

Egress ve kimlik bilgisi verme işlemini ayrı kararlar olarak ele alın. Egress kontrolü "bu süreç bu host'a bir bağlantı açabilir mi?" sorusunu yanıtlar. Kimlik bilgisi verme ise "bu belirli istek, host'un kabul edeceği bir token alıyor mu?" sorusunu yanıtlar. İkisini ayrı tutmak, ele geçirilmiş bir planner'ın kendi kapsamını genişletememesi anlamına gelir: bir host'a ulaşabilir ama sözleşmesi dışındaki bir eylem için kimlik bilgisi elde edemez. Bu, bir ağ politikası ile bir yetenek sistemi arasındaki farktır ve çoğu agent framework'ünün şu anda yanlış yaptığı kısım budur.

Kabul edilen her sözleşmenin imzalı bir kaydını tutun. Bir olay gerçekten meydana geldiğinde, inceleme bir arkeoloji projesi değil bir sorgu olmalıdır. Sözleşme id'si, agent kimliği, attestation hash'i ve kararın (izin/ret) imzalı, yalnızca eklenebilir bir log'u, çalışmayı deterministik olarak yeniden oluşturmanızı sağlar. Ayrıca düzenleyicilerin ve olay müdahale ekiplerinin gerçekte sorduğu soruyu yanıtlamanızı sağlar: "model ne söyledi?" değil, "agent'ın ne yapmasına izin verilmişti ve yapmadan önce neyi kanıtladı?"

Ekiplerin bu çeyrekte yapması gerekenler

Bir agent'ın çağırabileceği her tool'u numaralandırın ve her birini okuma, yazma, harcama veya yayınlama olarak işaretleyin. Bu, genellikle kimsenin beklemediğinden daha fazla yetenek ortaya çıkaran tek oturumluk bir alıştırmadır. Sınıflandırma sözleşmeyi yönlendirir: okuma tool'ları kapsam ve hız alır; yazma, harcama ve yayınlama tool'ları ek olarak geri döndürülebilirlik ve attestation alır.

Yazma ve harcama tool'ları için commit öncesi bir dry-run modu ve insan tarafından görülebilir bir diff zorunlu kılın. Dry-run, commit adımı stub'lanmış halde gerçek çağrıyla aynı kod yolunu çalıştırmalıdır. Diff, bir insanın veya otomatik bir denetleyicinin incelediği artefakttır. Bir tool bir diff üretemiyorsa, devredilmeye hazır değildir.

Bir containment tatbikatı yapın: çalışma ortasında bir kimlik bilgisini iptal edin ve agent'ın kapalı başarısız olduğunu doğrulayın. Beklenen davranış, uç noktayı döven bir yeniden deneme döngüsü veya başka bir kimlik bilgisi bulan bir fallback değil, temiz bir durma ve tipli bir hatadır. Bu tatbikat ucuzdur, modeli değil gateway'i test eder ve kapalı başarısız olan bir sistem ile yalnızca bir arızayı loglayan bir sistem arasındaki farkı ortaya çıkarır.

Medicare olayı, containment'ın modelin bir özelliği olmadığını hatırlatır. Bu, sınırın bir özelliğidir: agent'ın çalışma zamanında pazarlık edemeyeceği altyapı tarafından uygulanan bir dizi açık ön koşul. Sınırı tasarımın birimi olarak ele alan ekipler, çoğu agent olayının olay olmaktan çıkıp reddedilen çağrılara dönüştüğünü görecektir.