AI Agent İzinleri Deterministik Uygulama Gerektirir

AI agent izinleri, model yanlış karar verdiğinde bile hataları sınırlamalıdır. Üretim tasarımı basittir: her çalıştırmaya dar bir yetenek kümesi verin, bunu modelin dışında uygulayın, insan onayını sonuçları önemli olan eylemler için saklayın ve ne olduğunu doğrulamaya yetecek kanıtları kaydedin.

Hedef kitle: Tool kullanan agent'lar, coding agent'lar veya MCP sunucuları oluşturan ileri düzey uygulayıcılar.

Bu yanıt önemlidir; çünkü “silmeden önce sor” gibi bir prompt, erişim kontrolü sınırı değil, yönlendirmedir. Model bunu yanlış okuyabilir, enjekte edilmiş bir talimat bununla rekabet edebilir ve bir tool, açıklamasından farklı davranabilir. Yetkilendirme bu üç hatanın da üstesinden gelebilmelidir.

AI agent izinleri neleri kontrol etmelidir

Bir agent izin sistemi, belirli bir çağırıcının mevcut koşullar altında belirli bir kaynak üzerinde belirli bir eylemi gerçekleştirip gerçekleştiremeyeceğine karar verir. “Agent GitHub kullanabilir” ifadesi fazla geniştir. Kullanışlı bir karar en azından şunları içerir:

İzin kontrolü tool veya service sınırında yapılmalıdır. Model bir eylem önerebilir ve nedenini açıklayabilir. Kendi önerisinin yetkili olup olmadığına karar vermemelidir.

Bu rolleri ayırmak, secret izolasyonunu da dürüst tutar. Bir credential broker, bir API key'i modelden gizleyebilir; ancak bu key'in izin verdiği her işlemi yine de açığa çıkarabilir. Broker secret'ı korur; eylem kapsamlı bir policy ise kaynağı korur.

En yeni izin araştırması neyi ölçtü

Temmuz 2026 tarihli bir preprint olan *How Agents Ask for Permission*, 2024 ile 2026 arasında yayımlanan veya kullanıma sunulan 21 agent izin sistemini ve önerisini inceledi. Yazarlar ayrıca mayıs sonu ile haziran başı arasında izole kurulumlarda beş ticari agent'ı inceledi.

Taksonomileri üç yönlü bir mühendislik gerilimini ortaya koyuyor:

Bu sayılar yazarların örneklemini tanımlar; tüm pazarı değil. İnceleme kartopu örneklemesi kullandı, preprint'leri ve ticari ürünleri içerdi ve kapalı kaynak iç yapılarını inceleyemedi. Yine de makale faydalıdır; çünkü izin arayüzünü policy'den ve uygulama mekanizmasından ayırır. Özenle hazırlanmış bir onay penceresi, belirsiz bir policy'yi veya uygulanmayan bir kararı telafi edemez.

Ticari tool'lar bu ayrımın bir bölümünü zaten yansıtıyor. Claude Code belgeleri allow, ask ve deny kurallarına izin verirken sandbox belgeleri işletim sistemi düzeyinde dosya sistemi ve network sınırlarını açıklar. OpenAI'nin Codex security guidance de sandbox'ı teknik bir sınır, approval policy'yi ise kullanıcıya soru sorulabilecek nokta olarak ele alır. Bunlar ürüne özgü kontrollerdir; her deployment'ın bunları güvenli biçimde yapılandırdığına dair kanıt değildir.

Onay yorgunluğu bir yönlendirme problemidir

Onay prompt'ları, kullanıcının gerçek bir karar vermesi gerektiğinde faydalıdır. Her rutin komut eşit derecede acil göründüğünde başarısız olurlar.

Tekrarlanan düşük riskli prompt'lar, insanları düşünmeden tıklamaya alıştırır. Anthropic, kendi dahili sandbox kullanıma alımında izin prompt'larında %84 azalma bildirdi; ancak bu bağımsız bir benchmark değil, sağlayıcı tarafından bildirilen operasyonel bir sonuçtur. Kalıcı ders daha dardır: uygulanmış bir sınır içindeki önceden onaylanmış işler, agent'a global erişim vermeden kesintileri azaltabilir.

Eylemleri dört sonuca yönlendirin:

Risk, modelin güveninden değil, eylemden ve etki alanından hesaplanmalıdır. Yüksek güven, geri döndürülemez bir eylemi daha güvenli yapmaz.

Beş katmanlı izin mimarisi

İnandırıcı en küçük mimari, birbirinden ayrı beş katmana sahiptir. Bunları birleştirmek denetimleri zorlaştırır ve fail-open yolları oluşturur.

*Model bir eylem önerir. Policy, uygulama, yürütme ve kanıt ayrı kalır.*

1. Önerilen eylemi normalize edin

Model tarafından oluşturulan bir tool çağrısını yetkilendirmeden önce türü belirli bir isteğe dönüştürün:

{ "actor": "agent-run-7f3", "on_behalf_of": "user-42", "action": "blog.publish", "resource": "post:ai-agent-permissions", "constraints": { "environment": "production", "language": "en" } }

Bu, bir standart değil, örnek bir sözleşmedir. Önemli özellik, yetkilendirmenin serbest biçimli akıl yürütme yerine kararlı bir nesneyi değerlendirmesidir.

2. Policy'yi modelin dışında değerlendirin

Deterministik bir karar döndürün: `allow`, `ask` veya `deny`. Policy kuralını ve sona erme zamanını ekleyin. Model yeni bir isteği sınıflandırmaya yardımcı olabilir; ancak bu sınıflandırma tek başına erişim vermemelidir. Bilinmeyen eylemler fail closed olmalıdır.

3. Kararı yürütme sırasında uygulayın

Tool handler veya downstream service kararı yeniden doğrulamalıdır. Agent'ın bir reddi uygulamasına güvenmeyin. Yeteneği tam eyleme, kaynağa, çağırıcıya ve kısa bir zaman aralığına bağlayın; böylece başka bir hedefe karşı yeniden oynatılamaz.

MCP authorization specification, aynı prensibi access token'lara uygular: sunucular, token'ın amaçlanan audience için verildiğini doğrulamalıdır. MCP'nin security guidance belgesi, bu sınırı bozabileceği için token passthrough'u açıkça yasaklar.

4. Dar kapsamlı tool'lar üzerinden yürütün

`run_sql(query)` yerine `publish_draft(post_id)`, `http_request(url, body)` yerine `send_invoice(invoice_id)` kullanmayı tercih edin. Dar kapsamlı tool'lar policy'yi okunabilir kılar ve istenmeyen eylemlerin alanını küçültür.

Aynı control-layer argümanı MCP Developer Workflows: The Real Control Layer içinde de görülür: tool biçimi, approval gate'leri ve yeniden oynatılabilir eylemler, bir agent'ın güvenli biçimde neler yapabileceğini belirler.

5. Bir makbuz kaydedin ve iptali destekleyin

İstenen eylemi, policy kararını, onay kimliğini, tool input özetini, sonuç sınıfını ve postcondition'ı log'layın. Secret'ları ve hassas payload'ları redakte edin. Kullanıcı, agent'ı yeniden oluşturmadan kalıcı bir izni iptal edebilmelidir.

Makbuz, “tool döndü” ile “amaçlanan durum mevcut” ifadelerini birbirinden ayırmalıdır. HTTP 200, başarılı bir SDK çağrısı veya kendinden emin bir final mesajı bir postcondition değildir.

Memory yazımlarını ayrıcalıklı eylemler olarak ele alın

Kalıcı memory gelecekteki davranışı değiştirir; bu nedenle memory yazımlarının kendine ait bir izin ve doğrulama yolu olmalıdır.

Temmuz 2026 tarihli MemGhost paper, e-posta workflow'ları üzerinden gizli memory injection için 108 vakalık bir benchmark olan WhisperBench'i tanıttı. Yazarlar, bir OpenClaw yapılandırmasına karşı %87,5 ve bir Claude Code SDK yapılandırmasına karşı %71,4 oranında, elde tutulmuş uçtan uca saldırı başarısı bildirdi. Ayrıca diğer memory sistemlerine aktarım da bildirdiler.

Bu rakamlar evrensel bir ele geçirilme oranı ortaya koymaz. Deneyler belirli modelleri, agent mimarilerini ve e-posta merkezli bir workflow'u kapsıyor; bazı değerlendirmeler LLM judge'ları kullanıyor ve makale haftalar süren memory decay'i test etmiyor. Pratik sonuç yine de geçerlidir: güvenilmeyen içerik, provenance, schema validation, tenant isolation ve açık bir write policy olmadan kalıcı agent memory'sine dönüşmemelidir.

Bir memory kaydı şunları taşımalıdır:

İzinler tool hatalarına dayanmalıdır

Bir izin tasarımı, tool açıklamalarının ve yanıtlarının sabit kaldığını varsayıyorsa eksiktir.

ToolBench-X, specification drift, invocation errors, execution failures, output drift ve cross-source conflict altında agent'ları değerlendirir. Makale, temiz tool'larla iyi performans gösteren agent'ların bu tehlikeler altında gerilediğini; hedefli recovery hint'lerinin ise yalnızca daha fazla test-time compute harcamaktan daha fazla yardımcı olduğunu bildiriyor. Bu bir benchmark sonucudur, production incident rate değildir.

AgentTether, başarısız trajectory'leri ve korumalı runtime müdahalesini inceler. Yazarlar, 261 tau-bench görevi üzerinde başlangıçta başarısız olan Qwen run'larının %69,11'ini onardıklarını ve bunun blind retry'dan 26,02 yüzde puan daha yüksek olduğunu bildiriyor. Sonuçlar domain'e göre değişir, yardımcı değerlendirmeler başka bir model kullanır ve tau-bench her production toolchain'i temsil edemez.

Bu makaleler iki kontrolü destekler:

Retry yeni bir yürütme kararıdır; önceki eylemin güvenli olduğunun kanıtı değildir.

Tekrarlanabilir bir izin test workflow'u

Otonom yazımları etkinleştirmeden önce şu testleri çalıştırın:

Deterministik agent metrikleri open-source evaluation tooling içinde görünmeye başlıyor. 12 Temmuz 2026 tarihli DeepEval 4.1.3 release, deterministik bir `ToolPermissionMetric` ve `AgentLoopDetectionMetric` ekledi. Bu release bir benimseme sinyalidir; metriklerin her kötüye kullanım vakasını kapsadığına dair kanıt değildir.

Bağımsız doğrulama security'nin ötesinde de önemlidir. This hybrid AI code review loop, kanıt olarak ayrı bir reviewer ve gerçek bir build kullanır. Daha geniş sistem dersi Code Agents After 21.54 Billion Tokens içinde yeniden görülür: model kalitesi verification'ın ve operasyonel sınırların yerini tutamaz.

Production checklist

OWASP'ın AI Agent Security Cheat Sheet belgesi de benzer bir operasyonel sonuca ulaşır: least privilege uygulayın, karar vermeyi geri döndürülemez yürütmeden ayırın, harici girdileri doğrulayın, loop limit'lerini uygulayın ve yapılandırılmış eylem log'larını koruyun.

Bu kanıt neyi kanıtlamaz

Burada atıfta bulunulan makaleler yerleşik standartlar değil, yeni preprint'lerdir. Örneklemleri, modelleri, tool'ları ve benchmark'ları her sayısal sonucu sınırlar. Ticari belgeler mevcut kontrolleri açıklar; belirli bir deployment'ın bunları doğru kullanıp kullanmadığını değil. GitHub release'leri ve issue raporları aktif mühendislik baskısını gösterir; ekosistem genelindeki hata oranlarını değil.

Bu nedenle mimari bir certification değil, karar çerçevesidir. Değeri, security sınırını incelenebilir kılmasından gelir: model önerir; policy karar verir; altyapı uygular; tool'lar eyleme geçer; bağımsız kanıt doğrular.

Claim checks

Sources