Agent yetkilendirmesi ne anlama gelir
Agent yetkilendirmesi, bir AI agent’in ne yapmasına izin verildiğine ilişkin karardır: hangi route’ları çağırabileceği, hangi verileri okuyabileceği, hangi actions gerçekleştirebileceği ve hangi hacimde yapabileceği. Bu, agent kimliğinden farklıdır; agent kimliği, isteği hangi agent’in ya da hangi operatörün agent’inin yaptığıyla ilgilidir.
İkisini ayırmak kolay değildir çünkü çoğu zaman birlikte gelirler. İmzalı bir istek, size bunu kimin gönderdiğini söyler. Ancak bu gönderenin bir hesabı değiştirmesine, sipariş oluşturmasına ya da veri dışa aktarmasına izin verilip verilmeyeceğini söylemez. Kimlik bir kanıttır; yetkilendirme bir policy’dir. İmzalı AI agent isteklerinin neyi kanıtladığı ve neyi kanıtlamadığı hakkındaki yazımız bu farkı açar.
Bu ayrım neden önemlidir
Uygulamalar, insan kullanıcılar için zaten kimlik doğrulamayı yetkilendirmeden ayırır: oturum açmak kim olduğunuzu kanıtlar, roller ve permissions ise ne yapabileceğinizi belirler. Agent’ler için de aynı ayrım gerekir, ancak ek bir dikkat katmanıyla:
- Kimlik güçlü olabilir, izin olmayabilir. Kusursuz geçerli bir HTTP mesaj imzası olan bir crawler’ın bir yazma endpoint’ini çağırma yönünde doğuştan bir hakkı yoktur.
- İzin güçlü kimlik olmadan da var olabilir. Bir müşterinin API key’ini kullanan bir agent, o key ile yetkilidir, onu hangi agent yazılımının tuttuğunu hiçbir şey göstermese bile.
- Agent’in arkasındaki kişi önemlidir. Bir agent birisi adına hareket ettiğinde soru, o kişinin ona yetki verip vermediği olur (bkz. devredilmiş yetki).
Bunları tek bir kontrolde birleştirmek iki hata türüne yol açar: insan oturumu açması olmadığı için meşru otomasyonu engellemek ya da iyi tanımlanmış bir agent’e hiç amaçlanmamış eylemleri güvenerek yaptırmak.
Yetkilendirme genellikle nasıl ifade edilir
Çoğu uygulama, zaten sahip oldukları mekanizmalarla agent’leri yetkilendirir:
- Credentials ve scopes. Entegrasyonun ihtiyaç duyduğu kadar ile sınırlı API key’ler ya da OAuth 2.0 token’ları. MCP server’lar aynı modeli kullanır: MCP yetkilendirme spesifikasyonu, korunan bir server’ı OAuth 2.1 resource server olarak ele alır.
- Route düzeyinde policy. Bilinen agent’lere açık salt okunur route’lar; yazma route’ları ise bir hesab'a bağlı credential gerektirir.
- Risk kademeleri. Düşük etkili actions geniş biçimde izinli, yüksek etkili actions ise daha güçlü credentials, onay veya inceleme gerektirir.
- Operatör, credential veya route başına rate limitler ve kotalar.
Agent kimliği kanıtı bu kararlara girdilerden biri olarak beslenir. İşleyen bir yaklaşım için insanlar ve AI agent’ler için uygulama düzeyi policy’lerin tasarlanması bölümüne bakın. Bu yaklaşım, doğrulanmış bir operatörü anonim bir istemciden farklı ele almanızı sağlar, ancak iznin kendisi yine de policy’nizden gelir.
Yaygın yanlış kanılar
- "Doğrulanmış agent izinlidir." Doğrulama bir isteği bir tarafa atar. Hangi eylemlere izin verileceğine yine policy karar verir.
- "Agent’ler, insan oldukları kanıtlanmadıkça engellenmelidir." Birçok agent meşru katılımcıdır. Daha doğru soru, her actor türüne route route ne kadar izin verileceğidir.
- "Yetkilendirme davranıştan çıkarılabilir." Davranış, mevcut actor türüne ilişkin güveni artırabilir ya da azaltabilir. Ancak tek başına izin vermemelidir.
Proof of Actor bunu nasıl ele alır
Proof of Actor, kanıt sorusuna yanıt verir: Hangi tür actor mevcut, hangi temelde (Verified, Declared, Inferred ya da Unknown) ve neler biliniyor, neler bilinmiyor. İzin kararını bilerek vermez. Agent sonucu, doğrulanmış olsa bile, asla yetkilendirme anlamına gelmez. Route içinde uygulamanız, her interaction için allow, adapt, challenge, review ya da limit kararını vermek üzere actor sonucunu kendi credentials, scopes ve risk kademeleriyle birleştirir; bunu önce observation modunda başlatarak herhangi bir şeyi enforce etmeden önce sonuçları kontrol edebilirsiniz.
Kararların uygulamanıza nasıl oturduğu hakkında daha fazla bilgi edinin, APIs ve MCP servers kullanım alanlarına bakın veya erken erişim için başvurun.
Kaynaklar
- RFC 6749: The OAuth 2.0 Authorization Framework: client’lar için kapsamlı token’lar
- MCP specification 2026-07-28: Authorization: MCP servers için OAuth tabanlı yetkilendirme
- RFC 9421: HTTP Message Signatures: imzalı bir isteğin neyi ortaya koyduğu