2026 ajan kimlik yığını: ARD, workload identity, Web Bot Auth ve OAuth açıklaması

Tek bir protokol değil, bir kimlik yığını

Eylül 2026'da yayımlanan bir dev.to yazısı, yapay zeka ajanları için kimlik doğrulamanın nasıl çok katmanlı bir yığın haline dönüştüğünü haritalıyor ve bu katmanların tek bir mekanizmada — genellikle uzun ömürlü bir API anahtarında — birleştirilmesinin, bir yetkilendirme motorunun ihtiyaç duyduğu bilgiyi yok ettiği konusunda uyarıyor.

Yazarı, yılı şekillendiren iki gelişmeye işaret ediyor: ajan yeteneklerini bulmak ve doğrulamak için Google'ın açık Agentic Resource Discovery (ARD) spesifikasyonu ve ajan kimlik bilgilerini, delege kullanıcı yetkisini, workload identity'yi, yetkilendirmeyi ve denetim izlerini kapsayan bir mimari öneren, Temmuz 2026 tarihli bir IETF Internet-Draft. Makale, ikisinin de OAuth'un yerini almadığını ve ikisinin de tek başına imzalı bir botu güvenilir kılmadığını vurguluyor.

API anahtarları neden yanlış biçimde

Geleneksel web otomasyonu, bir botu adlandıran bir User-Agent başlığına ve erişim veren bir API anahtarına dayanır. Makaleye göre ilki kolayca taklit edilebilir; ikincisi ise kimliği ve izni tek bir uzun ömürlü gizli anahtara sıkıştırır, böylece onu bir logdan, environment variable'dan, container image'ından veya ajan kaydından çıkarabilen herkes, anahtarın tüm yetkisini devralır.

Ajanlar bunu daha da kötüleştirir çünkü tek bir eylem dört ayrı sorumluyu içerebilir: yazılımı dağıtan operatör, çalışan workload'ın kendisi, ajanın yetkisini kullandığı kullanıcı veya sistem ve bu birleşimin ne yapabileceğine karar veren kaynak sahibi. Yazar, anahtarlara dayalı bir denetim izinin yalnızca anahtarın harekete geçtiğini kaydedebildiğini — hangi workload'ın çalıştığını, kimin yetkilendirdiğini veya hangi kısıtlamaların geçerli olduğunu değil — belirtiyor.

Dört katman, dört soru

Makale sorunu dört katmana ayırıyor. ARD katalogları, kayıt defterleri ve güven meta verisi aracılığıyla keşif, bir yeteneğin nerede yaşadığını ve meta verisini kimin yayımladığını yanıtlar; ancak çağırıcının onu kullanup kullanamayacağını değil. WIMSE kimlik bilgileri, SPIFFE ID'ler ve SVID'ler ya da mTLS kullanan workload identity, hangi çalışan yazılımın aradığını tanımlar; ancak hangi kullanıcının yetki devrettiğini değil. Web Bot Auth ve HTTP Message Signatures aracılığıyla istek kimlik doğrulaması, bir HTTP isteğinin iddia edilen otomatik istemciden geldiğini kanıtlar; ancak istenen eyleme izin verildiğini değil. OAuth access token'ları, token exchange ve transaction token'lar aracılığıyla delege yetkilendirme, ajanın ne yapabileceğini, hangi hedef kitle için ve kimin adına tanımlar — ancak ajanın güvenli davranacağını değil.

Dördünün altında beşinci bir katman yatar: gözlemlenebilirlik. Bir operatör keşif sonuçlarını, workload kimlik bilgilerini, kullanıcı delegasyonunu, yetkilendirme kararlarını, tool çağrılarını ve nihai yan etkileri birbirine bağlayamıyorsa, sistem anlamlı biçimde denetlenebilir değildir.

Her katman gerçekte neyi kanıtlıyor

ARD, çağrı öncesinde olanları ele alır. Domain'de barındırılan kataloglar ve federasyon keşfi kullanır, böylece bir ajan bir tool'u, API'yi, MCP sunucusunu, A2A ajanını veya iç içe katalogu, sabit kodlanmış endpoint'ler veya kapalı bir dizin olmadan bulabilir. Makale, doğrulanmış keşif meta verisinin bir runtime access token olmadığı konusunda uyarıyor: kaynak, çağırıcıyı yine de doğrulamak ve yetkilendirmek zorundadır. Ayrıca spesifikasyon deposunun v0.91'i gelişmekte olan bir taslak olarak tanımladığını, dolayısıyla katalogların sabit değil sürümlü biçimde ele alınması gerektiğini belirtiyor.

Workload identity, doğrulama (attestation) sonrasında runtime'a, küme, namespace, service account, image veya dağıtım politikası gibi niteliklere bağlı kısa ömürlü kriptografik kimlik bilgileri verir. SPIFFE olgun örnek olarak gösteriliyor: bir workload, kodun yanına statik bir gizli anahtar yerleştirmek yerine Workload API aracılığıyla bir SPIFFE ID ve dönen bir SVID (X.509 veya JWT) alır.

Web Bot Auth, RFC 9421 HTTP Message Signatures'ı profiller; böylece otomatik istemciler istek bileşenlerini imzalar ve sunucular imzaları operatörün kontrolündeki açık anahtarlara karşı doğrular. Geçerli bir imza, anahtar sahipliğini, korunan bileşenlerin bütünlüğünü ve tazeliği kanıtlar — iyi niyeti, onayı veya rate limit'leri aşma hakkını değil. Makale, kimlik doğrulama ile yetkilendirme arasındaki ayrımı yazıdaki en önemli ayrım olarak nitelendiriyor ve bir dağıtım uyarısı ekliyor: otomatik trafiklerin çoğu hâlâ imzasız olduğundan, politikalar operatörün yayımladığı IP aralıklarına ve forward-confirmed reverse DNS'e zarif biçimde geri düşmeli ve yalın bir user-agent dizgesi kimlik değil kanıtlanmamış bir iddia olarak ele alınmalıdır.

OAuth ise yetkiyi taşır. Bir ajan kendi yetkisiyle hareket ettiğinde, makale dar kapsamlı, kısa ömürlü ve hedef kitleye sınırlandırılmış, machine-to-machine grant yoluyla alınmış bir access token öneriyor; ajan, authorization server'a statik bir client secret yerine workload kimlik bilgisiyle kimliğini doğrular. Yazı bunu, ajanların delege kullanıcı yetkisini kullandığı ayrı durumdan ayırıyor; ancak o durumun ele alınışı yayımlanan alıntının ötesinde devam ediyor.

Neden önemli

Ajanlar demolarından üretim API'lerine geçtikçe, kimlik, yararlı otomasyon ile hesap verebilir olmayan trafik arasındaki sınıra dönüşüyor. dev.to incelemesi, mühendislik ekiplerine, şu anda tek bir anahtara sıkıştırdıkları sorun için ortak bir sözlük veriyor: tool'u kim yayımladı, hangi workload çağırıyor, eylemi kim yetkilendirdi ve ne yapmasına izin var. Bu ayrımları baştan inşa etmek — bir olaydan sonra denetim izlerini tamir etmek yerine — ajan trafiğini yönetilebilir kılan şeydir ve makalenin katman katman dökümü, bu mimariyi 2026'da tasarlayan herkes için pratik bir kontrol listesidir.