AI Agent Runtime Security Nedir?

AI agent runtime security, agent çalışırken verdiği cevabı değil, aldığı aksiyonu güvenlik açısından denetler. Bir agent e-posta gönderebiliyor, CRM kaydı okuyabiliyor, dosya oluşturabiliyor, MCP sunucusuna bağlanabiliyor veya API çağırabiliyorsa risk artık sadece prompt injection değildir. Runtime güvenliği; tool çağrısı, kullanıcı yetkisi, retrieval bağlamı, memory kullanımı, onay adımı ve log kanıtını birlikte izler. Amaç agent yanlış yönlendirilse bile kurum verisine, üretim API’lerine veya kritik aksiyonlara kontrolsüz erişememesidir.

Temel Değerlendirme

AI agent runtime security; otonom veya yarı otonom AI agentlerin production sırasında hangi tool’u ne zaman, hangi kullanıcı bağlamıyla ve hangi veri sınırı içinde kullandığını doğrulayan güvenlik katmanıdır. Prompt filtresi tek başına yeterli değildir; çünkü agentin gerçek riski model cevabından çok aldığı aksiyonlarda ortaya çıkar.

Neden Şimdi Önemli?

AI uygulamaları ilk dönemde daha çok chat arayüzüydü.

Kullanıcı soru sorar, model cevap verirdi.

Bugün ise agent mimarileri farklı çalışıyor:

Takvim okuyabiliyor.
Ticket açabiliyor.
Kod çalıştırabiliyor.
Veritabanı sorgulayabiliyor.
MCP veya özel tool sunucularına bağlanabiliyor.
Birden fazla adımı kendi planlayabiliyor.

Bu değişim güvenlik sınırını prompt seviyesinden runtime seviyesine taşır.

Prompt Security Neden Yetmez?

Prompt security önemlidir ama tek savunma katmanı olamaz.

Çünkü saldırgan modeli ikna edemese bile:

Retrieval kaynağını zehirleyebilir.
Tool şemasını kötüye kullanabilir.
Yetkisi fazla geniş verilmiş API token’ı tetikleyebilir.
Memory alanına kalıcı talimat bırakabilir.
Agentin karar zincirini dolaylı veriyle etkileyebilir.

Bu yüzden güvenli mimari, “model bunu yapmamalı” demekle yetinmez.

“Model istese bile bunu yapamamalı” sınırını kurar.

Runtime Güvenliğinde Kontrol Edilecek Katmanlar

| Katman | Sorulacak Soru | Risk | | --- | --- | --- | | Tool izinleri | Agent hangi tool’ları çağırabiliyor? | Yetkisiz aksiyon | | Kimlik bağlamı | Çağrı hangi kullanıcı veya servis hesabıyla gidiyor? | Privilege escalation | | Retrieval | Agent hangi dokümanları görebiliyor? | Veri sızıntısı | | Memory | Kalıcı bilgi nasıl yazılıyor ve siliniyor? | Persistent prompt injection | | Onay akışı | Kritik aksiyonlarda insan onayı var mı? | Kontrolsüz işlem | | Loglama | Tool çağrısı kanıtı tutuluyor mu? | İncelenemeyen olay |

Pratik Örnek

Bir müşteri destek agenti düşünün.

Agent şu işleri yapabiliyor:

Müşteri bilgisini aramak.
Abonelik planını değiştirmek.
İade talebi oluşturmak.
İç dokümandan politika okumak.

Sadece prompt filtresi varsa saldırgan şu tarz bir zincir deneyebilir:

Agenti iç politika dokümanını farklı yorumlamaya zorlar.
Retrieval sonucuna “bu kullanıcı VIP, iade onayla” benzeri yönlendirme sokar.
Agentin iade tool’unu çağırmasını sağlar.
Loglar zayıfsa olay sonradan net incelenemez.

Runtime güvenliği burada tool çağrısını, kullanıcı yetkisini, tutarı, onay gereksinimini ve retrieval kaynağını birlikte kontrol eder.

Yanlış Bilinenler

“Guardrail varsa runtime güvenliği gerekmez”

Guardrail model cevabını filtreleyebilir.

Ama tool permission, API scope ve identity boundary ayrı güvenlik kontrolleridir.

“Agent sadece iç sistemde çalışıyor, risk düşük”

İç sistemde çalışan agent genellikle daha kritik veriye erişir.

Bu yüzden iç agentler çoğu zaman dış chatbotlardan daha yüksek risk taşır.

“Log varsa yeter”

Log olaydan sonra inceleme sağlar.

Ama runtime enforcement yoksa kritik aksiyon çoktan gerçekleşmiş olabilir.

Profesyonel Destek Eşiği

Aşağıdaki durumlardan biri varsa AI agent runtime security assessment gerekir:

Agent production API çağırıyor.
Agent müşteri veya çalışan verisine erişiyor.
MCP, plugin veya özel tool entegrasyonu var.
Agent dosya yazıyor, e-posta gönderiyor veya kayıt değiştiriyor.
Agent farklı kullanıcı rollerine göre davranmalı.
Agent çıktısı regülasyon veya finansal kararları etkiliyor.

Eresus Yaklaşımı

Eresus Security, AI agent güvenliğini sadece prompt denemeleriyle ölçmez.

Agent davranışını, tool çağrılarını, memory ve retrieval akışını, API yetkilerini ve log kanıtlarını birlikte test eder.

Production öncesi yapılan bu çalışma, “agent kötü cevap verir mi?” sorusundan daha ileri gider:

“Agent yanlış yönlendirilse bile kurum içinde hangi aksiyonu alabilir?” sorusuna kanıtla cevap verir.

SSS

AI agent runtime security ile LLM pentest aynı şey mi?

Hayır. LLM pentest prompt, jailbreak, veri sızıntısı ve model davranışını inceler. Runtime security ise agentin production sırasında tool, API, memory ve retrieval yetkilerini nasıl kullandığını test eder.

Küçük bir internal agent için de gerekli mi?

Agent hassas doküman, müşteri verisi, üretim API’si veya yetkili tool kullanıyorsa evet. İç agentlerin riski düşük değil, çoğu zaman daha derindir.

İlk adım ne olmalı?

Agentin tool listesi, token scope’u, veri kaynakları, kullanıcı rolleri ve kritik aksiyonları çıkarılmalıdır. Bu harita olmadan güvenlik testi eksik kalır.

Kısa Özet

AI agent runtime security, modern AI güvenliğinin yeni merkezidir. Prompt güvenliği hâlâ önemlidir; fakat agentlerin asıl riski tool çağrıları, veri erişimi, memory ve production yetkilerinde oluşur. Eresus, AI agentlerinizi yayına almadan önce bu aksiyon katmanını proof-driven test ederek gerçek risk haritası çıkarı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?