Agent Tool Permission Security: AI Agentlerde Yetki Sınırı Nasıl Kurulur?

Agent tool permission security, AI agentin kullanabildiği araçları en düşük yetki prensibiyle sınırlandırma çalışmasıdır. Bir agentin “SQL çalıştır”, “dosya oku”, “e-posta gönder”, “CRM güncelle” veya “ticket kapat” gibi tool’lara erişimi varsa her tool ayrı bir güvenlik sınırı olarak ele alınmalıdır. Doğru yaklaşım, agentin neyi yapabileceğini prompt’a bırakmaz; tool, parametre, kullanıcı rolü, veri tipi ve onay gereksinimiyle teknik olarak sınırlar.

Temel Değerlendirme

AI agentlerde tool permission güvenliği, agentin her tool çağrısını kullanıcı bağlamı, aksiyon riski ve veri hassasiyetine göre sınırlar. Amaç agent yanlış yönlendirilse bile fazla yetkili API veya dosya erişimi üzerinden zarar verememesidir.

Tool Permission Neden Kritik?

Agent mimarilerinde model genellikle karar verir, tool ise aksiyon alır.

Güvenlik açığı çoğu zaman modelin cevabında değil, tool’un fazla yetkili olmasında oluşur.

Örneğin:

Read-only olması gereken agent write yetkisiyle çalışır.
Bir tenant için çalışan agent tüm tenant verisini okuyabilir.
Test ortamı için tasarlanan tool production endpoint’e bağlıdır.
Kritik işlem için onay adımı yoktur.
Tool parametreleri doğrulanmadan API’ye iletilir.

Bu hatalar prompt filtresiyle kalıcı olarak çözülemez.

Tool Permission Matrix

| Tool | İzin Seviyesi | Risk | Gerekli Kontrol | | --- | --- | --- | --- | | Search docs | Read | Hassas doküman sızıntısı | Permission-aware retrieval | | Send email | Write | Yetkisiz iletişim | Onay ve alıcı doğrulama | | Update CRM | Write | Veri bütünlüğü kaybı | Rol ve tenant kontrolü | | Run SQL | High risk | Veri sızıntısı/RCE zinciri | Query allowlist, proxy, audit | | Create ticket | Low/medium | Operasyon gürültüsü | Rate limit ve sahiplik | | Deploy action | Critical | Production etkisi | İnsan onayı ve break-glass |

Pratik Tasarım İlkeleri

Her Tool İçin Ayrı Kimlik

Tek bir geniş yetkili servis hesabı kullanmak yerine tool bazlı kimlik tercih edilmelidir.

Bu sayede bir tool kötüye kullanılsa bile etki alanı sınırlı kalır.

Parametre Seviyesinde Doğrulama

Tool çağrısında sadece tool adı değil, parametre de kontrol edilmelidir.

Örneğin customerId, tenantId, amount, recipientEmail ve filePath gibi alanlar iş kuralına göre doğrulanmalıdır.

Kritik Aksiyonda İnsan Onayı

Para transferi, hesap silme, plan değiştirme, production deploy veya toplu e-posta gibi aksiyonlar otomatik gerçekleşmemelidir.

Agent öneri üretebilir.

Kararı yetkili insan veya ayrı bir approval servisi vermelidir.

Denetlenebilir Log

Her tool çağrısı şu alanlarla loglanmalıdır:

Kullanıcı veya servis kimliği.
Agent oturumu.
Tool adı.
Parametre özeti.
Retrieval kaynağı.
Onay durumu.
Sonuç ve hata bilgisi.

Yanlış Bilinenler

“Tool sadece iç API’ye bağlı, sorun olmaz”

İç API’ler çoğu zaman dış endpointlerden daha yüksek yetkiye sahiptir.

Agent iç API’ye bağlanıyorsa object-level authorization daha da önemli hale gelir.

“Model iyi niyetli davranır”

Güvenlik iyi niyete bırakılmaz.

Model manipüle edilebilir, retrieval zehirlenebilir veya kullanıcı dolaylı talimat verebilir.

“Read-only tool risksizdir”

Read-only erişim de veri sızıntısı yaratabilir.

Özellikle müşteri verisi, loglar, sözleşmeler ve iç dokümanlar için risk yüksektir.

Profesyonel Destek Eşiği

Agentiniz production tool kullanıyorsa, özellikle write/delete/deploy aksiyonları varsa profesyonel assessment gerekir.

Eresus Security bu çalışmada tool permission matrix çıkarır, fazla yetkili çağrıları test eder, yanlış tenant/rol senaryolarını dener ve aksiyon kanıtını raporlar.

SSS

Tool permission security ile API security aynı şey mi?

Tamamen aynı değildir. API security endpointleri ve yetkilendirmeyi inceler; tool permission security agentin bu API’leri hangi bağlamda, hangi karar zinciriyle ve hangi runtime sınırıyla kullandığını da test eder.

En düşük yetki nasıl uygulanır?

Her tool için ayrı scope, ayrı servis kimliği, parametre doğrulama, rate limit, onay akışı ve loglama kuralı tanımlanmalıdır.

Tool çağrısını sadece prompt ile sınırlamak yeter mi?

Hayır. Prompt talimatı yardımcı olur ama güvenlik sınırı değildir. Sınır API gateway, policy engine, tool proxy veya runtime enforcement katmanında uygulanmalıdır.

Ek Kontrol Soruları

Bu risk hangi varlıkları etkiliyor?
Hangi kullanıcı rolleri bu akışa erişebiliyor?
Aynı sorun başka endpoint veya entegrasyonda tekrar ediyor mu?
Bulgunun müşteri verisine etkisi var mı?
Loglardan olayın izi sürülebiliyor mu?
Düzeltme sonrası retest nasıl yapılacak?
Geçici önlem ile kalıcı çözüm ayrıldı mı?
İş etkisi teknik ekibin dışında da anlaşılır mı?
Benzer hata için önleyici kontrol eklenebilir mi?
Ekip bu kontrolü release sürecine bağlayabilir mi?
Gerekirse bağımsız doğrulama için hangi kanıtlar hazırlanmalı?
Sonraki sprintte hangi iç bağlantı ve servis sayfası desteklemeli?