kagent 0.10, RFC 8707 ile hedef kitleye bağlı agent token'ları sunuyor; varsayılan olarak kapalı

Neler yayınlandı

kagent v0.10.0, 4 Eylül'de genel kullanıma sunuldu ve uzun değişiklik listesinde, bir agent'ın kimlik bilgisinin tek bir backend'de mi yoksa hepsinde mi geçerli olacağını belirleyen iki environment variable dikkat çekiyor. Etiketli kaynak kodunu inceleyen webofmike'nin dev.io yazısına göre, KAGENT_STS_RESOURCE ve KAGENT_STS_AUDIENCE değişkenleri RFC 8707 resource indicator'larını projenin token exchange akışına getiriyor. İkisi de varsayılan olarak boş, yani yeni kapsamlama davranışı bir operatör etkinleştirmedikçe devre dışı.

Çözülen sorun

Bir kagent agent'ı, Kubernetes service account olarak kimlik doğrular ve bu kimliği, kagent'in bir süredir gönderdiği RFC 8693 OAuth 2.0 Token Exchange client'ı aracılığıyla MCP server'ları gibi backend'lere sunduğu bir token'a dönüştürür. Bu exchange'in daha önce açık bıraktığı nokta, ortaya çıkan token'ın amacıydı. Bir istek hedef belirtmediğinde, security token service sonucu kapsamlayacak bir şeye sahip olmaz ve yanıt, STS'ye güvenen her backend tarafından kabul edilir.

Yazı bunu, agent'ın vekil (deputy) rolünü üstlendiği bir confused-deputy senaryosu olarak tanımlıyor ve agent'lar runtime'da metin içinde bulunan talimatlar üzerine harekete geçmek için açıkça tasarlandığından, bunun klasik versiyondan daha keskin olduğunu savunuyor. GitHub issue'ları okumak için bir MCP server'a, para taşımak için bir diğerine bağlı bir agent; bir prompt injection ya da kurcalanmış bir tool açıklaması yoluyla, token'ını ikinci backend'e sunabilir.

Kapsamlama nasıl çalışıyor

Çözüm RFC 8707'yi izliyor: exchange sırasında hedef resource'u belirt, aud claim'i o resource olan bir token al ve backend'in başka her şeyi reddetmesini sağla. 0.10 kodunda değişkenler go/core/pkg/env/kagent.go içinde RFC'leri atıf yapan açıklamalarla kayıt ediliyor, runtime başlangıcında go/adk/pkg/runner/adapter.go içinde okunuyor ve her iki parametre birden fazla değeri kabul ettiğinden virgüllerle ayrılıyorlar. Bağlantıya go/adk/pkg/sts/client.go içinde ulaşıyorlar ve her giriş kendi form alanına dönüşüyor.

Davranışı göstermek için yazar, Kubernetes cluster, bulut hesabı ya da sağlayıcı anahtarı gerektirmeyen ve iki mock backend içeren üç container'lı bir test düzeneği kurdu: biri yalnızca bir GitHub URL'ine audience-bound token'ları, diğeri bir ödeme URL'ine bağlı token'ları kabul ediyor. Düzenek, kagent'in kendisi yerine ilgili kod yollarını yansıtan bir kagent runtime vekili çalıştırıyor. Değişken ayarlanmadığında exchange hiçbir kapsamlama parametresi taşımıyordu ve doğrulayan iki backend de ortaya çıkan kapsamsız token'ı reddetti. Tek bir backend'e kapsamlandığında token orada kabul edildi, diğerinde ise HTTP 401 ile geri çevrildi. İkisine birden kapsamlandığında her ikisinde de çalıştı — geniş erişim hâlâ mümkün, ama artık birinin inceleyebileceği bir config dosyasında açıkça talep edilmesi gerekiyor.

Sessiz başarısızlık modu

Öne çıkan tuzak, boş ya da yanlış yazılmış bir değişkenin ürettiği sonuç. Değer boş, yalnızca boşluklardan oluşan ya da yanlış yazılmış olduğunda kod hiçbir alan eklemediğinden, bağlantıdaki istek kapsamlanmamış bir exchange'ten ayırt edilemez görünüyor. Bunun sert bir başarısızlığa mı yoksa sessiz bir fazla yetkilendirmeye mi dönüşeceği tamamen backend'e bağlı. Demoda mock server'lar aud doğruladığından, yanlış bir yapılandırma hemen bir 401 olarak ortaya çıkıyor. Audience kontrolünü atlayan bir backend'de ise aynı hata, her yerde kabul edilen bir token üretir ve hiçbir yerde sorunu bildirmez. Bu nedenle kontrol iki taraflıdır: KAGENT_STS_RESOURCE ayarlamak, backend'ler gerçekten olması gereken audience'ları reddetmedikçe pek bir şey kazandırmaz ve yazı her iki tarafın da doğrulanmasını öneriyor.

Çözmediği şey

Bu, bir token'ı bir servise kapsamlayan standart bir OAuth mekanizması gönderen bir runtime'dır; agent kimliği değil. Token'ın öznesi pod'un Kubernetes service account'u olarak kalıyor ve act claim'i runtime'ı adlandırıyor; exchange'te bir agent oturumunu diğerinden ayırt eden ya da agent'tan ne istendiğini kaydeden hiçbir şey yok. Yazar, bu alandaki MCP spec çalışmasının henüz bitmediğini belirtiyor: MCP auth extensions deposunun Ağustos yol haritasında adı geçen dört kimlik çalışma grubundan yalnızca biri stabil bir spec üretmiş durumda; DPoP ve Workload Identity Federation hâlâ açık. Yazar, altındaki katman için SPIFFE workload identity'yi doğal bir eşleşme olarak öneriyor.

Neden önemli

Bu sürüm, uzun süredir süren bir agent güvenliği tartışmasını bir config alanına dönüştürüyor. Operatörlerin değişkenleri ayarladığı ve backend'lerin audience kontrolü uyguladığı yerlerde, yanlış backend'e uzanan enjekte edilmiş bir agent, tutmaması gereken bir kimlik bilgisiyle başarılı olmak yerine, kullanım noktasında reddediliyor. Ancak varsayılan olarak kapalı ve sessizce başarısız olan bu kombinasyon, iyileştirmenin isteğe bağlı olduğunu ve yanlış yapılandırmaya açık olduğunu gösteriyor; üzerindeki boşluklar — oturum başına agent kimliği, workload federation — hâlâ açık spec çalışmaları. Birden fazla MCP backend'ine karşı agent runtime'ları çalıştıran ekipler için pratik çıkarım doğrudan: değişkenleri etkinleştirin ve backend'lerin gerçekten aud kontrolü yaptığını doğrulayın.