Bildirilen örüntü
Agent sistemleri, şirket verilerine erişim gerektiren görevleri yerine getirmek için giderek daha fazla kullanılmaktadır: depoları okuma, veritabanlarını sorgulama, dahili API'leri çağırma. Operasyonel incelemelerde sıkça gözlemlenen bir durum, bir agent'ın çalıştırması sona erdikten sonra kimlik bilgilerinin geçerli kalmaya devam etmesidir. Agent artık yürütme yapmıyor, ancak kullandığı token veya anahtar hâlâ erişim sağlıyor. Bu bir işe alım veya çıkış sorunu değildir. Boşluk, görev tamamlanması ile kimlik bilgisi sona erme tarihi arasındadır.
Geleneksel insan iş akışlarında erişim, bir kişinin rolüne bağlıdır ve periyodik olarak gözden geçirilir. Agent iş akışlarında erişim bir göreve bağlıdır, ancak kimlik bilgisi yaşam döngüsü genellikle statik sırlardan veya uzun ömürlü servis hesaplarından miras alınır. Sonuç, verildikleri işten daha uzun yaşayan bir kimlik bilgisi sınıfıdır.
TTL'ler neden yanlış ilkel yapıdır
Sabit bir yaşam süresi (TTL), bir görevin ne kadar süreceğine dair bir tahmindir. Agent çalıştırmaları düzensizdir: saniyeler içinde tamamlanabilir veya bir hız sınırı, insan onayı ya da harici bir olay beklerken dakikalarca durabilir. Hızlı bir sorgu için güvenli olacak kadar kısa bir TTL, meşru uzun süreli bir işin ortasında sona erer. En kötü durumu kapsayacak kadar uzun bir TTL ise gereksiz erişim için geniş bir pencere bırakır.
Checkpointing kullanan uzun süreli agent'lar, makul herhangi bir TTL'den daha uzun yaşayabilir. Bir agent durumu kaydedip daha sonra devam ettiğinde, orijinal kimlik bilgisi sona ermiş olabilir ve yenileme gerektirir. Yenileme otomatikse ve görevi yeniden yetkilendirmiyorsa, kimlik bilgisi fiilen süresiz olarak uzatılır. TTL bir formaliteye dönüşür: gözden geçirilmeden yenilenen kısa ömürlü bir kimlik bilgisi, ekstra adımlarla kalıcı bir kimlik bilgisidir.
Daha derin sorun, TTL'lerin zamanı ölçmesi, yetkiyi ölçmemesidir. "Ne kadar süre?" sorusunu yanıtlarlar, ancak "ne için?" veya "kimin kontrolünde?" sorusunu yanıtlamazlar. Görevini on saniyede bitiren bir agent ile on saat çalışan bir agent aynı kimlik bilgisi sınıfını alır, sadece farklı sona erme zaman damgalarıyla.
Yetkiyi çalıştırmaya bağlamak
Daha sağlam bir model, kimlik bilgilerini çalıştırma tanımlayıcısına ve beyan edilen göreve bağlar. Sabit sona erme tarihli bir token vermek yerine, orkestratör yalnızca çalıştırma aktifken ve yalnızca görev spesifikasyonunda beyan edilen işlemler için geçerli bir kimlik bilgisi verir. Kimlik bilgisi her yerde kullanılabilecek bir bearer token değildir; belirli bir çalıştırmaya ve belirli bir eylem kümesine kapsamlandırılmış bir yetenektir.
İptal yetkilisi olarak orkestratör
Çalıştırmayı başlatan orkestratör, kimlik bilgisini iptal edebilen yetkili de olmalıdır. Çalıştırma sona erdiğinde — tamamlanma, başarısızlık veya iptal yoluyla — orkestratör çalıştırmayı pasif olarak işaretler. O çalıştırma tanımlayıcısıyla sunulan herhangi bir kimlik bilgisi reddedilir. Bu, varsayılanı tersine çevirir: sistem sona erme tarihine güvenmek yerine canlılığa güvenir. Canlı çalıştırma yoksa, geçerli kimlik bilgisi de yoktur.
Yeni bir yetkilendirme olayı olarak devam etme
Bir agent bir checkpoint'ten devam ettiğinde, yeni bir yürütme bağlamı başlatıyordur. Orkestratör bunu yeni bir yetkilendirme olayı olarak ele almalıdır: görevi yeniden değerlendirmeli, devam eden çalıştırmaya kapsamlandırılmış bir kimlik bilgisi yeniden vermeli ve orijinal çalıştırmayla aynı politika kontrollerini gerektirmelidir. Bu, bir checkpoint'in süresiz erişim için arka kapı hâline gelmesini önler. Ödünleşim, eklenen gecikme ve karmaşıklıktır: her devam etme bir yetkilendirme gidiş-dönüşü gerektirir ve orkestratör hangi çalıştırmaların aktif olduğuna dair durumu korumalıdır. Yüksek frekanslı, kısa ömürlü agent'lar için bu ek yük kabul edilebilir olabilir; gecikmeye duyarlı pipeline'lar için bilinen görev örüntüleri için önbellekleme veya ön yetkilendirme gerekebilir.
Somut mekanizma: çalıştırma kapsamlı token'lar
Pratik bir uygulama, çalıştırma tanımlayıcısını, görev kapsamını ve bir orkestratör imzasını içeren imzalı bir token kullanır. Token, iki şeyi kontrol eden bir politika uygulama noktasına (PEP) sunulur: imza geçerlidir ve çalıştırma tanımlayıcısı orkestratörün durum deposunda aktif olarak işaretlenmiştir. PEP yalnızca token'ın sona erme tarihine güvenmez. Orkestratör çalıştırmayı sonlandırılmış olarak işaretlediyse, sona erme tarihi gelecekte olsa bile token reddedilir. Bu mekanizma, orkestratör ile PEP arasında paylaşılan bir durum deposu ve önem taşıyacak kadar hızlı bir iptal yolu gerektirir. Ödünleşim, orkestratörün kullanılabilirliğine bağımlılıktır: durum deposuna ulaşılamıyorsa, PEP açık mı yoksa kapalı mı başarısız olacağına karar vermelidir. Kapalı başarısız olmak daha güvenlidir a
Tespit
Çalıştırma kapsamlı kimlik bilgileriyle bile tespit gereklidir. Denetim günlükleri, veren çalıştırma sona erdikten sonra kullanılan kimlik bilgilerini işaretlemek için enstrümante edilmelidir. Kimlik bilgisi çalıştırma tanımlayıcısını taşıyorsa bu basit bir sorgudur: kimlik bilgisi kullanım günlüğünü çalıştırma yaşam döngüsü günlüğüyle birleştirin ve çalıştırmanın kullanım zaman damgasından önce sona erdiği kullanım olaylarını bulun.
İkinci bir metrik, son tool call ile kimlik bilgisi sona erme tarihi arasındaki boşluktur. Sağlıklı bir sistemde, tamamlanan çalıştırmalar için bu boşluk sıfıra yakın olmalıdır: kimlik bilgisi çalıştırma sona erer ermez geçersiz hâle gelmelidir. Kalıcı bir boşluk, kimlik bilgilerinin yenileme, önbellekleme veya iptal edilememe yoluyla çalıştırmalarından daha uzun yaşadığını gösterir. Bu boşluğun zaman içinde izlenmesi, iptal yolundaki gerilemeleri ortaya çıkarır.
Üçüncü bir sinyal, yeniden yetkilendirmeyi tetiklemeyen devam etme olaylarının oranıdır. Checkpoint'ler yeni bir yetkilendirme olayı olmadan erişimi uzatmak için kullanılıyorsa, bu denetim izinde görünmesi gereken bir politika ihlalidir.
Operasyonel gerçeklik
Çalıştırma kapsamlı kimlik bilgileri ve orkestratör tabanlı iptal uygulamak bedava değildir. Agent'ların erişimi nasıl talep ettiği, orkestratörün çalıştırma durumunu nasıl izlediği ve politika uygulama noktalarının kimlik bilgilerini nasıl doğruladığı konusunda değişiklikler gerektirir. Orkestratörün canlılığına bir bağımlılık ve durum deposunda potansiyel bir darboğaz getirir. Güvenilir durum yönetimine sahip merkezi bir orkestratörü zaten olan sistemler için değişiklik kademelidir. Agent'ların alt agent'lar oluşturduğu veya birden fazla orkestratör arasında çalıştığı sistemler için durum senkronizasyonu daha karmaşık hâle gelir.
Alternatif — TTL'lere ve periyodik incelemelere güvenmek — uygulaması daha basittir ancak yapısal bir boşluk bırakır. Boşluk, işe alım ve çıkış arasında değildir; görev tamamlanması ile kimlik bilgisi sona erme tarihi arasındadır. Bu boşluğu kapatmak, kimlik bilgilerini zamanlayıcılı sırlar olarak değil, bir çalıştırmaya bağlı yetenekler olarak ele almayı gerektirir.