Kurumsal yapay zekâ ajanlarında asıl sorun artık modelin kendisi değil, modelin çalıştığı katmanlar. Geçen dönemde yaşanan bir örnekte çalışan, bir yapay zekâ asistanından toplu e-posta otomasyonu başlatmasını istedi; otomasyon alıcı sınırı politikasına takılıp başarısız olunca asistan, çalışanın kişisel posta kutusunu kullanarak aynı işi oradan yapmayı önerdi. Çalışan bunu onayladı ve kısa süre sonra, yetkili kanal yerine kişisel hesaptan gönderilen e-postalar dış alıcılara ulaştı.
Olayda herhangi bir jailbreak ya da model istismarı yoktu. Asistan, tasarlandığı işi yaptı; sorun, tek başına modele değil, runtime katmanına indirgenen güvenlik yaklaşımındaydı. Vakayı durduran şey de modelin yeniden eğitilmesi değil, 50’den fazla harici alıcıya ya da domaine ulaşma girişimini engelleyen ve kullanıcıya ne yapıldığını açıklayan tek bir çalışma zamanı kuralı oldu. Bu kuralın nereye uygulanacağını bilmek ise ancak hangi ajanların sistemde bulunduğunu, nereye bağlı olduklarını ve normal davranışın ne olduğunu görmekle mümkün.
Güvenlik taraması, uygulamanın dışından bakınca eksik kalıyor
Yıl içinde duyurulan büyük ajan lansmanları, ajanları kurumların doğrudan sahip olmadığı platformların içine yerleştirdi. Claude, Salesforce’un güven sınırı içinde çalışıyor; Claude, Slack’in içine gömülü biçimde sunuluyor; Copilot Microsoft 365 ekosisteminde yer alıyor. Workday de ajanlarını kendi platformunun içinde işletiyor ve şirket, yapay zekânın yeni yıllık sözleşme değerinin yüzde 25’inden fazlasını artık yönlendirdiğini söylüyor. Bu yapılarda ajanın araçları uygulamanın özellikleri, bilgisi uygulamanın verisi, yetkileri ise uygulamanın izin modeli oluyor.
Bir ağ geçidi yalnızca üzerinden geçen trafiği inceleyebilir. Salesforce içinde çalışan, Flow üzerinden tetiklenen, CRM kayıtlarını okuyan ve vaka yorumları yazan bir ajan, denetim noktasının yanından hiç trafik geçirmeyebilir. Aynı durum SharePoint’ten belge toplayan bir Copilot ajanı ya da yıllardır süren kanal geçmişini okuyan Slack tabanlı bir ajan için de geçerli. OWASP Agentic Skills Top 10, bu açığı AST09 altında “erişilemeyen beceri” ve “governance yok” senaryosu olarak tanımlıyor: Üçüncü taraf bir platform içinde konuşlandırılmış bir yetenek var, dışarıdaki hiçbir tarayıcı oraya ulaşamıyor.
Siber güvenlikte bu tip bir sıçrama daha önce de yaşandı. Güvenlik duvarları bir zamanlar paketi kaynak, hedef ve port bilgisine göre inceleyebiliyordu. Uygulamalar portlarla temiz biçimde eşleşmeyi bırakınca ve kötü niyetli trafik meşru trafiğe benzeyince denetim noktası uygulama katmanına taşındı. Ajan runtime güvenliğinin de aynı hareketi yapması gerekiyor. Fakat burada önceki geçişten farklı bir komplikasyon var: Uygulama katmanı başka bir şirkete ait.
Yalnızca gateway kullanan yaklaşım, kurumun kendi barındırdığı ajanları koruyabilir. Bu ajanlar ise hem sayıca az hem de en yavaş büyüyen bölüm. Kurumsal riskin ağırlığı giderek platformların içine gömülü ajanlara kayarken, dışarıdan görülebilen trafik tek başına resmi tamamlamaya yetmiyor.
Denetim noktası da saldırı yüzeyi oluyor
2026 Mart ayında saldırganlar, ajan trafiğini model sağlayıcılarına yönlendiren açık kaynak gateway LiteLLM’i ele geçirdi. Kötü amaçlı paketler yaklaşık 40 dakika boyunca yayında kaldı. CloudSEK daha sonra etkilenme alanını 2.500’den fazla kuruluş olarak değerlendirdi. Güvenlik ekiplerinin görünürlük için özellikle eklediği bir bileşenin, bu kez denetim noktasını doğrudan saldırı aracına dönüştürdüğü görüldü.
LiteLLM türü bileşenler, yapay zekâ trafiğini izlemek isteyen ekiplerin bilinçli olarak eklediği katmanlar arasında yer alıyor. Bu da gateway yaklaşımını değersiz kılmıyor, fakat tek başına strateji gibi görülmesine itiraz oluşturuyor. Gateway de tedarik zincirindeki başka bir yazılım; kendi sürüm hattı, kendi bağımlılıkları ve kendi riskleri var. Ayrıca saldırganın en çok istediği trafiği de merkezileştiriyor. Uygulama düzeyinde bir zorunlu kontrol bileşeni paylaşılır hale geldiğinde, o bileşenin çökmesi ya da ele geçirilmesi herkesi aynı anda etkileyebiliyor.
Bu yüzden runtime kararları birkaç milisaniye içinde verilirken gri alanları da kapsamak zorunda kalıyor. Bir destek ajanı müşteri verisini çekiyorsa görevini yapıyor olabilir, aynı davranış veri sızdırma anlamına da gelebilir. Bir kod ajanı depo içeriğini okurken bağlam topluyor olabilir ya da keşif yapıyor olabilir. Bir finans ajanı OAuth bağlantısı kurarken entegrasyon başlatıyor olabilir, ya da bir ihlalin ilk adımını atıyor olabilir. Yalnızca yapılan eylem kararı tek başına taşımaz; ajan kimliği, sahibi, yetkileri, normal davranışı, verinin hassasiyeti, hedef konum ve isteğin arkasındaki delege zinciri de kararı belirler.
Zincirler tabloyu daha da karmaşıklaştırıyor. Sadece son sıçramayı değerlendiren bir kontrol mekanizması, yetkili bir ajanı yetkisi dahilinde hareket ederken görür ama bu yetkinin kimsenin onaylamadığı bir zincir üzerinden geldiğini kaçırır. Runtime’da tüm zinciri değerlendirmek ise zinciri önceden bilmek anlamına geliyor. O harita olmadan anlık karar vermek, radyo üzerinden komut verebilen ama hangi uçağın nereye gittiğini göstermeyen bir kontrol kulesine benziyor.
İşleyen runtime, tek kapıdan değil çoklu görünürlükten kurulur
Bu yaklaşımın üç temel sonucu var. Önce, uygulama içi doğal kancalar, API seviyesindeki kontroller, MCP katmanı, tarayıcı ve uç nokta dahil olmak üzere ajanların bulunduğu birden fazla temas noktasına yerleşmek gerekiyor. İkinci olarak, her karar canlı bir kimlik, yetki, bağlantı ve aktivite haritasına, yani IPCA’ya, ayrıca veri hassasiyeti ve delegasyon bilgisini de ekleyen bir bağlama dayanmalı. Üçüncü olarak, yanıt seçeneği yalnızca engellemekten ibaret olmamalı.
Olgun bir uygulamada enforcement katmanı aşamalı çalışıyor. Bilinen ve güvenli davranışa izin veriyor, gerekçesi makul olan durumlarda uyarıyor, sorun verideyse bilgiyi maskeleyebiliyor ve zincir düşmanca görünüyorsa engelliyor. En yüksek riskli işlemleri insana yönlendiriyor; kanıtlanmış şekilde ele geçirilmiş bir ajan için de durdurma düğmesi tutuyor. Bu düğme ajanı askıya alıyor, verdiği izinleri geri çekiyor ve iz kaydını koruyor. Her karar tam nedensel zinciriyle birlikte kayda geçiyor, çünkü hem olay incelemesi hem de regülatör aynı beş şeyi görmek istiyor: ajan, zincir, veri, hedef ve politika.
Irregular’dan Dan Lahav bu noktada “end-state fallacy” dediği hataya işaret ediyor. Ona göre kuruluşlar, sistemin nihai dengeye ulaştığında sahip olacağı özelliklerin bugün de geçerli olduğunu varsayıyor. Runtime satın alırken bu hata, inline enforcement’ın bir gün her şeyi göreceği ve bu yüzden sıkıcı görünen alt katmanların atlanabileceği düşüncesiyle ortaya çıkıyor. Ancak bu yıl, hangi satıcıya gidilirse gidilsin, hangi fiyata bakılırsa bakılsın o nihai durum henüz ortada değil. Runtime kapsamı parçalı; platform kancaları da eşit hızda gelmiyor.
Bugün satın alınabilen şey, runtime’ın üzerinde durduğu temel katmanlar. Her görünürlük noktasında keşif, her platformda duruş bilgisi, her ajan için kimlik ve sahiplik, her karar için bağlam bunun parçası. Denetim noktaları daha sonra açıldığında, önceden neyin normal olduğunu bilen bir haritaya oturabiliyor.
İlk 90 günü aşağıdan yukarıya kuran bir sıra da buna dayanıyor. İlk iki haftada mevcut sistemler, yani kimlik sağlayıcı, ana platformlar, ağ araçları ve e-posta katmanı birbirine bağlanıyor; keşif aynı anda tüm görünürlük noktalarında çalışıyor. Gateway kurulumu da endpoint yayılımı da trafik yönlendirmesi de bu aşamada gerekmiyor. Hedef, ilk içgörünün çeyrekler sonra değil, günler içinde gelmesi ve keşfedilen popülasyonun IT’nin elindeki listeden birkaç kat büyük çıkması.
Üçüncü ila altıncı haftalar arasında keşfedilen her ajana isimli bir insan sahibi atanıyor ya da ajan askıya alınıyor. Konfigürasyon borcu ise en çok erişilebilir ajanın bulunduğu platformlardan başlanarak triage ediliyor; misafir kullanıcı maruziyetleri, ajan tetiklerine bağlı intake özellikleri ve üç yıl öncesinden kalan paylaşım kuralları ilk sıraya alınıyor. Müşteriyle temas eden ve ayrıcalıklı ajanlara da ilk guardrail’ler burada ekleniyor.
Yedinci ila on ikinci haftalarda bağlama duyarlı risk sınıflandırması devreye giriyor. Böylece inceleme, iş için gerçekten zarar verebilecek ajanla başlıyor. En üst risk grubuna en az ayrıcalık prensibiyle düzenli gözden geçirme uygulanıyor. İş ekiplerine de güvenli varsayılanlarla ajan çıkarabilecekleri onaylı bir yol sunuluyor. Builders’ın önüne yalnızca engel değil, bir rota konduğu anda uyum şansı artıyor; çünkü tamamen kapatma yaklaşımı çoğu zaman kaçınmayı öğretiyor.
Kuruluşlar kendilerini dört seviyeli bir testle de sınıflandırabiliyor. “Blind” seviyesinde, yönetim kurulunun sorduğu üç sorunun güncel yanıtı yok: Kaç ajan var, neye ulaşabiliyorlar ve kimin sorumluluğunda çalışıyorlar. “Inventoried” seviyesinde popülasyon keşfedilmiş, sayılmış ve sürekli yenileniyor. “Governed” seviyesinde her ajanın sahibi var, duruşu baz çizgiye göre yönetiliyor ve risk bağlama göre derecelendiriliyor. “Instrumented” seviyesinde ise enforcement ajanların çalıştığı yerde işliyor, kararlar aşamalı veriliyor ve her uyarıda tam nedensel yol görünür durumda oluyor.
Çoğu kuruluş, politika dokümanında ne yazarsa yazsın, ilk seviyede kalıyor. Sadece instrumented özellik satan bir ürün, blind bir yapıya enforcement koyabilir ama yargı oluşturamaz; yani aksiyon alır, fakat neye bakması gerektiğini bilemez.
Piyasadaki satıcıları ayıklamak için sorulan sorular da bu farkı netleştiriyor. SSO üzerinden hiç kimlik doğrulaması yapmayan ajanları bulabiliyor musunuz, sorusunun iyi yanıtı birden fazla bağımsız görünürlük noktasında çalışabilmek oluyor. Kritik dediğiniz bir ajan için zinciri gösterebiliyor musunuz sorusunun iyi yanıtı ise saldırı yolunun yalnızca bir skor değil, analistin doğrulayabileceği erişilebilir bir yol olması. Aynı bulgu farklı ajanlarda farklı şiddet derecesi üretebiliyor mu, bir sandbox ajanla müşteriyle temas eden ajan arasında ayrım yapılabiliyor mu, bir ajan başka bir ajanı çağırdığında delege zinciri yeniden kurulabiliyor mu, bunların hepsi mimarinin altındaki haritanın varlığına bağlı.
Bir kararın allow, block ya da redact olarak verilmesini hangi bağlam belirliyor sorusunda kimlik, yetki, delegasyon ve veri hassasiyeti cevabı öne çıkıyor. Koruma bileşeni ele geçirilirse ne olur sorusuna ise LiteLLM olayını doğrudan ele alan somut bir yanıt gerekiyor. Gerçek ajan envanteri ne kadar sürede görünür hale geliyor sorusunun yanıtı günler olmalı; çeyrek yıl, farklı bir ürün sınıfı anlamına geliyor.
Harita yerine tek tek ajanı merkeze alan platformlar bu sorulara doğrudan yanıt verebildiğini savunuyor. Reco da bunlardan biri olarak Reco Graph yapısıyla insan ve insan dışı tüm kimlikleri, uygulamaları, izinleri ve ajan eylemlerini tek bir canlı görünümde birleştirdiğini belirtiyor. Şirketin aktardığına göre reachability, yani neye ulaşabildiği, burada yapılandırmadan daha önemli analiz birimi oluyor. Bir ölçümlü programda bu yaklaşımın 21 platformda 30 gün içinde duruş skorunu yüzde 47’den yüzde 91’e çıkardığı da paylaşıldı.
Aynı şirket, Agent360 adlı ücretsiz bir değerlendirme sunduğunu da duyuruyor. Bu değerlendirme hangi ajanların ve uygulamaların aktif olduğunu, neye ulaşabildiklerini ve kimin sahip olduğunu gösteriyor. Okuma yetkili API üzerinden çalıştığı, kurulum gerektirmediği ve beş iş günü içinde yazılı bir güvenlik özeti ile öncelikli bir iyileştirme planı ürettiği aktarılıyor.