Görevsiz Kimlik: Ajan Başına Kimlik Bilgileri Neden Hâlâ Fazla Yetki Veriyor

İyileştirme ve durduğu yer

Bir AI ajanına görevi bittiğinde süresi dolan bir kimlik bilgisi verin; erişim yönetimindeki en eski sorunlardan birini ortadan kaldırmış olursunuz: bir yapılandırma dosyasında duran, aylarca geçerli olan ve ajan süreci gittikten çok sonra bile saldırganın işine yarayan uzun ömürlü bearer token. 1Password tarzı çerçeveleme ve daha geniş IAM-for-agents önerileri bu yönde ilerliyor. Kimlik bilgileri görev başına üretilir, bir oturuma bağlanır ve görev kapandığında iptal edilir. Sızdırılmış bir token'ın işe yaradığı pencere aylardan dakikalara iner. Bu gerçek bir kazançtır.

Aynı zamanda bu kazanç, çoğu güvenlik incelemesinin aslında önemsediği soruyla dikey olarak ilgisizdir: bu kimlik bilgisi hayattayken neye erişebilir? Beş dakikalık ömrü olan ve * üzerinde s3:GetObject yetkisine sahip görev kapsamlı bir token, yine de tüm bucket'a açılan beş dakikalık bir penceredir. Ömür dardır. Kapsam değildir. Ve kapsam, kimlik bilgisini veren sistemin kendi başına karar verdiği bir şey değildir — daha önce, farklı bir bileşen tarafından, farklı bir sözlükle verilmiş bir karardan miras alınır.

Kapsam, ayrıştırmanın bir çıktısıdır

Bir orkestratörün bir alt ajana verebileceği iki talimatı düşünün:

subtask: reconcile the account
subtask: read invoice 4417

Birincisi meşru ve yaygın bir istektir. Aynı zamanda, erişim kontrolü açısından, faturalama defterine, ödeme sağlayıcısına, müşteri kaydına ve mutabakat mantığının dokunduğu her şeye okuma erişimi talebidir. İkincisi tek bir belge talebidir. Her ikisi de "görev"dir. Niyetin tanımı olarak hiçbiri diğerinden daha doğru değildir. Ancak son derece farklı genişlikte kimlik bilgileri üretirler ve kısa ömürlü token'ı üreten sistem — birincinin tembel bir ayrıştırma, ikincinin ise dikkatli bir ayrıştırma olduğunu bilemez. Bir görev tanımlayıcısı ve istenen bir kapsam görür; kapsam göreve uyuyorsa verir.

Başka bir deyişle, planlayıcı, kimse onu öyle görse de görmese de erişim kontrolü yapıyor. "Müşteri şikayetini ele al"ı "talebi oku, siparişi oku, iade yap" olarak böldüğünde, sürünün hangi kimlik bilgilerine ihtiyaç duyacağına karar vermiş olur. Aynı isteği "talebi oku, siparişi oku, ödeme geçmişini oku, kargo kaydını oku, hesap notlarını oku" olarak böldüğünde ise daha geniş bir şeye karar vermiş olur. Aşağı akıştaki IAM katmanı bir formalitedir; asıl karar yukarı akışta, çoğu ekibin hâlâ orkestrasyon olarak tanımladığı bir bileşende verilmiştir.

Görev başına kimlik bilgisi modelinin ele almadığı kısım burasıdır. Ömür sorununu düzeltir çünkü ömür, vericinin kontrol ettiği bir özelliktir. Kapsam sorununu düzeltmez çünkü kapsam, ayrıştırmanın bir özelliğidir ve ayrıştırma, en az yetki ilkesi üzerine akıl yürüten bir politika motoru tarafından değil, kullanıcı isteği üzerine akıl yürüten bir dil modeli tarafından üretilir.

Denetlenebilirliğin gerektirdiği şey

Kapsam ayrıştırmaya bağlıysa, erişimi denetlemek ayrıştırmayı denetlemek anlamına gelir. agent-7 requested scope X, granted scope X kaydını tutan bir token verme günlüğü, bir gözden geçirene X'in haklı olup olmadığı hakkında hiçbir şey söylemez. Biçimsel adımı kaydeder, asıl olanı atlar.

Bundan çıkan tasarım kuralı karmaşık değildir, ancak kulağa geldiğinden daha müdahaleci. Her kimlik bilgisi isteği iki tanımlayıcı taşımalıdır: ait olduğu alt görev ve o alt görevi üreten üst plan düğümü. İstenen kapsam, beyan edilen alt görevin makul olarak ihtiyaç duyabileceğini aşıyorsa verme reddedilmelidir — ve burada "makul olarak", ayrıştırmanın karşılaması gereken bir politikayı ifade eder, vericinin anlık olarak verdiği bir yargıyı değil. Verildiğinde ise, onu motive eden ayrıştırmayla birlikte günlüğe kaydedilmelidir; böylece bir gözden geçiren akıl yürütmeyi yeniden kurabilir: bu token var çünkü plan düğümü P, alt görev S'i doğurdu ve S, fatura 4417 ile kapsamlandırıldı ve token fatura 4417'yi okuyabilir.

{
  "plan_node": "P-118",
  "subtask": "S-118-3",
  "intent": "read invoice 4417",
  "requested_scope": ["billing:invoices:read:4417"],
  "granted_scope": ["billing:invoices:read:4417"],
  "parent_scope_ceiling": ["billing:invoices:read:*"]
}

parent_scope_ceiling alanı önemli olandır. Plan düğümünün çocuklarına dağıtmasına izin verilen maksimum kapsamdır ve kimlik bilgisi istendiğinde değil, plan oluşturulduğunda ayarlanır. Bu, gözden geçirene kontrol edecek iki şey verir: alt görevin üst öğesinin tavanı içinde kalıp kalmadığı ve üst öğenin tavanının kendisinin orijinal istek tarafından haklı çıkarılıp çıkarılmadığı. İkinci kontrol, "hesabı mutabık kıl"ın "her şeyi oku" anlamına geldiğine sessizce karar vermiş bir planlay![Close-up of r

Dikkat edilmesi gereken başarısızlık modu kötü niyetli bir ajan değildir. Yardımcı olan bir ajandır. Bir ajan bir izin hatasıyla karşılaşır — fatura 4417'yi okumaya çalıştı ve kapsam billing:invoices:read:4417 idi ama fatura farklı bir sistemde yaşıyor ya da mutabakat için ödeme kaydı da gerekiyor — ve yeniden dener. Yeniden deneme mantığının kapsamı genişletmesine izin verilirse, ajan kapsamı genişletir. Bu, ajandaki bir hata değildir; ajanın yaptığı şeyi yapmasıdır, yani hedefin peşinden gitmesidir. Hata, bir izin hatasını daha fazla izin talebi olarak gören, ayrıştırmanın yanlış olduğuna dair bir sinyal olarak görmeyen yeniden deneme politikasındadır.

Yeniden denemede kapsam sızması, bir günlük satırı değil, birinci sınıf bir olay sinyali olmalıdır. Somut olarak: orijinal alt görevin kapsamından kesinlikle daha büyük bir kapsam isteyen bir yeniden deneme, kapalı başarısız olmalı, bir olay yaymalı ve planın, duvara çarpan ajan dışında bir bileşen tarafından yeniden ayrıştırılmasını gerektirmelidir. Düzeltme, yeniden ayrıştırmadır. Genişletilmiş verme ise başarısızlıktır. Sistem ikisi arasındaki farkı söyleyemezse, eninde sonunda genişletilmiş kapsamı verir çünkü bu, teslim tarihi yaklaşan bir ajan için en az dirençli yoldur.

Dürüst ödünleşim

Bunların hiçbiri bedava değildir. Her kimlik bilgisi isteğinin bir alt görev tanımlayıcısı ve bir plan düğümü tavanı taşımasını gerektirmek, planlayıcının serbest metin görev tanımları değil, yapılandırılmış ayrıştırmalar üretmesi gerektiği anlamına gelir. Orkestrasyon katmanının kapsam ek açıklamalarıyla bir plan grafiği tutması ve bu grafiğin sürümlenmesi ve denetlenebilir olması gerektiği anlamına gelir. Bazı meşru görevlerin başarısız olacağı anlamına gelir çünkü ayrıştırma çok kaba olmuştur ve ajan kendi kapsamı içinde kendini düzeltemez — ve bu başarısızlığa doğru yanıt, daha geniş bir token değil, daha yavaş, insan tarafından görülebilen bir yeniden plandır.

Ödünleşim budur: ayrıştırma yanlış olduğunda daha fazla sürtünme pahasına daha dar kapsam. Alternatif — görev düzeyinde kapsamlı, "görev"in planlayıcının yazdığı her neyse o olduğu ajan başına kimlik bilgileri — en az yetkinin görünümünü ve planlayıcının canı ne istediyse onun özünü verir. Görev kapsamlı kimlik bilgileri bir iyileştirmedir. Kapsam sorununun çözümü değildirler çünkü kapsam sorunu bir kimlik bilgisi sorunu değildir. Bir ayrıştırma sorunudur ve bir katman yukarıda yaşar.

Ne inşa edilmeli

• Planlayıcıyı güvenlikle ilgili bir bileşen olarak ele alın. Çıktıları erişim kontrolü kararlarıdır.
• Her kimlik bilgisi isteğinde alt görev ve üst plan tanımlayıcılarını zorunlu kılın.
• Kimlik bilgisi verilirken değil, plan oluşturulurken ayarlanan bir üst kapsam tavanını uygulayın.
• Gerekçenin yeniden kurulabilmesi için ayrıştırmayı vermeyle birlikte günlüğe kaydedin.
• Daha geniş kapsamla yeniden denemede kapalı başarısız olun ve başarısızlığı daha geniş bir vermeye değil, yeniden ayrıştırmaya yönlendirin.

Kimlik bilgisi, yalnızca onu üreten görev kadar dardır. Görev yanlış ayrıntı düzeyinde ifade edilirse, kimlik bilgisi de öyle olacaktır.