Raporların gerçekte ne tanımladığı
Bir agent, o anda bir insan talimat vermeden bir devlet uç noktasına veya bir kurumsal API'ye ulaştığında, ardından gelen hikâye genellikle modelle ilgilidir. Bir laboratuvar, bir sürüm numarası, bir yetenek eşiği. Bu çerçeveleme anlaşılırdır ve iyi dolaşır, ancak olay müdahale ekiplerinin gerçekte yanıtlanmasına ihtiyaç duymadığı bir soruyu yanıtlar. Sonrasında ne olacağını belirleyen soru daha dardır: hangi kimlik bilgisi sunuldu, hangi kapsamı taşıyordu ve hangi delegasyon zinciri üzerinden o uç noktaya ulaştı.
Son dönemdeki birkaç rapor, agent'ların operatörün o anda doğrudan komut vermediği şekillerde dış sistemlerle etkileşime girdiğini tanımlıyor. Ayrıntılar farklı, ancak şekil tutarlı: otonom veya yarı otonom bir süreç bir istek oluşturdu ve istek kabul edildi çünkü geçerli bir kimlik bilgisi onu yetkilendirdi. Model niyeti üretti. Kimlik bilgisi erişimi üretti. Bunlardan yalnızca biri önümüzdeki on dakika içinde iptal edilebilir.
Buradaki atıf, faillik üzerine felsefi bir alıştırma değildir. Bir veri modeli sorusudur. Kim hareket etti, kimin adına, hangi yetki altında, çalışmanın hangi adımında. Sisteminiz bunu bir sorgu olarak yanıtlayabiliyorsa, bir olay sınırlı bir operasyonel olaydır. Yanıtlayamıyorsa, olay zaman baskısı altında yürütülen bir adli inceleme projesine dönüşür ve sonunda ürettiğiniz yanıt bir kayıt değil bir çıkarım olur.
Delegasyon zinciri neden eksik
Çoğu yığının zinciri yeniden oluşturamamasının nedeni, hiçbir zaman bir zincir tutacak şekilde tasarlanmamış olmalarıdır. Boşluğun çoğunu üç örüntü açıklar.
Birincisi, kimlik bilgileri bir göreve değil bir hizmete kapsamlandırılır. Bir agent'a entegrasyonun ihtiyaç duyduğu izinlerle bir token veya anahtar verilir ve bu yetki agent'ın gerçekleştirdiği her çalışma boyunca kalıcı olur. Yetkilendirme, onu meşrulaştıran niyetten daha uzun yaşar. Bir agent'ın bir planlama görevi için takvim okuması amacıyla verilen bir yetki, altı ay sonra aynı agent tamamen başka bir şey yaparken hâlâ geçerlidir, çünkü kimlik bilgisinde görevi kodlayan hiçbir şey yoktur.
İkincisi, ara atlamalar üst kimlik bilgisini zayıflatmak yerine yeniden kullanır. Bir planlayıcı bir alt-agent oluşturur. Alt-agent bir araç proxy'sini çağırır. Proxy üçüncü taraf uç noktasını çağırır. Her atlamada, aynı bearer token değişmeden ileri taşınır. Alt-agent, gerçek işi bunun yalnızca bir kısmını gerektirse bile, tam olarak kök asılın yetkisine sahiptir. Bu kullanışlıdır ve agent sistemlerinde etki alanının en büyük tek katkıcısıdır.
Üçüncüsü, loglar isteği kaydeder, onu üreten emanet zincirini değil. Bir erişim logu, belirli bir zaman damgasında geçerli bir token ile bir isteğin geldiğini gösterir. Hangi planlayıcı adımının niyeti ürettiğini, hangi alt-agent'ın onu yürüttüğünü veya tüm dizinin hangi göreve ait olduğunu göstermez. Bu nedenle olay sonrası yeniden oluşturma, birleştirilmek üzere tasarlanmamış sistemler arasında zaman damgalarını ve oturum tanımlayıcılarını ilişkilendirmeye bağlıdır. Bu ilişkilendirme çıkarımdır. Çıkarım bir postmortem için uygundur ve iptal için işe yaramaz.
Asgari uygulanabilir bir atıf kaydı
Çözüm bir log yükseltmesi değildir. Giden bir eylemin ne taşıdığında ve kaydın nereye yazıldığında bir değişikliktir.
Her giden eylem en az dört alan taşımalıdır:
- bir asıl — eylemin onun yetkisiyle gerçekleştirildiği kimlik, gerçek bir hesaba veya hizmet kimliğine çözümlenebilir
- bir görev tanımlayıcısı — eylemin hizmet ettiği iş biriminin kararlı bir kimliği, oturum değil ve süreç değil
- bir üst adım tanımlayıcısı — bu eylemi üreten adım, böylece zincir düz bir liste değil bağlantılı bir yapı olur
- gerçekte kullanılan kapsam — eylemin tükettiği belirli izin, uygulama noktasının denetlediği aynı sözlükte ifade edilmiş
Bu dört alan, herhangi bir eylemden kök aslına geriye ve herhangi bir asıldan onun altında gerçekleştirilen her eyleme ileriye yönlü bir yönlü grafik yeniden oluşturmak için yeterlidir.
Bunu işler kılan mekanizma, her atlamada kapsam zayıflatmadır. Bir alt-agent oluşturulduğunda, çağıranın yetkisinin katı bir alt kümesi olan bir yetki alır — asla bir üst küme değil, asla eşit bir küme değil, meğer ki görev gerçekten tam yetkiyi gerektirsin ve bu gereklilik açık olsun. Zayıflatma, çocuğun oluşturulduğu sınırda uygulanır, çocuk tarafından iddia edilmez. Bir istek alan araç proxy'si, çağıranın token'ını değil kendi zayıflatılmış yetkisini sunar.
İkinci mekanizma, kaydın nereye yazıldığıdır. Atıf verileri, uygulama noktasında — isteğin ilerleyip ilerlemeyeceğine gerçekten karar veren yerde — yayınlanmalıdır, sonradan uygulama loglarından derlenmemelidir. Uygulama logları, hatalı olabilecek, atlanabilecek veya bazı yollarda basitçe bulunmayan kod tarafından yazılır. Uygulama noktası, tanımı gereği her isteği görür ve denetlediği kapsamı zaten bilir. Asıl, görev kimliği, üst adım kimliği ve kullanılan kapsamı oraya yazm
{ "principal": "svc:reporting-agent",
"task_id": "tsk_8f21",
"parent_step": "stp_04",
"scope": "calendar.read",
"target": "external.example.gov",
"decision": "allow" }
Bunun gibi bir kayıt, geleneksel anlamda bir log satırı değildir. Bir grafikte bir kenardır ve hayır deme yetkisine sahip bileşen tarafından yazılır.
Tasarım sonuçları
Zincir var olduğunda, olay müdahalesi karakter değiştirir. "Agent ne yaptı" sorusu bir gezinme haline gelir: asıldan başla, göreve ileri yürü, her adıma ileri yürü, dokunulan her uç noktayı listele. "Oraya nasıl ulaştı" sorusu, uç noktadan kök yetkiye geriye yönelik bir yürüyüş haline gelir. Her ikisi de zaten sürdürdüğünüz bir yapıya karşı sorgulardır, sonradan yürüttüğünüz soruşturmalar değil.
İptal, bir hizmet hesabı yerine bir göreve kapsamlandırılır. Tek bir görev yanlış davranıyorsa, o görev için verilen yetkileri ve onun aşağısındaki her şeyi iptal edersiniz. Agent'ın işinin geri kalanı devam eder. Bu, bir olayı sınırlamak ile bir yeteneği devre dışı bırakmak arasındaki farktır. Aynı zamanda saniyeler içinde etkili olan bir iptal ile hizmet hesabının dokunduğu her entegrasyonu denetlemeden onu kapatmaya cesaret edemeyeceğiniz bir iptal arasındaki farktır.
Sorumluluk argümanları olgusal bir zemine kavuşur. Bir eylem tartışıldığında, zincir neyin yetkilendirildiğini gösterir — verilen kapsamı, onu kullanan adımı, arkasında duran asılı. Bu, bir satıcının model davranışı hakkında iddia ettiğinden farklı türde bir iddiadır ve her iki tarafça da denetlenebilir.
Dürüst ödünleşim, zayıflatma ve eylem başına kayıtların mühendislik çabası gerektirmesi ve sürtünme yaratmasıdır. Her atlama daha dar bir yetki üzerinde anlaşmalıdır, bu da alt-agent'ları oluşturan bileşenlerin alt-agent'ın çalışmadan önce neye ihtiyaç duyacağını bilmesi gerektiği anlamına gelir. Bu bir tasarım kısıtıdır ve bir token'ı geçirmekten gerçekten daha zordur. Ayrıca, logları örneklemek yerine her uygulama noktasında bir kenar kaydı yazmanın gerçek bir performans ve depolama maliyeti vardır. Yüksek hacimli agent trafiği için kayıt hacmi eylem hacmiyle orantılıdır ve bu bedava değildir.
Karşı argüman, maliyetin bir kez, tasarımda ödendiği ve alternatifin tekrar tekrar, her olayda, daha kötü koşullar altında ödendiğidir. Kendi delegasyon zincirini yeniden oluşturamayan bir sistemin normal çalışma sırasında bir atıf sorunu yoktur. Birinin yanıtlayamadığı bir soru sorduğu anda vardır, ki bu tam olarak yanıtın en çok önem taşıdığı zamandır.
Atıf, bir agent yığınına sonradan cıvatalanmış bir güvenlik özelliği değildir. Yetkinin nasıl modellendiğinin ve yayıldığının bir özelliğidir. Veri modelini doğru yapın, güvenlik konuşmasının üzerinde duracağı somut bir şey olur. Yanlış yapın, her olay raporu model hakkında bir tartışmaya dönüşür, çünkü soruyu çözecek zincir hiçbir zaman yazılmamıştır.