AWS, Okta Cross App Access ile Yapay Zeka Ajanlarının Eylemlerini Adı Belirli Çalışanlara Bağlıyor

AWS, yapay zeka ajanlarını kendileri adına hareket ettikleri çalışanlara karşı sorumlu kılmak için, yetkilendirmede Okta oturum açmalarını çapa olarak kullanan bir mimari yayımladı. dev.to üzerinde yer alan Fathom News haberine göre tasarım, her ajan eylemini paylaşımlı bir service account yerine adı belirli bir kullanıcıya bağlıyor ve izinleri her tool çağrısında ayrı ayrı değerlendiriyor.

Tek ajanlı desen nasıl çalışıyor

Kurulumun temel sürümünde tek bir ajan, tek bir kişi adına çalışır. Kullanıcı Okta üzerinden oturum açtığında, Okta Cross App Access o kişinin kimliğine bağlı bir grant çıkarır. Ajan herhangi bir aşağı akış tool'una erişmeden önce Amazon Bedrock AgentCore Identity bu grant'ı kullanır; böylece ajan kendi genel kimlik bilgileriyle değil, kullanıcının yetkilendirmesiyle hareket eder.

Haber burada ince ama önemli bir modelleme tercihine dikkat çekiyor: Bedrock AgentCore, ajanı genel bir arka plan script'i olarak ele almıyor. Bunun yerine ajan, çalıştığı kişiden kısıtlı bir hak kümesini devralan ayrı bir aktör.

Çok sayıda ajana ölçeklenme

Bir sonraki kılavuz, deseni tek ajan senaryosunun ötesine taşıyor. Genişletilmiş sürüm merkezi bir gateway ekliyor, Amazon EKS üzerinde çalışan ikinci bir ajan sunuyor ve her tool çağrısına ayrı bir policy denetimi uyguluyor.

Habere göre yetkilendirme zinciri şöyle işliyor: Okta kullanıcıya bağlı yetkilendirmeyi çıkarır, Bedrock AgentCore Gateway bunu alır, Amazon'un policy dili Cedar o çağrının gerçekleştirilip gerçekleştirilemeyeceğine karar verir ve AgentCore Observability oluşan olay kaydını tutar. Amazon bunun sonucunu, uygulamalara dağılmış ayrı service account'ların yerini alan, kurum genelinde ajan kimliği için tek bir ön kapı olarak tanımlıyor.

Service account'ların yetersiz kaldığı yer

Haber altta yatan sorunu, ajanların ne olduğuna dair bir değişim olarak çerçeveliyor. Yazılım artık yalnızca sohbet etmek yerine bilet açabildiğine, dahili dosyalarda arama yapabildiğine veya iş akışları tetikleyebildiğine göre, zor soru model kalitesi değil yönetişim oluyor: hangi ajan, hangi kullanıcı için, hangi sınır dahilinde ne yapabilir.

Mevcut izin yapıları bunu kötü yönetiyor. Bir çalışanın Salesforce veya Workday içinde iyi tanımlanmış hakları olabilir; ancak arka plandaki bir ajan tipik olarak geniş kapsamlı bir service kimliği altında çalışır. Bu, verilen bir eylemi kimin gerçekten onayladığını bulanıklaştırır ve olay sonrası incelemeyi zorlaştırır; çünkü birçok sisteme sürekli erişimi olan tek bir kimlik bilgisi net bir hesap verebilirlik çizgisi bırakmaz.

Güvenlik ekipleri, uyum yetkilileri ve regüle sektörlerdeki şirketlerde çalışan geliştiriciler için AWS deseni, haberin eksik olduğunu söylediği şeyi sunuyor: her eylemi kullanıcı onaylı bir yetkilendirme zincirine bağlanırken özerk hareket edebilen ajanlar.

Şimdi izlenecek nokta

Habere göre açık soru, AWS'nin bu belgelenmiş deseni Bedrock AgentCore içindeki varsayılan ayarlara dönüştürüp dönüştürmeyeceği. Bu olursa, kullanıcıya bağlı ajan kimliği referans mimariden standart bir kurumsal kontrole geçecek.

Neden önemli

Kurumlarda ajan dağıtımını sınırlayan şey model yeteneğinden çok güven oldu. Paylaşımlı service account'lar ajanlara sınırsız bir etki alanı veriyor ve denetçilere bir eylemi bir kişiye atfetme imkanı bırakmıyor; bu yüzden birçok kuruluş ajanları üretim araçlarından tamamen uzak tutuyor. Ajan izinlerini bir insan kimliğine bağlamak, bu grant'ı bir gateway'de kullanmak ve her çağrıyı Cedar ile değerlendirmek, ajan erişimini her şeye ya da hiçbir şeye izin veren bir kısayoldan denetlenebilir ve geri alınabilir bir şeye dönüştürüyor. AWS bunu varsayılan olarak sunarsa, kurumsal yapay zeka ajanlarının nasıl kimlik doğrulaması yapmasının beklendiğine dair tabanı belirleyebilir ve diğer platformları eşdeğer kullanıcıya bağlı kimlik kontrolleri sunmaya zorlayabilir.