Talimat katmanı bir kontrol yüzeyi değildir
Bir agent'a bir araç verildiğinde, prompt genellikle bir dizi kısıt taşır: birkaç e-postadan fazlasını gönderme, üretim kayıtlarını değiştirme, harcama eşiğini aşma. Bu kısıtlar tavsiye niteliğindedir. Bir context window içindeki token'lardır ve bir aracı çağırabilen bir model, onu prompt'un öngörmediği şekillerde çağırabilir. Model, izin verilen bir eylemi izin verilmeyen bir eyleme genelleyebilir, araçları beklenmedik bir sırayla zincirleyebilir veya uzun bir yörünge boyunca bir kısıtı takip etmeyi basitçe başaramayabilir. Prompt uygulatmaz; önerir.
Yetki ise bunun aksine modelin altında uygulatılır. Kimlik bilgisinde, token'ın kapsamında, endpoint üzerindeki rate limit'te ve erişimi yenilemek için gereken attestation'da yaşar. Bunlar modelin yeniden yorumlayabileceği talimatlar değildir. Runtime'ın uyguladığı kısıtlardır. Bir agent bir veritabanını silebilen bir kimlik bilgisi tutuyorsa, "veritabanını silme" diyen prompt bir umuttur, bir sınır değil. Pratik kontrol birimi izin verildi ya da verilmedi değildir. Ne kadar, ne sıklıkla ve hangi attestation altında olduğudur.
Bu ayrım, agent'lar tek turlu araç kullanımından uzun süre çalışan döngülere geçtikçe daha da önem kazanır. Bir döngüde modelin davranışı, kendisine söylenenle değil, yapabildikleriyle şekillenir. Kontrol yüzeyi, elinde tuttuğu yetenekler ve bu yetenekler üzerindeki sınırlardır. İşte bu yetki bütçesidir.
Prompt'lar neden yetki taşıyamaz
Bir prompt bir istektir. Bir kimlik bilgisi bir yetenektir. Bir agent bir aracı çağırdığında, araç prompt'u okumaz. Token'ı, kapsamı, kotayı ve çağırana bağlı politikayı kontrol eder. Token genişse, araç uyar. Prompt uygulama noktası için görünmezdir.
Yaygın bir örüntüyü düşünün: bir agent'a destek taleplerini özetlemesi söylenir ve ona talep durumunu da güncelleyebilen bir araç verilir. Prompt "yalnızca oku" der. Aracın API'si bir yazma parametresi kabul eder. Model, talebi çözme hedefini izleyerek bu parametreyi ayarlayabilir. Prompt yazma yetkisi vermedi, ama kimlik bilgisi verdi. Başarısızlık bir prompt başarısızlığı değil; bir yetki tasarımı başarısızlığıdır.
Aynısı hız ve hacim için de geçerlidir. Bir prompt "arama aracını idareli kullan" diyebilir. Endpoint'in kotası yoktur. Agent onu binlerce kez çağırabilir. Prompt idareli kullanmayı uygulatamaz. Yalnızca bir kota uygulatabilir.
Bu yüzden agent güvenliği, harcanabilir bir yetki ödeneği olarak daha iyi modellenir. Her yetenek; bir kapsam, bir kota, bir son kullanma ve bir yenileme koşulu içeren bir grant'tir. Model grant'i harcayabilir. Onu aşamaz. Uygulama noktası prompt değil; araç, gateway veya kimlik bilgisi vericisidir.
Bir yetki bütçesi tasarlamak
Bir yetki bütçesi her yeteneği sınırlandırılmış bir grant olarak ifade eder. Bir grant'in dört parçası vardır:
- Kapsam: yeteneğin ne üzerinde işlem yapabileceği. "E-posta" değil, "destek alan adındaki dahili alıcılara gönder." "Veritabanı" değil, "tickets tablosundaki satırları oku."
- Kota: ne kadar ve ne sıklıkla. Bir çağrı sayısı, bir veri hacmi, dakika başına bir hız, bir kaynağa karşı toplam harcama. Kotlar gateway'de uygulatılır.
- Son kullanma: grant'in ne zaman sona ereceği. Kısa ömürlü grant'ler, ele geçirilmiş veya hizasız bir agent'ın işlem yapabileceği pencereyi daraltır. Son kullanma yenilemeyi zorunlu kılar; bu da attestation için bir fırsattır.
- Attestation: grant'i yenilemek veya genişletmek için hangi kanıtın gerektiği. Bu bir insan onayı, ikinci bir agent'ın imzası, bir politika motoruna karşı kontrol veya önceki kotanın kapsam içinde harcandığına dair bir kanıt olabilir.
Bütçe planlayıcı için görünür olmalıdır. Agent üç yazma hakkı kaldığını ve son kullanmaya iki saat olduğunu görebiliyorsa, tükenme üzerine akıl yürütebilir. Önceliklendirebilir, erteleyebilir veya yenileme talep edebilir. Bütçe görünmezse, agent sınırları hata olarak keşfeder; bu da yeniden denemelere, etrafından dolanmalara ve öngörülemez davranışa yol açar. Görünürlük, sert bir duruşu bir planlama kısıtına dönüştürür.
Yetkiyi türüne göre ayırın. Okuma yetkisi düşük risklidir ve bir oturum içinde otomatik olarak yenilenebilir. Yazma yetkisi daha yüksek risklidir ve daha dar bir kapsam ile daha kısa bir son kullanma gerektirmelidir. Geri alınamaz yetki, örneğin harici bir iletişim göndermek, veri silmek veya fon transfer etmek, her çekiş için açık attestation veya insan döngüde olacak şekilde çok küçük bir kota gerektirmelidir. Yenileme yolları buna göre farklılaşmalıdır: okuma grant'leri orkestratör tarafından yenilenebilir; yazma grant'leri bir politika kontrolüyle; geri alınamaz grant'ler bir insan veya bir kurul tarafından.
Somut bir mekanizma: agent ile araçlar arasında bir yetki gateway'i yer alır. Agent bir grant token'ı sunar. Gateway token'ı doğrular, kapsamı istenen eyleme karşı kontrol eder, kotayı düşürür ve çekişi loglar. Kota tükendiyse veya kapsam aşıldıysa, gateway orkestratörün yorumlayabileceği yapılandırılmış bir ret döndürür. Token, kapsamı, kotayı, son kullanmayı ve attestation gereksinimlerini kodlayan bir kimlik bilgisi servisi tarafından verilir. Model alttaki kimlik bilgilerini asla görmez; yalnızca grant'i ve kalan bütçesini görür.
Bu yeni bir fikir değildir. Bulut IAM, API rate limiting ve yetenek tabanlı güvenliğin zaten çalıştığı yoldur. Katkı, agent'ın yetkisini planlayıcının üzerine akıl yürütebileceği ve runtime'ın uygulatabileceği birinci sınıf, harcanabilir bir kaynak olarak ele almaktır.
Operasyonel sonuçlar
Yetki bir bütçe olduğunda, olay müdahalesi değişir. Bir sistem prompt'unu yeniden yazıp modelin uyacağını ummak yerine, operatörler bir grant'i iptal eder. İptal anında ve uygulatılabilirdir. Agent yalnızca talimatı değil, yeteneği kaybeder. Olay, hasarın oluşacağı yer olan kimlik bilgisi katmanında sınırlandırılır.
Denetim çıktısı, bütçelere karşı çekişlerin bir defteri haline gelir. Her satır grant'i, kapsamı, eylemi, kalan kotayı ve attestation'ı kaydeder. Bu defter, ML dışı gözden geçirenler için okunabilirdir: güvenlik, uyum ve operasyon ekipleri modelin iç işleyişini anlamadan okuyabilir. Agent'ın ne yaptığını, hangi yetki altında yaptığını ve sınırlar içinde kalıp kalmadığını görebilirler. Bir grant'in ne zaman ve hangi kanıtla yenilendiğini de görebilirler.
Bütçe tükenmesi birinci sınıf bir agent durumu haline gelir. Orkestrasyon katmanı bunu açıkça ele almalıdır: duraklat, yenileme talep et, daha düşük yetkili bir moda düş veya sonlandır. Tükenmeyi yeniden denenecek bir hata olarak ele almak, etrafından dolanma için bir reçetedir. Onu yönetilecek bir durum olarak ele almak, agent'ı yetkisi içinde tutar.
Ödünleşim ek yüktür. Yetki bütçeleri bir gateway, bir kimlik bilgisi servisi ve bir defter gerektirir. Araç çağrılarına latency, orkestrasyon katmanına karmaşıklık ekler. Ekipleri kapsamları ve kotları önceden tanımlamaya zorlar; bu, prompt'ların gerektirmediği bir iştir. Bir prototip için bu gereksiz olabilir. Gerçek sistemlere yazma erişimi olan bir üretim agent'ı için bu ek yük, gerçekten kontrol eden bir kontrol yüzeyinin bedelidir.
İkinci bir ödünleşim esnekliktir. Sıkı kapsamlı bir grant, agent'ın bir görevi tamamlamak için ihtiyaç duyduğu meşru bir eylemi engelleyebilir. Agent o zaman yenileme talep etmelidir; bu da insan onayı gerektirebilir. Bu döngüyü yavaşlatır. Alternatif, eyleme ve diğer her şeye izin veren geniş bir grant'tir. Tasarım seçimi, özerklik ile gözetim arasındaki sınırın nereye konacağıdır. Yetki bütçeleri bu seçimi, modelin bir prompt yorumuna bırakmak yerine açık ve uygulatılabilir kılar.
Sonuç
Prompt'lar niyeti tanımlar. Yetki davranışı sınırlar. Bir döngüde model, kullanması söyleneni değil, kullanabildiğini kullanır. Eksik kontrol yüzeyi yetki bütçesidir: kapsam, kota, son kullanma ve attestation içeren, planlayıcı için görünür ve gateway'de uygulatılan harcanabilir bir ödenek. Bu, güvenliği talimat katmanından kimlik bilgisi katmanına kaydırır; orada iptal edilebilir, denetlenebilir ve üzerine akıl yürütülebilir. Bir prompt'tan daha az elverişlidir. Aynı zamanda bir agent'ın davranmasını ummak ile aksini yapamayacağını garanti etmek arasındaki farktır.