AI ajanında tek filtre yetmez: Altı çalışma zamanı kontrolü

AI ajanı çalışma zamanı güvenliği, tek bir istem enjeksiyonu filtresiyle değil; aracın ne yapabileceğini, kimin adına çalıştığını, hangi bilgiyi sakladığını ve riskli bir eylemin nasıl durdurulacağını ayrı ayrı denetleyerek sağlanır. Küçük bir ekip için uygulanabilir asgari paket altı parçadan oluşur: dar araç izinleri, deterministik insan onayı, ayrı ajan kimliği, bellek yalıtımı, uçtan uca gözlemlenebilirlik ve acil durdurma.

Bu kontroller birbirinin alternatifi değildir. Filtre zararlı bir talimatı kaçırabilir; izin katmanı yetkisiz kaynağa erişimi, onay kapısı ise geri döndürülemez işlemin otomatik yürütülmesini engelleyebilir. Amaç modelin daima doğru karar vereceğini varsaymak değil, yanlış veya manipüle edilmiş bir kararın etkisini sınırlamaktır.

Önce tehdidi eylem noktasında tanımlayın

Korunacak bileşen yalnızca sohbet kutusu değildir. Ajan; kullanıcı girdisinden, web sayfasından, dosyadan, e-postadan veya araç yanıtından talimat alabilir, ardından API çağırabilir ya da kalıcı belleğe kayıt yapabilir. OWASP AI Agent Security rehberi, doğrudan ve dolaylı istem enjeksiyonunun yanında araç kötüye kullanımı, yetki yükseltme, veri sızdırma, bellek zehirleme ve aşırı özerkliği ayrı riskler olarak ele alıyor.

Bu ayrım, hangi kontrolün hangi tehdidi durdurduğunu gösteren bir matris kurmayı sağlar:

• Yetkisiz araç veya kaynak erişimi: Araç izinleri ve ajan kimliği.
• Silme, ödeme veya dışarıya ileti gönderme: Eyleme bağlı insan onayı.
• Sonraki oturumları etkileyen zararlı kayıt: Bellek yalıtımı ve yazma doğrulaması.
• Gizli veri taşıyan araç parametresi: Çağrı öncesi denetim ve veri çıkış politikası.
• Tekrarlayan ya da kontrolden çıkan çalışma: İzleme, kullanım sınırları ve acil durdurma.

Matrisin bir de “açık kalan risk” sütunu olmalıdır. Örneğin salt okunur erişim değişiklik yapılmasını engeller; ancak ajanın okuyabildiği hassas veriyi yanıtına veya başka bir araç çağrısına eklemesini tek başına önlemez.

1. Araç izinlerini daraltın, 2. yüksek etkili eylemi onaya bağlayın

Her ajan rolü için kullanılabilecek araçları izin listesiyle tanımlayın ve varsayılan kararı ret yapın. “Dosya sistemi”, “veritabanı” veya “e-posta” gibi geniş yetkiler yerine kaynak, işlem ve hedef düzeyinde kapsam belirleyin: belirli bir dizinde okuma, belirli tabloda sorgu ya da yalnızca kurumsal alan adına taslak oluşturma gibi. Serbest kabuk çalıştırma, genel HTTP isteği veya sınırsız veritabanı yazma yetkisi, filtreden geçen zararlı bir talimatın etki alanını gereksiz yere büyütür.

İnsan onayını her adıma eklemek operasyonu kilitler; hiç eklememek ise yüksek etkili işlemleri model muhakemesine bırakır. Silme, para transferi, erişim rolü değiştirme, üretime dağıtım ve harici ileti gönderme gibi eylemleri ayrı risk sınıfına koyun. Onay ekranı araç adını, hedefi ve normalize edilmiş parametreleri göstermeli; verilen yetki yalnızca gösterilen işlem için ve kısa süreyle geçerli olmalıdır.

Microsoft’un katmanlı ajan güvenliği yaklaşımı, yüksek riskli veya geri döndürülemez işlemlerde insan incelemesinin model kararına değil orkestrasyon mantığına bağlanmasını, izinlerin ise kapalı başlayıp role ve riske göre açılmasını öneriyor. Bu nedenle “kullanıcı onayladı mı?” sorusunu modelin yorumlaması yerine yürütme bileşeni, işleme ve parametrelerine bağlanmış geçerli onay kaydını doğrulamalıdır.

3. Ajana ayrı kimlik verin, 4. belleği güven sınırlarına ayırın

Ajanı geliştiricinin, son kullanıcının veya sunucunun genel kimlik bilgileriyle çalıştırmayın. Her ajan ya da görev türü doğrulanabilir bir servis kimliğine sahip olmalı; kısa ömürlü kimlik bilgileri yalnızca gereken araç ve kaynak kapsamı için üretilmelidir. Böylece ele geçirilen bir oturumun başka projelere veya yönetim işlevlerine sıçraması zorlaşır, denetim kaydında işlemi yapan özne açıkça görülür.

Kimlik kontrolü, yetkili ajanın zararlı içeriği belleğe yazmasını engellemez. Oturumluk çalışma belleğini kalıcı profilden ayırın; kullanıcılar, kiracılar ve güven düzeyleri arasında aynı bellek alanını paylaşmayın. Dış kaynaktan gelen metni güvenilmeyen veri olarak işaretleyin; kalıcılaştırmadan önce hassas bilgi ve enjeksiyon denetiminden geçirin, saklama süresi ile boyut sınırı uygulayın.

Bu kontrol bellek zehirlemesinin kalıcılığını azaltır; ancak güvenilir görünen yanlış bilginin kaydedilmesi riskini tamamen ortadan kaldırmaz. Kritik kayıtlar için kaynak, yazan ajan ve zaman bilgisi tutulmalı; bütünlük doğrulaması ve silme mekanizması bulunmalıdır.

5. İstemden araç sonucuna kadar gözlemleyin

Yalnızca son sohbet yanıtını kaydetmek, ajanın hangi aracı hangi parametrelerle çağırdığını göstermez. Kullanıcı veya görev kimliği, ajan ve politika sürümü, araç adı, hedef kaynak, izin kararı, onay kimliği ve sonuç durumu yapılandırılmış olaylar olarak tutulmalıdır. Parola, erişim belirteci ve kişisel veri gibi değerler günlük oluşturulmadan önce maskelenmelidir.

Denetim noktalarını ajan döngüsüne yerleştirin: kullanıcı istemi alınırken, araç çağrısı yürütülmeden önce ve araç yanıtı modele geri verilmeden önce. Önizleme statüsündeki Microsoft Defender çalışma zamanı koruması, desteklenen ajanlarda bu noktaları denetleyebildiğini, bulguları audit modunda kaydedebildiğini ve desteklenen eylemleri block modunda çalışmadan önce durdurabildiğini belirtiyor; belge ayrıca doğruluğu gözlemek için audit moduyla başlamayı öneriyor.

Gözlemlenebilirlik geçmişi açıklamaya yarar, fakat tek başına saldırıyı durdurmaz. Uyarıları tekrarlanan retler, olağandışı araç sıklığı, hassas kaynağa erişim ve onay atlatma denemeleri gibi müdahale edilebilir koşullara bağlayın.

6. Acil durdurmayı modelin dışına yerleştirin

Acil durdurma, ajana “artık çalışma” diye yeni bir istem göndermek değildir. Orkestratör yeni işleri kabul etmeyi kesmeli, kuyruktaki eylemleri iptal etmeli, aktif araç kimlik bilgilerini geri çekmeli ve devam eden çağrıları mümkün olduğunda sonlandırmalıdır. Bu kontrolü çağrı yolunun dışındaki yetkili bir operatör veya otomatik devre kesici tetikleyebilmelidir.

Durdurma koşullarını önceden tanımlayın: belirli sürede aşırı araç çağrısı, art arda politika ihlali, beklenmeyen ayrıcalıklı kaynak erişimi veya veri çıkışı alarmı gibi. Geri alınabilen işlemler için telafi adımları hazırlayın. Para transferi veya harici ileti gibi geri döndürülemeyen işlemlerde asıl güvence, işlemin daha önceki onay kapısında tutulmasıdır.

Audit’ten engellemeye geçiş sırası

Kontrolleri ölçülebilir bir sırayla devreye almak, üretim davranışını görürken kritik yetkileri baştan sınırlamayı sağlar:

1. Ajanları, kullandıkları araçları, kimlikleri ve eriştikleri veri sınıflarını envantere alın.
2. Ayrı ajan kimliklerini oluşturun; araç ve kaynak izinlerini salt okunur, dar kapsamlı başlangıç politikasıyla sınırlandırın.
3. İstem, araç isteği ve araç yanıtı denetimini audit modunda açın; günlüklerde sırları maskeleyin.
4. Kalıcı bellek yazmayı varsayılan olarak kapatın; gerekli kayıtlar için yalıtım, saklama süresi ve doğrulama kuralları ekleyin.
5. Yüksek etkili eylemleri parametreye bağlı insan onayına alın; geçerli onayı bulunmayan yürütme isteğini deterministik olarak reddedin.
6. Normal davranış gözlemlerine göre kuralları ayarladıktan sonra güven düzeyi yüksek bulguları engelleme moduna geçirin ve acil durdurma mekanizmasını tatbik edin.

Başarı ölçütü, enjeksiyon filtresinin hiç hata yapmaması değildir. Yetkisiz aracın politika katmanında reddedilmesi, onaysız kritik işlemin yürümemesi, güvenilmeyen içeriğin başka oturuma taşınmaması, olay zincirinin incelenebilmesi ve gerektiğinde ajan yetkilerinin hızla iptal edilebilmesidir.

Ayrıca okuyun:

• #İşbirliği tek başına yetmeyebilir: Türkiye’de reklam etiketi kontrolü
• SonicWall SMA1000 saldırı altında: Yama tek başına yetmeyebilir
• İstisna belgesi yetmiyor: İçerik geliri tek banka hesabından geçmeli