Yapay zeka ajanı kimliğini beşe ayırmak: güvenilir API çağrıları için transaction-token yaklaşımı

Dev.to'da yayımlanan, güvenilir yapay zeka ajanı transaction'ları üzerine planlanan bir dizinin açılış yazısı, sıradan API çağrılarının arkasındaki kimlik modelinin bir yapay zeka ajanı kullanıcı ile servis arasına girdiğinde çöktüğünü savunuyor — ve mevcut standartların bir bileşiminin bu parçaları nasıl bir arada tutabileceğini çiziyor.

Sorun: tek soru altıya dönüşüyor

Geleneksel bir uygulama bir kullanıcı adına API çağırdığında, servis genellikle tek bir soruyu yanıtlamak zorundadır: kullanıcı kim? Yazıya göre bir ajan bunu birkaç ayrı soruya dönüştürür — işi hangi kullanıcı yetkilendirdi, hangi mantıksal ajan harekete geçiyor, çağrıyı hangi çalışan workload gerçekleştirdi, o ajanın hangi çalıştırması söz konusu, çağrı hangi transaction ve amaca hizmet ediyor ve geçerli ağ sekmesini hangi servis yaptı.

Yazar, tüm yanıtların tek bir claim içine paketlenmesinin yanılsamalı bir güvenlik duygusu yarattığı konusunda uyarıyor. Bir ajanın adı, fiilen çalışan süreç hakkında kriptografik kanıt değildir; bir workload kimliği kişi değildir; bir transaction tanımlayıcısı da çağırıcı kimliği değildir.

Anlatılan uygulama beş değeri ayrı tutuyor:

• UserID — kimliği doğrulanmış insan veya upstream principal
• AgentID — onaylanmış mantıksal ajan tanımı
• AgentInstanceID — o ajanın tek bir çalıştırması
• SPIFFEID — kanıtları doğrulanmış runtime workload
• TransactionID — devredilen eylem için sabit bir tanımlayıcı

Kullanıcı token'ı neden yeterli değil

Yazıya göre, özgün kullanıcı erişim token'ının tüm downstream servislere iletilmesi üç şekilde başarısız olur. Servisler, kullanıcıyı onun adına hareket eden ajandan güvenilir biçimde ayırt edemez. Ayrıca geniş kapsamlı bir token, onu görme nedeni olmayan sistemlere de sızmabilir ve genellikle bu belirli transaction'ın amacı hakkında hiçbir şey söylemez.

Yazarın benimsediği alternatif, Tokenetes'ten gelen Transaction Tokens mimarisidir. Dış bir endpoint, gelen yetkilendirmeyi kontrollü bir Transaction Token Service sınırında değiştirir; çıktı, tek bir çağrı zincirine kapsamlanan donmuş kimlik ve yetkilendirme bağlamını taşıyan kısa ömürlü, imzalı bir Txn-Token'dır.

Bir agent_id alanı kanıt değildir

Herhangi bir HTTP isteği rastgele bir ajan adı ileri sürebilir; bu nedenle yalnızca bu değere göre yetkilendiren bir sunucu, bir workload'un bir dizeyi düzenleyerek diğerini taklit etmesine izin verir. Yazının kuralı, mantıksal AgentID'nin, kriptografik olarak doğrulanmış bir workload kimliğini onaylanmış bir ajana eşleyen güvenilir politikadan gelmesi gerektiğidir. Çağıranlar işlem isteyebilir — kendilerine bir kimlik atayamazlar.

Değişmez bağlam, kimliği doğrulanmış sekmeler

Txn-Token, devredilen bağlamı — kullanıcı, mantıksal ajan, kaynak workload, transaction ve amaç — taşır ve downstream'a yol alırken asla yeniden yazılmaz. Bu, ara servislerin önceki bağlamı silmesini veya taklit etmesini engeller ve paylaşılan transaction ID'si ajan, gateway, MCP sunucusu ve korumalı API arasında ilişkilendirilebilir.

Her ağ bağlantısı SPIFFE mTLS ile ayrı ayrı doğrulanır; böylece bir servis, çağrıyı yalnızca doğrulanmış transaction bağlamı, doğrulanmış anlık çağıran ve hedef politika hep örtüştüğünde kabul eder.

Referans akış

Yazı somut bir boru hattı ortaya koyuyor: kullanıcının OAuth token'ı bir yapay zeka ajanına ulaşır ve ajan bunu RFC 8693 token exchange için PingFederate'e sunar. Sonuç, korumalı API'ye ulaşmadan önce bir MCP gateway ve MCP sunucusu boyunca akan kısa ömürlü bir transaction JWT'sidir. PingFederate Transaction Token Service rolünü üstlenir, SPIRE değişim sırasında ajan workload kanıtı olarak bir JWT-SVID ve workload'lar arasındaki mTLS için X.509-SVID sağlar, PingAuthorize ise gateway'de token'ın bağlamını değerlendirir.

Tokenetes, çağrı zinciri modeli için referans noktası olarak hizmet eder: bir Txn-Token dış çağrı için bir kez basılır, downstream'a hareket ederken değişmeden kalır ve yalnızca kendi güven alanı içinde kabul edilir; anlık ağ çağıranı ise ayrıca doğrulanır.

Yazar, bunun yeni bir kimlik sistemi olmadığını vurguluyor. Bu, her birinin sorumluluğu net biçimde ayrılmış, mevcut kullanıcı, workload, delegation, transport ve politika kontrollerinin bir bileşimidir. Bir eşlik eden GitHub deposu uygulamayı içeriyor ve bir devam yazısı, delegation sınırı olarak PingFederate token exchange'i ele alacak.

Neden önemli

Yapay zeka ajanlarının gerçek API'lere karşı işlem yapmasına izin verilmeden önce, servislerin aynı anda birbirinden bağımsız iki soruya yanıt alması gerekir: bu hangi devredilmiş eylemdir ve bu bağlantının diğer ucunda tam olarak kim vardır? Bunların tek bir token'a veya tek bir dize alanına daraltılması, taklidi kolaylaştırır ve denetimi imkânsız kılar. Bu yazıdaki çerçeve — kullanıcı, mantıksal ajan, ajan çalıştırması, workload ve transaction'ın ayrı tutulup ardından atlama başına mTLS ile kısa ömürlü, değişmez bir token içinde birleştirilmesi — ekiplere, birçoklarının zaten işlettiği standartlardan oluşturulmuş somut bir kalıp sunuyor: OAuth, RFC 8693 exchange, SPIFFE/SPIRE ve merkezi politika. Ajan'dan-API'ye altyapı, özellikle MCP gateway'leri çevresinde kuran herkes için beş kimlikli ayrıştırma kalıcı çıkarımdır.