AI Ajan Güvenlik ve Hazırlık Denetimi

Bir AI ajanı metin üreten bir sohbet kutusundan farklıdır: veritabanı sorgular, API çağırır, e-posta gönderir, kayıt açar ya da siler. Demo aşamasında bu yetenekler genellikle geniş yetkili bir servis hesabıyla, tek bir API anahtarıyla ve kimsenin ayrıntısına bakmadığı bir araç listesiyle bağlanır. Ajan çalışır, ekip ikna olur ve aynı yapı fark edilmeden üretime taşınır. Sorun o noktada başlıyor: ajanın neye erişebildiğini, hangi veriyi hangi modele gönderdiğini ve bir işlemi kimin onayıyla yaptığını yazılı olarak gösteremeyen bir sistem, güvenlik ve uyum ekibinin onayından geçemiyor ya da geçtiyse bir olay yaşandığında geriye dönük açıklanamıyor. AI Ajan Güvenlik ve Hazırlık Denetimi bu soruları üretime geçmeden önce cevaplamak için tasarlanmış sabit kapsamlı bir çalışma. Sonunda elinizde bir bulgu listesi değil, hangi ajanın hangi yetkiyle, hangi veri sınırı içinde ve hangi onay kapılarından geçerek çalışacağını gösteren bir hazırlık dosyası oluyor. Konunun arka planını ajanları üretime almanın asıl engeli üzerine yazımızda anlattık.

Bu denetim kimin için

Üç durumda işe yarıyor. Birincisi pilotu tamamlanmış, üretime alınması beklenen ama güvenlik ya da hukuk ekibinden onay bekleyen bir ajan projesi. İkincisi farklı ekiplerin kendi başına kurduğu ajanların, otomasyonların ve MCP bağlantılarının çoğaldığı, kimin neyi bağladığının artık tek bir yerden görülemediği şirketler. Üçüncüsü bir müşteri, denetçi ya da yatırımcı tarafından AI kullanımına dair yazılı açıklama istenen ekipler. Denetim, ajanı kendi ekibinizin mi, bir tedarikçinin mi yoksa hazır bir platformun mu kurduğuna bakmaksızın aynı kapsamla yürüyor. Ajan henüz yoksa ve yalnızca fikir aşamasındaysanız bu denetim erken; o durumda AI çözümleri tarafında kapsam görüşmesiyle başlamak daha doğru.

Denetimin kapsamı

Kapsam altı başlıktan oluşuyor ve her projede aynı. Başlıkların sabit olması önemli, çünkü denetimin değeri bir şeyin unutulmamasından geliyor: araç listesinde kimsenin hatırlamadığı tek bir silme yetkisi, bütün diğer önlemleri anlamsız kılabiliyor.

Ajan envanteri

Önce neyin var olduğunu çıkarıyoruz: hangi ajanlar çalışıyor, hangi modeli kullanıyor, hangi araçlara ve sistemlere bağlı, hangi kimlikle çalışıyor, kim tarafından kuruldu ve kimin sorumluluğunda. Envanter yalnızca ekiplerin beyanına dayanmıyor; servis hesapları, API anahtarları, MCP sunucu yapılandırmaları ve otomasyon platformlarındaki bağlantılar üzerinden doğrulanıyor. Çoğu kurumda ilk sürpriz bu aşamada çıkıyor: beyan edilen ajan sayısıyla gerçekten çalışan bağlantı sayısı nadiren aynı oluyor.

Yetki ve veri sınırı haritası

Her ajan için yaptığı işle sahip olduğu yetkiyi yan yana koyuyoruz. Sadece okuma yapması gereken bir ajanın yazma yetkisi, tek bir tabloya ihtiyacı olan bir ajanın bütün veritabanına erişimi ya da kullanıcı adına çalışması gereken bir ajanın yönetici hesabıyla bağlanması bu haritada görünür hale geliyor. Çıktı, en az yetki ilkesine göre her ajan için önerilen yetki seti ve hangi verinin sistem dışına, yani model sağlayıcısına çıkabileceğini gösteren veri sınırı tanımı. Kurumsal entegrasyonda bu yetki katmanının neden protokolden daha önemli olduğunu MCP yazımızda ele aldık.

KVKK risk değerlendirmesi

Ajanın işlediği kişisel verinin türü, hangi amaçla işlendiği, yurt dışındaki bir model sağlayıcısına aktarılıp aktarılmadığı, sağlayıcının veriyi eğitimde kullanıp kullanmadığı ve kayıtların ne kadar süre tutulduğu tek tek çıkarılıyor. Özel nitelikli kişisel veri, örneğin sağlık verisi, ayrı işaretleniyor. Bu teknik bir değerlendirme: aydınlatma metni ya da hukuki görüş yazmıyoruz, ama hukuk ekibinizin karar verebilmesi için ihtiyaç duyduğu veri akışını eksiksiz ve yazılı olarak önüne koyuyoruz.

Denetim izi ve insan onayı kapıları

Bir olay yaşandığında sorulacak ilk soru "ajan ne yaptı, neden yaptı ve kim onayladı" olur. Ajanın hangi aracı hangi parametreyle çağırdığının, hangi kullanıcı adına çalıştığının ve sonucun ne olduğunun kayıt altına alınıp alınmadığına bakıyoruz. Ardından geri alınamayan işlemleri, yani ödeme, silme, dışarıya gönderilen e-posta ya da müşteri kaydının değiştirilmesi gibi adımları ayırıyor ve bunların önüne hangi insan onayı kapısının konması gerektiğini tanımlıyoruz. Her işleme onay koymak ajanı kullanışsız yapar; hiçbirine koymamak ise riski görünmez yapar. Denge işlem bazında kuruluyor.

Prompt enjeksiyonu ve araç kötüye kullanımı

Ajanın okuduğu her içerik, yani bir e-posta, bir web sayfası, bir PDF ya da bir müşteri mesajı, ona talimat vermeye çalışabilir. Dolaylı prompt enjeksiyonu adı verilen bu saldırıda ajan, okuduğu metnin içindeki komutu kendi görevi sanıp elindeki araçla uygular. Denetimde ajanın güvenilmeyen içerikle karşılaştığı her noktayı belirliyor, bu içeriğin hangi araçları tetikleyebileceğine bakıyor ve kontrollü senaryolarla deniyoruz. Aynı başlıkta araç tanımlarının fazla geniş olup olmadığını, ajanın kendi yetkisini genişletebileceği bir yol bırakılıp bırakılmadığını ve maliyet ile çağrı sayısına sınır konup konmadığını da kontrol ediyoruz.

Üretime geçiş yol haritası

Son çıktı, bulguları maliyetine ve etkisine göre sıralayan yazılı bir plan. Hangi değişiklik üretimden önce zorunlu, hangisi ilk ay içinde yapılabilir, hangisi ise kabul edilmiş risk olarak kayda geçebilir; her madde için sorumlu rol ve kabul ölçütü belirtiliyor. Plan sizin ekibinizin uygulayabileceği ayrıntıda yazılıyor, bizim tarafımızdan uygulanması şart değil.

Nasıl ilerliyor

Denetim, ajan sayısına ve bağlı sistemlerin genişliğine göre iki ila dört hafta sürüyor. İlk hafta kapsam toplantısı, erişim tanımı ve envanter çıkarımıyla geçiyor. Denetim için üretim sistemlerinize yazma yetkisi istemiyoruz: yapılandırmalara, kod deposuna, kayıtlara ve mümkünse bir test ortamına okuma erişimi yeterli. Enjeksiyon ve araç kötüye kullanımı denemeleri yalnızca test ortamında ya da sizin onayladığınız kontrollü bir kapsamda yapılıyor. Her hafta sonunda kısa bir ara durum notu paylaşılıyor, böylece kritik bir bulgu denetimin bitmesini beklemeden ekibinize ulaşıyor. Son hafta bulgular teknik ekip ve karar vericilerle ayrı ayrı toplantıda anlatılıyor.

Teslim edilenler

• Ajan envanteri: her ajanın modeli, araçları, kimliği, bağlı sistemleri ve sorumlusu.
• Yetki ve veri sınırı haritası: mevcut yetkiyle önerilen en az yetkinin karşılaştırması ve sistem dışına çıkabilecek verinin tanımı.
• KVKK veri akışı dokümanı: hukuk ekibinizin değerlendirmesi için işlenen veri, amaç, aktarım ve saklama süresi.
• Onay kapısı tasarımı: geri alınamayan işlemlerin listesi ve her biri için önerilen insan onayı ile kayıt yapısı.
• Enjeksiyon ve araç kötüye kullanımı bulguları: denenen senaryolar, sonuçları ve önerilen düzeltmeler.
• Üretime geçiş yol haritası: önceliklendirilmiş, sorumlusu ve kabul ölçütü belli iş listesi.

Bu denetim neyi yapmaz

Bir sızma testinin yerini tutmuyor: altyapınızın ağ ve uygulama güvenliği kapsam dışında, ajanın kendisine ve bağlantılarına odaklanıyoruz. Hukuki görüş vermiyor, KVKK uyumunu onaylamıyor; teknik veri akışını çıkarıyor. Modelin cevap kalitesini ya da doğruluğunu ölçmüyor, bu ayrı bir değerlendirme işi. Ve "güvenli" diye bir sertifika vermiyor: yazılı bir durum tespiti ve yapılacaklar listesi veriyor. Ajanın kodu AI destekli araçlarla yazıldıysa ve uygulama katmanında da bir kontrol gerekiyorsa, bunu Vibe-Code to Production kapsamında ayrıca ele alıyoruz.

Denetimden sonra

Yol haritasını kendi ekibinizle uygulayabilirsiniz; doküman bunun için yazılıyor. Uygulamayı bize bırakmak isterseniz yetki daraltma, onay kapıları, kayıt yapısı ve enjeksiyon önlemleri ayrı bir iş olarak planlanıyor. Ajan sayısı arttıkça bu kararların kimin tarafından ve hangi ilkelere göre verileceği sorusu da büyüyor; sürekli teknik liderlik ihtiyacı olan ekiplerle bu işi CTO as a Service modeliyle sürdürüyoruz.