Ajan Yetki Matrisi ve OAuth Kapsamları
KVKK Etken YZ Rehberi'nin uygulanabilir teknik karşılığı

Ajan yetkilendirme nedir?

Ajan yetkilendirme, bir yapay zeka ajanının hangi araçları çağırabileceğini, hangi veri sınıflarına erişebileceğini ve hangi işlemler için insan onayı gerektiğini ajan kimliği düzeyinde önceden sabitleme pratiğidir. Klasik uygulama yetkilendirmesinden farkı, kararı ajanın kendisinin değil çevreleyen kontrol katmanının vermesidir: ajan bir aracı ancak kimliğine bağlı kapsam (scope) izin veriyorsa çağırabilir, çağrı da onay eşiğini ve loglama kuralını taşıyan bir kapı üzerinden geçer.

Bu yazı kavramsal çerçeveyi baştan kurmaz. Kimlik, kapsam, araç sınırı, süre, bütçe, onay ve geri alınabilirlik gibi en az ayrıcalık ilkelerinin neden gerektiğini Ajan Yetki Modeli ve En Az Yetki (least agency) yazısında ele aldık. Burada odak tamamen uygulama katmanında: kopyalanabilir matris, konfigürasyon deseni ve düzenleyici eşleme.

Neden teori değil, uygulama katmanı?

KVKK'nın 12 Mart 2026'da yayımladığı 'Etken Yapay Zekâ (Agentic AI)' Rehberi, veri yönetişimi, risk değerlendirmesi, insan denetimi ve sorumluluk dağılımı başlıklarında ilkesel yönlendirmeler getirdi. Bu ilkeler doğru ama soyut: 'insan denetimi sağlanmalı' cümlesi, bir üretim sistemine tek başına yazılmaz. Ekiplerin ihtiyacı, ilkeyi hangi araç çağrısında onay kapısına çevireceğini, hangi log alanını tutacağını ve hangi kişisel veri alanını maskeleyeceğini gösteren somut bir haritadır.

Türkçe kaynaklarda rehberin hukuki yorumu birçok yerde işlendi; az işlenen kısım, aynı rehberin bir yetki matrisine ve gateway konfigürasyonuna nasıl indirgeneceğidir. Bu sayfa o boşluğu doldurmaya çalışır. Bölümlerin sırası pratik: önce matris, sonra kapsam deseni, sonra düzenleyici eşleme ve confused deputy savunması.

Ajan Yetki Matrisi şablonu (kopyalanabilir)

Yetki matrisi, her ajanı bir satır; erişebildiği araçları, veri sınıfını, onay eşiğini ve loglama seviyesini sütun yapar. Amaç, 'bu ajan neyi yapabilir?' sorusunun yanıtını koda gömmek yerine bir tabloda gözle denetlenebilir hale getirmektir. Aşağıdaki şablonu olduğu gibi kopyalayıp kendi ajanlarınızla doldurabilirsiniz.

Şablonu doldururken üç kuralı sabit tutun: (1) her satır varsayılan olarak reddet ile başlar, yalnızca açıkça listelenen araçlar açılır; (2) 'veri sınıfı' sütunu daima en dar sınıfı gösterir, 'her şey' asla yazılmaz; (3) yazma veya para hareketi içeren her araç mutlaka bir onay eşiği taşır. Matrisi bir tablo dosyası olarak sürüm kontrolünde tutmak, her yeni ajan ekleme talebini bir satır incelemesine dönüştürür.

Ajan başına OAuth kapsam ve anahtar deseni

Matristeki her satır, çalışma zamanında bir kimliğe karşılık gelmelidir. Doğru desen, tüm ajanların ortak bir servis hesabını paylaşması değil; her ajanın kendi kimliği, kendi anahtarı ve o kimliğe bağlı dar bir OAuth kapsam kümesi olmasıdır. Böylece bir ajan ele geçirilse bile yalnızca kendi kapsamı kadar zarar verebilir; anahtar tek tek iptal edilebilir (geri alınabilirlik).

OAuth 2.0 kapsamları tam da bunun için vardır: erişim jetonuna hangi işlemlere izin verildiğini gömer. Aşağıdaki illüstratif konfigürasyon, matristeki fatura ajanı satırının bir kapsam/anahtar tanımına nasıl indirgendiğini gösterir.

agent: fatura-odeme-ajani
identity: svc-agent-billing            # kendi kimligi, paylasilmaz
oauth_scopes:
  - invoices:read
  - refunds:write
denied_by_default: true                # listelenmeyen her arac kapali
data_classes:
  - financial
  - identity_masked                    # ham TCKN/IBAN degil, maskeli
approval:
  tool: refunds:write
  threshold: "tutar > esik"           # esik ustu insan onayi
logging:
  level: full
  fields: [agent_id, tool, args_masked, approver_id, timestamp]
key_rotation: enabled                  # anahtar tek tek iptal edilebilir

AltaySec olarak bu deseni, Guardian yapay zeka gateway'i etrafında ajan başına anahtar/kapsam referans mimarisi olarak ele alıyoruz: bu desende gateway katmanı, çağrıyı ajan kimliğine bağlamak, kapsam dışı araç çağrısını reddetmek ve onay eşiğini kapıda uygulamak için doğru yerdir. Bunu bir üründe genel geçer 'kurulu yapılandırma' olarak değil, ekiplerin kendi yığınlarına uyarlayabileceği bir mimari desen olarak sunuyoruz. Gateway'in bir LLM güvenlik duvarı gibi araç çağrısı katmanında durması, kapsam denetimini uygulamanın en pratik yeridir. Araç envanterinizi MCP sunucularıyla açıyorsanız, kapsam sınırlarının sunucu tarafında da doğrulanması gerektiğini MCP sunucusu güvenlik incelemesi yazısında işledik.

KVKK Etken YZ Rehberi'nin teknik karşılığı

Rehberin dört ana ilkesini üretimde uygulanabilir tekniklere eşleyelim. Bu eşleme, hukuki metni değil, o metnin gateway ve matris üzerindeki karşılığını verir.

Nasıl loglanır

Denetlenebilirlik için her araç çağrısı en az şu alanları taşımalı: ajan kimliği, çağrılan araç, maskelenmiş argümanlar, varsa onaylayan kişi kimliği ve zaman damgası. Kritik olan, logun kişisel veriyi ham haliyle çoğaltmamasıdır; argümanlar log'a yazılmadan önce maskeleme filtresinden geçmelidir.

Nasıl kısıtlanır

Kısıtlama iki katmanlıdır: kimlik katmanında kapsam dışı araç çağrısı reddedilir; iş katmanında onay eşiği üstündeki işlem insan onayı gelene kadar bekletilir. İki katman birlikte, 'ajan yanlış bir şey isterse ne olur?' sorusuna varsayılan-reddet yanıtı verir.

Hangi alan maskelenir

TCKN, IBAN, telefon, e-posta ve adres gibi kişisel veri alanları ajana ham verilmez; gateway bunları maskeli biçimde iletir ve log'a maskeli yazar. Maskelemenin nerede ve nasıl yapılacağını KVKK ve LLM'lerde kişisel veri maskeleme yazısında ayrıntılandırdık.

Confused deputy ve insan onayı akışı

Confused deputy (kafası karışmış vekil), bir ajanın kendi yetkilerini başkası adına, o kişinin sahip olmadığı bir yetkiyle kullanmasıyla oluşur: ajan geniş kapsamlı bir servis anahtarı taşır, kullanıcı ise ajana enjekte ettiği bir talimatla o anahtarı kendi lehine kullandırır. Ajan başına dar kapsam bu saldırının yüzeyini doğrudan küçültür, çünkü ele geçirilmiş ajan yalnızca kendi kapsamı kadarını yapabilir.

İkinci savunma insan onayı akışıdır. Yazma, silme veya para hareketi içeren her işlemde ajan, eylemi doğrudan yürütmez; matristeki eşiğe bakar, eşik aşılıyorsa işlemi bir onay kuyruğuna koyar ve insan onayı gelene kadar bekler. Onay isteği, ajanın ne yapmak istediğini ham argümanlarla değil, insan tarafından okunabilir bir özetle sunmalıdır; aksi halde onaylayan kişi neyi onayladığını göremez. Enjekte edilmiş bir aciliyet dilinin onay eşiğini atlatmaya çalışması sık görülen bir kalıptır; bunu yetki ve aciliyet temelli prompt injection yazısında inceledik. Araçların kendisinin ele geçirilmesi riski için ise araç ele geçirme (tool hijacking) savunmalarına bakılabilir.

Uygulama kontrol listesi

Matrisi ve deseni bir üretim sistemine oturtmak için sırayla ilerleyin:

• Her ajan için ayrı kimlik ve anahtar tanımlayın; ortak servis hesabını paylaşmayın.
• Yetki matrisini bir tablo dosyası olarak sürüm kontrolüne alın; yeni ajanı bir satır incelemesiyle ekleyin.
• Kapsamı varsayılan-reddet kurun; yalnızca listelenen araçları açın.
• Yazma ve para hareketi araçlarına onay eşiği koyun; onaylayan kimliğini loglayın.
• Kişisel veri alanlarını gateway'de maskeleyin; log'a maskeli yazın.
• Anahtar rotasyonunu ve tekil iptali önceden test edin; geri alınabilirliği bir tatbikatla doğrulayın.

Matris şablonunu ve kapsam desenini kendi ajan yığınınıza uyarlarken destek isterseniz iletişim üzerinden ulaşabilirsiniz. Bu sayfadaki tablolar doğrudan kopyalanabilir; amaç, KVKK Etken YZ Rehberi'nin ilkelerini bir sonraki denetimden önce uygulanmış hale getirmenizdir.

Kaynaklar

• KVKK — Rehberler (Etken Yapay Zekâ Rehberi dahil)
• OWASP Top 10 for LLM Applications — LLM06:2025 Excessive Agency
• OAuth 2.0 (RFC 6749) — Access Token Scope (Section 3.3)
• NIST AI Risk Management Framework (AI RMF 1.0)
• MITRE ATLAS — Adversarial Threat Landscape for AI Systems

İlgili Yazılar

• Ajan Yetki Modeli ve En Az Yetki (Least Agency)
• MCP Sunucusu Güvenlik İncelemesi
• KVKK ve LLM'lerde Kişisel Veri Maskeleme
• AI Agent Güvenliği: Araç Ele Geçirme