AI ajanında model testi yetmez: Üç çalışma anı kapısı gerekiyor
AI ajanı çalışma zamanı güvenliği, gerçek bir görev sürerken kullanıcı istemini, yürütülmek üzere olan araç çağrısını ve araçtan dönen yanıtı denetleyen koruma katmanıdır. Model testi bu katmanın yerini tutmaz; çünkü üretimdeki risk, modelin eriştiği kimlikler, dosyalar, API’ler, komutlar ve dış içerikle birlikte oluşur.
Uygulanabilir mimari ajan döngüsünü üç karar kapısına ayırır: kullanıcı istemi, yürütme öncesi araç çağrısı ve araç yanıtı. Her kapı için görülebilen veri, uygulanacak politika, engelleme yetkisi, saklanacak kanıt ve kapsama dışında kalan akış ayrı tanımlanmalıdır.
Model testi neden çalışma zamanı kontrolünün yerini tutmaz?
Model değerlendirmesi, seçilmiş istemler karşısındaki davranışı ölçebilir; ancak üretimde hangi kullanıcının hangi yetkiyle işlem yaptığını veya araç parametrelerinin hangi dış etkiyi doğuracağını tek başına denetlemez. Güvenli yanıt veren bir model, fazla yetkili bir ajan kabuğu içinde hassas dosya okuyabilir, yanlış kaydı değiştirebilir ya da dış içerikteki gizli talimatı görev emri sanabilir.
11 Ağustos 2026’da sunulan Agent Safety Should Be a Runtime Contract ön baskısı, 52 belgelenmiş AI ajanı ve LLM güvenlik olayını inceleyip 12 açık ajan sistemi ile çalıştırma katmanını yörünge şeması açısından değerlendiriyor. Yazarlar güvenlik biriminin yalnızca model değil, doğrulanabilir kanıtla birlikte tüm ajan yörüngesi olması gerektiğini savunuyor; tehlikeli eylemi önceden durduran kontroller ile doğru sonucun oluştuğunu test, günlük, dosya farkı veya kaynak dayanağıyla gösteren kontrolleri birbirinden ayırıyor.
Bu nedenle model değerlendirmesi ile çalışma zamanı denetimi rakip değil, farklı riskleri kapsayan iki katmandır. Aynı ayrım, model ve araç sınırlarının ayrılmasında da belirleyicidir.
Birinci kapı: İstemi kimlik ve görev sınırıyla değerlendirin
İlk kapı yalnızca zararlı sözcük aramamalıdır. Kullanıcının ve oturumun kimliği, başlatılmak istenen görev, ajanın tanımlı amacı, verinin hassasiyeti ve talebin gerektirdiği yetki birlikte değerlendirilmelidir.
Microsoft Defender’ın önizleme belgesi, desteklenen yerel ajanlarda kullanıcı istemini, yürütme öncesi araç isteğini ve yürütme sonrası araç yanıtını ayrı kontrol noktalarında inceliyor; olay türünün desteğine göre istemin işlenmesini, araç eyleminin çalışmasını veya yanıtın ajan döngüsünde ilerlemesini engelleyebiliyor. Belge, ajanların sunduğu yapılandırılmış olay arayüzleri ile desteklenen ajan-LLM ağ akışlarının incelenmesini de iki ayrı yöntem olarak tanımlıyor; ağ incelemesinin sertifika sabitleme veya HTTP/3 kullanan ajanları desteklemediğini belirtiyor.
Kurumsal politika bu kapıda üç sonuç üretebilir: düşük etkili ve yetkili göreve izin vermek, belirsiz fakat yüksek etkili görevi insan onayına göndermek veya kapsam dışı talebi ajan çalışmadan reddetmek. Kayıt en azından oturum ve kullanıcı kimliğini, görev sınıfını, politika sürümünü, kararı, gerekçe kodunu ve zamanı içermeli; ham istemin saklanması veri minimizasyonu ve erişim kurallarıyla sınırlandırılmalıdır.
İkinci kapı: Araç çağrısını dış etki oluşmadan kesin
Asıl yaptırım noktası, ajanın seçtiği araç çalıştırılmadan hemen öncedir. Politika araç adının yanında hedef sistemi, yöntem ve parametreleri, kullanıcı ile ajan kimliğini, veri sınıfını, önceki adımları ve işlemin geri alınabilir olup olmadığını değerlendirmelidir.
“Bu ajan CRM kullanabilir” izni tek başına fazla geniştir. Okuma ve yazma ayrılmalı; alıcı, kayıt kümesi, dosya yolu, komut türü, tutar veya işlem sayısı gibi parametreler açık sınırlarla yetkilendirilmelidir. Yüksek etkili işlemlerde kısa ömürlü onay, en az ayrıcalıklı servis kimliği ve yinelenen isteğin aynı işlemi ikinci kez üretmesini önleyen idempotency denetimi kullanılabilir.
Engelleme kararı ajanın kendi muhakemesinin dışında uygulanmalıdır. Sistem istemindeki “tehlikeli işlem yapma” talimatı davranışı yönlendirir; fakat araç çağrısını zorunlu olarak kesemiyorsa teknik bir yaptırım noktası değildir.
Denetim izi, istenen araç ile parametrelerin korunmuş özetini, kullanılan politika sürümünü, izin-engelle-onaya gönder sonucunu, kararı veren bileşeni ve aracın gerçekten başlatılıp başlatılmadığını göstermelidir. Böylece inceleme yalnızca ajanın niyetini değil, önlenen veya gerçekleşen dış etkiyi de ortaya koyar.
Üçüncü kapı: Araç yanıtını güvenilmeyen yeni girdi sayın
Web sayfası, depo belgesi, e-posta veya başka bir ajan yanıtı başarılı bir araç çağrısından dönmüş olsa da güvenilir kabul edilemez. Üçüncü kapı; dolaylı prompt injection işaretlerini, hassas veriyi, beklenmeyen içerik türünü, kaynak bilgisini ve yanıtın aracın beklenen şemasına uyup uymadığını denetlemelidir.
Bu kapının sınırı önemlidir: araç yanıt verdiyse ilk çağrı zaten gerçekleşmiş olabilir. Kontrol şüpheli içeriğin ajan bağlamına eklenmesini, yeni bir aracı tetiklemesini veya kullanıcıya ya da başka bir sisteme aktarılmasını durdurabilir; daha önce oluşmuş dış etkiyi kendiliğinden geri almaz.
Kayıtta araç kimliği, şema doğrulaması, veri sınıflandırma sonucu, içerik kaynağı, karar ve izin verilen sonraki adım bulunmalıdır. Büyük veya hassas yanıtları günlükte çoğaltmak yerine değiştirilemez özetler ile erişimi denetlenen kanıt depoları kullanmak, inceleme kabiliyeti ile veri minimizasyonunu birlikte korur.
Audit’ten bloklamaya kanıtla geçin
Doğrudan tüm ajanlarda bloklama açmak, yanlış pozitifler nedeniyle iş akışlarını kesebilir; süresiz audit modu ise zararlı eylemi önlemez. Geçiş, her kapının gerçek bir kesme noktası sunduğu ve karar kayıtlarının oturumu uçtan uca yeniden kurabildiği doğrulandıktan sonra yapılmalıdır.
- Ajanları, kullandıkları araçları ve geri alınması zor görevleri envanterleyin; üç kapının hangilerinde yalnızca görünürlük, hangilerinde gerçek bloklama bulunduğunu belirleyin.
- Temsilî küçük bir grupta audit çalıştırın; olayları gerçek tehdit, beklenen davranış, yanlış pozitif veya kanıtı yetersiz kayıt olarak sınıflandırın.
- Politika ve istisnaları sürümleyin; karar gecikmesini, kayıp olayları ve kontrol katmanına erişilemediğinde sistemin açık mı kapalı mı davranacağını sınayın.
- Önce komut çalıştırma, veri aktarımı ve geri alınması zor yazma işlemlerini blok moduna alın; kapsamı ölçülen sonuçlara göre genişletin.
Microsoft’un önizleme dağıtım talimatı, küçük bir cihaz grubunda audit ile başlamayı, uyarıları bir ila iki hafta incelemeyi, ardından audit kapsamını genişletip sonuçlar doğru ve eyleme geçirilebilir olduğunda seçilen gruplarda blok moduna geçmeyi öneriyor. Bu süre evrensel bir güvenlik eşiği değildir; kurum yeterli örneği kendi işlem hacmi, yanlış pozitif maliyeti ve kritik araç kapsamına göre tanımlamalıdır.
Satıcı veya platform ekibi her kapıda hangi olayları görebildiğini, hangi eylemleri yürütmeden önce gerçekten durdurabildiğini ve oturumun hangi kanıtlarla yeniden kurulacağını gösterebilmelidir. İstem görünürken araç parametreleri kayıpsa, araç çağrısı denetlenirken dış yanıt taranmıyorsa veya “block” kararı yalnızca uyarı üretiyorsa üç kapılı çalışma zamanı kapsamı tamamlanmış değildir.
Ayrıca okuyun:
Bültenimize abone olun
En son Web3, yapay zekâ ve kripto haberleri doğrudan gelen kutunuza gelsin.