Şu anda, şirketinizin bir yerinde bir AI ajanı çalışıyor. Belki repolarınıza erişen bir personal access token'a sahip bir kod asistanı, belki OAuth izniyle CRM'inizi okuyan bir destek copilot'u, belki de finanstan birinin fatura mutabakatı için kurduğu bir otomasyon. Kimse onu bir sistem olarak onaylamadı. Kimse sahibi değil. Ve üretim verisine çoktan dokunuyor.
Shadow AI kavramının bugünkü hali bu: çalışanların bir chatbot'a metin yapıştırması değil, gerçek kimlik bilgileriyle ortamınızın içinde çalışan ajanlar — hem de hiçbir envanterde görünmeyen kimlik bilgileriyle.
Kimsenin vermediği erişim
Ajanların bugün erişimi nasıl edindiğine yakından bakınca tablo netleşiyor:
- Kimsenin takip etmediği API anahtarları ve OAuth token'ları taşıyorlar. Anahtar aceleyle üretilir, bir config dosyasına ya da environment değişkenine yapıştırılır ve unutulur. Nadiren süresi dolar, nadiren döndürülür; anahtarı üreten kişi şirketten ayrıldığında anahtar çalışmaya devam eder.
- Ödünç yetkilerle hareket ediyorlar. En yaygın kısayol, ajanı bir insanın hesabı ya da ortak bir servis hesabı altında çalıştırmaktır. Ajan böylece o kimliğin yapabildiği her şeyi devralır — ki bu neredeyse her zaman ihtiyacından kat kat fazladır.
- Hesap verecek bir sahipleri yok. Ajan hata yaptığında talep kime açılacak? Prototipi yazan geliştirici aylar önce ekipten ayrılmış. İş birimi "sadece kullanıyor". Sahiplik hiç atanmadığı için hesap verebilirlik de yok.
- Anlamlı bir denetim izi bırakmıyorlar. Loglarda kayıtları silenin servis hesabı, raporu dışarı aktaranın kullanıcının token'ı olduğu görünür. İşlemi bir insanın mı yoksa bir ajanın mı yaptığı — hangi ajanın, kimin talimatıyla yaptığı — görünmezdir.
Bunların her biri, konu bir insan kullanıcı ya da servis hesabı olsaydı denetim bulgusu olurdu. Ajanlarda ise şu an varsayılan durum bu.
Prompt injection, dağınıklığı ihlale çevirir
Bu konuyu "dağınık ama idare eder" değil de acil saymak için somut bir sebep var: prompt injection. Dış içerik okuyan bir ajan — e-postalar, talepler, web sayfaları, dokümanlar — o içerik tarafından yönlendirilebilir. Özenle hazırlanmış bir e-posta, destek ajanına müşteri verilerini iletmesini söyleyebilir; zehirlenmiş bir doküman, kod ajanına secret'ları dışarı sızdırmasını fısıldayabilir.
Kritik ayrıntı şu: kandırılan ajan "AI yetkileriyle" hareket etmez. Elindeki gerçek kimlik bilgileriyle hareket eder. Ajanın CRM'inizi okuyabilen bir token'ı varsa, injection saldırısının da o token'ı var demektir. Model seviyesindeki korumalar işe yarar; ama hiçbir model üreticisi bunların su geçirmez olduğunu iddia etmiyor. Dolayısıyla başarılı bir injection'ın blast radius'unu tamamen ajanın kimlik bilgilerinin izin verdikleri belirler.
Bu da problemi yeniden çerçeveler: Modelin ne yapacağını tam olarak kontrol edemezsiniz. Ama kimliğinin neye izinli olduğunu kontrol edebilirsiniz.
Cevap daha akıllı bir model değil, kimlik
Agentic AI güvenliğinin basit bir ilkede buluşmasının sebebi tam olarak bu: Ajanları, üzerinde çalıştıkları model ya da framework'ten bağımsız olarak kimlik katmanında yönetin. Modeller her çeyrek değişecek; yönetişim katmanı değişmemeli.
Pratikte bu şu anlama geliyor:
Her ajan için birinci sınıf bir kimlik ve isimli bir sahip. Bir ajan dizininizde tıpkı bir çalışan gibi var olmalı: yaşam döngüsü olan ayrı bir AI ajan kimliği, hesap verebilir bir insan sahibi ve bir işten çıkarma süreci. Sahibi şirketten ayrıldığında ajanın erişimi gözden geçirilmeli — sahipsiz kalmamalı.
Yapıştırılan anahtarlar yerine kasada saklanan kimlik bilgileri. API anahtarları, token'lar ve secret'lar bir kasada durmalı; çalışma anında enjekte edilmeli, otomatik döndürülmeli ve asla bir config dosyasında beklememeli. Ajan kimlik bilgisini kullanır, ona sahip olmaz.
En az yetki ve on-behalf-of kapsamı. Bir ajanın kalıcı yetkisi var olmaya yetecek kadar — yani neredeyse sıfır — olmalı; görev yetkilerini dinamik olarak edinmeli. Bir kullanıcı adına iş yaptığında on-behalf-of çalışmalı: yetkisi, kullanıcının yapabildikleriyle ajana duyulan güvenin kesişimiyle sınırlanmalı ve denetim izine her iki kimlik de yazılmalı.
MCP gateway üzerinden allow-list'e bağlı tool erişimi. Model Context Protocol (MCP), ajanların tool'lara ve veri kaynaklarına bağlanmasının standart yolu haline geldi — bu da onu kontrol için en doğal boğaz noktası yapıyor. Ajanlarla tool'lar arasına konumlanan bir MCP gateway, her ajanın hangi tool'ları çağırabileceğini allow-list ile belirler, her çağrıyı ajanın kimliğine karşı doğrular ve loglar. Açıkça izin verilmeyen şey, erişilebilir bile değildir.
Kapalıya düşen (fail-closed) insan onayı. Hassas işlemler — ödemeler, silmeler, yetki değişiklikleri, dışarıya iletişim — human-in-the-loop onayına bağlanmalı. Ve mekanik önemli: Onaylayan yanıt vermezse işlem kapalıya düşmeli. Onayı bekleyen ajan hiçbir şey yapmaz; varsayılan olarak asla devam etmez.
Kill-switch, güven skoru ve denetim. Bir ajan beklenmedik davrandığında, kimlik bilgilerini iptal edip oturumlarını anında durduran tek bir aksiyona ihtiyacınız var — API konsollarında hazine avına değil. Ajanın davranışına dayalı sürekli güven skorlaması bunu otomatik tetikleyebilir; her işlem de insan kimliklerinizin zaten kullandığı denetim izine düşer.
Politika dokümanıyla değil, envanterle başlayın
Bunların hiçbiri ajanları yasaklamayı gerektirmiyor — o savaş zaten kaybedildi ve üretkenlik kazancı gerçek. Gereken, ajanlara zaten oldukları şey gibi davranmak: sistemlerinize erişimi olan, hızla büyüyen bir insan-dışı kimlik nüfusu.
Pratik ilk adım görünürlük. Halihazırda var olan ajanları bulun, taşıdıkları kimlik bilgilerini bulun ve her birine bir sahip atayın. Sonrası — kasaya alma, kapsam daraltma, onaya bağlama — bilinen mühendislik işidir; çünkü kimlik ekipleri bunların hepsini insanlar ve servis hesapları için zaten yaptı.
İkinci adım ise ajanları mevcut kimlik süreçlerinize dahil etmek. İnsan kimlikleri için işleyen ne varsa — işe alım ve işten çıkış akışları, periyodik erişim gözden geçirmeleri, yetki sertifikasyonları — ajanlar için de işlemeli. Üç ayda bir "bu ajan hâlâ gerekli mi, bu yetkilere hâlâ ihtiyacı var mı, sahibi hâlâ şirkette mi" diye soran bir gözden geçirme, sahipsiz ajan birikimini daha oluşmadan engeller.
Bu işi doğru yapan kurumlar en katı AI politikasına sahip olanlar değil; ajanlarına erken kimlik verenler. Uçtan uca nasıl göründüğünü merak ediyorsanız: Monofor AI'ı nasıl güvence altına alıyor.
