AI Agent Security Checklist

AI agent security checklist, bir agent production’a çıkmadan önce tool izinleri, veri erişimi, memory, retrieval, kullanıcı rolleri, onay akışı ve loglama kontrollerinin net şekilde gözden geçirilmesini sağlar. Bu liste “model cevap veriyor mu?” sorusundan daha önemlidir; çünkü agent güvenliği, modelin aldığı aksiyonların sınırlandırılmasıyla kurulur. Agent müşteri verisine, iç dokümana, dosya sistemine veya API tool’larına erişiyorsa bu checklist minimum hazırlık kabul edilmelidir.

Temel Değerlendirme

AI agent güvenliği için önce agentin hangi veriye eriştiği, hangi tool’u çağırdığı, hangi kullanıcı bağlamıyla çalıştığı ve kritik aksiyonlarda nasıl durdurulduğu yazılmalıdır. Bu dört alan net değilse agent henüz güvenlik testine hazır bile değildir.

1. Agent Envanteri

Agentin amacı yazıldı mı?
Kullanıcı rolleri belli mi?
Agent hangi ortamlarda çalışıyor?
Test, staging ve production ayrımı net mi?
Agentin konuştuğu servisler listelendi mi?

2. Veri ve Retrieval Kontrolü

Retrieval kaynakları envanterde mi?
Hassas veri sınıflandırması yapıldı mı?
Kullanıcı yetkisine göre doküman filtreleme var mı?
Cross-tenant retrieval test edildi mi?
Prompt ve retrieval loglarında kişisel veri tutuluyor mu?

3. Tool Permission

Her tool için read/write/delete/deploy seviyesi yazıldı mı?
Tool erişimi role göre ayrılıyor mu?
Tool parametreleri doğrulanıyor mu?
Kritik tool’lar insan onayı istiyor mu?
Tool token’ları minimum yetkiyle mi çalışıyor?

4. Memory Güvenliği

Memory kalıcı mı geçici mi?
Memory’ye kim yazabiliyor?
Kullanıcı memory’si tenant veya hesap bazında ayrılıyor mu?
Zararlı kalıcı talimatlar temizlenebiliyor mu?
Memory deletion ve export süreci var mı?

5. Runtime İzleme

Tool çağrısı loglanıyor mu?
Hangi kullanıcı adına çağrı yapıldığı tutuluyor mu?
Retrieval kaynağı ve dönen doküman ID’si izleniyor mu?
Onaylanan ve reddedilen aksiyonlar ayrılıyor mu?
Şüpheli agent davranışı için alert var mı?

6. Abuse Senaryoları

Test edilecek temel senaryolar:

Prompt injection ile tool çağrısı zorlamak.
RAG dokümanına dolaylı talimat yerleştirmek.
Başka tenant verisini retrieval’a sokmayı denemek.
Fazla yetkili token ile write aksiyon almak.
Memory’ye kalıcı zararlı talimat bırakmak.
MCP server üzerinden beklenmeyen dosya veya komut erişimi denemek.

Karar Tablosu

| Durum | Risk | Aksiyon | | --- | --- | --- | | Agent sadece cevap veriyor | Orta | Prompt ve veri sızıntısı testi | | Agent RAG kullanıyor | Yüksek | Permission-aware retrieval testi | | Agent tool çağırıyor | Yüksek | Tool permission assessment | | Agent write/delete yapıyor | Kritik | Runtime enforcement ve onay | | Agent MCP kullanıyor | Kritik | MCP server ve tool review |

Yanlış Bilinenler

“Checklist güvenlik testi yerine geçer”

Hayır. Checklist hazırlık sağlar. Gerçek güvenlik testi, bu kontrollerin saldırgan senaryolarıyla doğrulanmasıdır.

“Agent küçükse risk küçüktür”

Risk agentin boyutuyla değil, eriştiği veri ve aksiyonla ölçülür.

“Sadece log tutmak yeter”

Log önemlidir ama kritik aksiyonu durdurmaz. Enforcement ve onay mekanizması ayrıca gerekir.

Profesyonel Destek Eşiği

Checklist içinde üçten fazla “hayır” cevabı varsa veya agent production verisi/tool’u kullanıyorsa profesyonel assessment mantıklıdır.

Eresus Security, AI agent güvenliğinde checklist’i test planına çevirir; tool abuse, retrieval leakage, MCP riskleri ve runtime yetki sınırlarını kanıtla doğrular.

SSS

Bu checklist kimler için?

AI ürün ekipleri, backend geliştiriciler, güvenlik ekipleri ve governance sorumluları için uygundur. Amaç teknik ve iş ekiplerini aynı risk haritasında buluşturmaktır.

İlk hangi maddeye bakılmalı?

Tool izinleri ve veri erişimi. Agentin neye eriştiği ve ne yapabildiği bilinmeden diğer kontroller doğru önceliklendirilemez.

Checklist ne sıklıkla güncellenmeli?

Yeni tool eklendiğinde, model değiştiğinde, retrieval kaynağı değiştiğinde veya agent yeni bir role açıldığında güncellenmelidir.

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?