Kurumsal sistemlerde yetki devralarak çalışan AI ajanları için kimlik ve erişim yönetimi, klasik kullanıcı hesaplarına göre yeniden kurgulanıyor. Yapılan son değerlendirmeler, bu ajanların yalnızca giriş yapıp araç çağırmadığını; CRM, biletleme, bulut altyapısı ve veri kaynakları arasında işlem zincirleri kurduğunu, bu yüzden de standart IAM mekanizmalarının tek başına yeterli olmadığını ortaya koyuyor.
En büyük boşluk, kimlik sistemlerinin “erişim tanımı” ile uygulama ve altyapının “gerçekte ne yapıldığı” arasında kalması. Bu aralıkta uygulama içinde açılan yerel hesaplar, gömülü kimlik bilgileri, API anahtarları ve kimlik sağlayıcısına hiç düşmeyen ajanlar bulunuyor. Analize göre merkezi IAM kayıtları bu katmanı göremediğinde, kurumların elinde politika niyeti kalıyor; davranışa dönük güvence oluşmuyor.
Statik roller ajan davranışını sınırlamıyor
Geleneksel IAM süreçleri çoğunlukla iki eksende çalışıyor: tasarım aşamasında yaşam döngüsü yönetimi, politika tanımı ve hesap açma-kapama akışları; çalışma anında ise SSO ve çevresel erişim kontrolleri. Bu model, insan kullanıcıların öngörülebilir görev akışına göre tasarlandı. Oysa bir AI ajanı, görevleri zincirleyebiliyor, araçları dinamik seçebiliyor ve yetki incelemesinde hiç düşünülmemiş işlemler üretebiliyor.
OWASP Top 10 for Large Language Model Applications içinde bu durum “excessive agency” olarak, LLM06 koduyla tanımlanıyor. Geniş işlev, geniş yetki ya da geniş özerklik verilen bir ajan, onaylanan görev sınırını aşabiliyor. Sabit rol ataması bunu çevrelemiyor; çünkü risk, yalnızca yapılandırmadaki izinden değil, ajan kimliğine gerçekten hangi izinlerin bağlandığından, çalışma anında hangi sistemlere eriştiğinden ve görev zincirini hangi koşullarda yürüttüğünden doğuyor.
İnceleme, yanlış yapılandırma ile fiili sömürü arasında da fark bulunduğunu vurguluyor. Bir ayar hatası tek başına istismar anlamına gelmiyor; etkinin seviyesi, ajan kimliğine atanmış izinlere ve o kimliğin yürüdüğü ortamın koşullarına bağlı değişiyor. Bu nedenle yapılandırma çıktıları yalnızca olasılığı, telemetri ise gerçekleşeni gösteriyor.
Kimlik bilgisi, sahiplik ve denetim eksikliği
Ajan kimlikleri çoğu zaman insan kaynakları süreçleriyle değil, altyapı otomasyonu, dağıtım boru hatları veya uygulama ekipleri tarafından oluşturuluyor. Bu da onları insan erişimindeki anormallikleri yakalayan yönetişim akışlarının dışına itiyor. Uyumluluk raporlarının dayandığı envanterlerde görünmeyen bu hesaplar, uzun süre fark edilmeden kalabiliyor.
Kaynak analizde tekrar eden beş hata sınıfı öne çıkıyor. İlki, atanmış bir insan sahibin olmaması. İkincisi, statik API anahtarları ve token’ların ajan emekliye ayrıldıktan sonra bile dönmemesi. Üçüncüsü, ajanlara görevle sınırlı yetki yerine kullanıcının ya da servis hesabının tüm izinlerinin topluca verilmesi. Dördüncüsü, başka iş yükleri tarafından başlatılan ajanların kimlik sağlayıcıya veya yönetişim sistemine hiç kaydolmaması. Beşincisi ise pilot çalışma için açılan erişimin pilot bittikten sonra da açık kalması.
Her ortamda beşinin birden görülmediği belirtiliyor, ancak her biri ayrı bir kontrol katmanına işaret ediyor. Kimlik çerçevesi tam da bu nedenle yaşam döngüsü, yetkilendirme ve çalışma anı denetimini birlikte ele almak zorunda.
AI ajanı için ayrı bir kimlik, ayrı bir doğrulama ve kısa ömürlü kimlik bilgileri öneriliyor. Ortak servis hesapları ya da ödünç alınmış insan oturumları yerine iş yükü kimliği federasyonu ve otomatik dönen geçici krediler tercih edilmeli deniyor. Bir ajan kullanıcı adına işlem yapıyorsa, OAuth 2.0 Token Exchange (RFC 8693) devreye giriyor. Bu yöntem, ajan kimliği ile ona ödünç verilen yetkiyi birbirinden ayıran delege etme ve vekâlet semantiği sağlıyor. Ajan bir kullanıcının oturum belirtecini doğrudan yeniden kullanırsa, bu ayrım ortadan kalkıyor.
Yetkilendirme tarafında NIST SP 800-53 Rev. 5 içindeki AC ailesi aynen uygulanıyor: en az ayrıcalık ilkesi AC-6, görevler ayrılığı AC-5 ve açık yetki sınırları. Ancak denetim noktasının bir giriş kapısında değil, eyleme daha yakın bir yerde konumlanması gerekiyor. Göreve özel yetki, araç allowlist’i, veri sınırları ve yüksek etkili işlemler için insan onayı ya da ikinci bir yetki yolu bu çerçevede öne çıkan kontroller arasında yer alıyor.
Özellikle veri sınırları kritik görülüyor. Ajanlar manipüle edilmiş verileri temel alarak karar verdiğinde, o veriye sadık biçimde hareket ediyorlar. Yani yanlış veri kaynağı, yanlış eylem zinciri anlamına gelebiliyor.
Çalışma anı görünürlüğü olmadan hiçbir tasarım kontrolünün savunulabilir olmadığı da raporda yer alıyor. NIST AI Risk Management Framework (AI 100-1), hesap verebilirlik ve şeffaflığı güvenilirlik özellikleri arasında sayıyor; SP 800-53’ün AU ailesi ise bir politika bulunduğunu değil, eylem dizisini yeniden kurmaya yetecek kayıtların tutulduğunu varsayıyor.
MITRE ATT&CK’teki valid-accounts abuse olarak bilinen T1078 tekniği ve ayrıcalık yükseltme yöntemleri gibi kimlik saldırıları, geçerli kimlik bilgileri kullanıldığı için çoğu zaman normal giriş kayıtları üretiyor. Bu nedenle ajan takibi yalnızca log toplamakla değil, ajanın hedeflenen görevini gerçek yürütmesiyle karşılaştırmakla mümkün oluyor. Fark ortaya çıktığında, devredilen yetkinin geri alınabilmesi de çerçevenin bir parçası sayılıyor.
Kurumsal seçimde öne çıkan ölçütler
Değerlendirme sırasında en çok atlanan iki başlık revocation hızı ve kanıt kalitesi olarak sıralanıyor. Sağlayıcıların hesap açma-kapama ve provizyon özellikleri kolay gösterildiği için ölçüt listelerinde çoğu zaman bu iki alan geri planda kalıyor. Oysa ajan IAM’i için uygun çerçeve seçimi, bağlantı sayısına bakmaktan çok, sahiplikten yürütme kanıtına uzanan tüm kontrol zincirini ne kadar kapsadığıyla belirleniyor.
İnceleme, karar verirken altı sorunun özellikle sorulmasını öneriyor: Her ajan kimliği, amacı ve süresi için adı belirtilmiş bir insan sahibine bağlanabiliyor mu; mimari federasyon destekli kısa ömürlü kimlik bilgileri sunuyor mu; ajan kendi kimliğini kullanıcı yetkisinden ayrı koruyabiliyor mu; keşif yalnızca IdP ve IAM platformunun bildiklerine mi dayanıyor, yoksa uygulama ve altyapıdan da ajan kimliği çıkarılabiliyor mu; telemetri yalnızca giriş olaylarını mı, araç çağırma ve veri erişimini de mi görüyor; yetki, otonom görev zinciri tamamlanmadan önce eylem noktasında sınırlandırılıp geri alınabiliyor mu; sistem politika tanımı değil, telemetri destekli davranış kanıtı üretiyor mu?
Yapı, al ya da genişlet yaklaşımı da kurumun mevcut olgunluğuna göre değişiyor. Kimlik yönetişimi zaten çalışan kurumlarda, var olan IAM platformunu genişletmek en doğal başlangıç olarak görülüyor. Yaşam döngüsü iş akışları, onay zincirleri, sertifikasyon döngüleri ve politika yönetişimi zaten kuruluysa, ajanlar için bunları sıfırdan yazmak yönetişimi daha da parçalı hale getirebilir. SailPoint ve Saviynt gibi yönetişim platformlarının tasarım anı katmanına hitap eden non-human ve agent identity yetenekleri bulunduğu belirtiliyor; ancak özellikler sürümden sürüme değiştiği için güncel dokümantasyonla doğrulama gerektiği de not ediliyor.
Özel ajan çerçeveleri kullanılan ve yetkilendirmenin çalışma zamanının içine gömülmesi gereken yerlerde geliştirme seçeneği öne çıkıyor. Satın alma ise yönetişim platformlarının çoğunun doğal olarak sağlamadığı iki katmanda anlam kazanıyor: ajan kimliklerini doğrudan uygulama ve altyapıdan keşfetmek ve yürütmenin niyetle uyup uymadığını doğrulamak. Birçok kurumda üç yaklaşım birlikte kullanılıyor: yaşam döngüsü için genişletme, uygulama içi uygulama için geliştirme, görünürlük için satın alma.
Bu modelin pratikte nasıl çalıştığına dair örneklerden biri, destek taleplerini CRM, biletleme sistemi ve kurum içi bilgi tabanı arasında çözen bir operasyon ajanı. Kimlik sağlayıcı tarafında günde birkaç başarılı giriş görülmesi olağan sayılabiliyor. Ancak uygulama katmanında aynı ajanın müşteri kayıtlarını sorguladığı, veri dışa aktardığı ve yetki bilgilerini güncellediği görülüyor. Sadece IdP’ye bakan bir yapı bu ajanı iyi yönetilen bir varlık gibi gösterebilirken, gerçek erişimi ancak uygulama telemetrisi ortaya çıkarıyor.
Satın alma süreçlerini yöneten bir ajan da aynı ayrımı netleştiriyor. Onaylı görevi tedarikçi fiyatlarını çekmek olabilir, fakat verilen izinler tüm satın alma API yüzeyini kapsıyorsa, görev zinciri sipariş başlatmaya kadar ilerleyebiliyor. Bu durumda niyet, yetki ve yürütme birbirinden ayrılıyor; fiilen ne olduğu ancak üçüncü kayıtla anlaşılıyor.
Kontrol düzeyi kimliği olan bir kod teslim ajanında risk daha da yükseliyor. Altyapı otomasyon kimlikleri geniş yetkiler taşıdığı için yüksek değerli hedefler haline geliyor ve ele geçirilirse, saldırganlar ortamı ve tespit kontrollerini de yeniden şekillendirebiliyor.
Olgunluk modeli de üç aşamada tarif ediliyor. İlk aşama statik hesap ve rol yönetişimi; ajanlar insan dışı kimlikler olarak envantere giriyor, sahip, amaç ve süre atanıyor, erişim periyodik olarak gözden geçiriliyor. Bu, pilotlar için yeterli görülebilir ama otonom eylem için zayıf kalıyor. İkinci aşamada olay tetiklemeli otomasyon devreye giriyor; provizyon, kimlik bilgisi döndürme ve iptal işlemleri inceleme takvimine değil, dağıtım ve emeklilik olaylarına bağlanıyor. Üçüncü aşamada ise sürekli kimlik gözlemi geliyor: ajan davranışı uygulamalar ve altyapı genelinde izleniyor, yürütme niyetli görev kapsamıyla karşılaştırılıyor ve denetim kanıtı telemetri üzerinden üretiliyor.
Bu üçüncü aşamada Orchid Security’nin konumlandığı aktarılıyor. Şirketin uygulama ve altyapıdan doğrudan kimlik keşfi yaptığı, parçalı kimlik sistemlerinin raporlamadığı ajan kimliklerini, kimlik bilgilerini ve erişim yollarını ortaya çıkardığı belirtiliyor. Kurumun mevcut IAM platformlarını tamamlamak üzere tasarlandığı, yönetişim ve provizyonu olduğu yerde bıraktığı, buna karşılık yapılandırılmış politikayı telemetriye dayalı denetim kanıtına çevirmeyi amaçlayan bir doğrulama ve düzeltme katmanı eklediği ifade ediliyor. Kapsamın ise bağlı uygulama ve altyapıya göre değiştiği not düşülüyor.
İleriye dönük bölümde, ajanlar birbirini yetkilendirmeye başladıkça görünürlüğün kolaylaşmayacağı vurgulanıyor. Bir ajan başka bir ajana alt görev devrettiğinde, yetki insan onayından geçmeyen bir zincir üzerinden ilerliyor. Buna yanıt olarak makine tarafından okunabilir politikalar ve çalışma anında uygulanabilen yetkilendirme biçimleri geliştirilirken, doğrulanabilir ajan kimlikleri ve sınırlı delege etme standartları üzerinde de çalışma sürüyor. Ancak bu girişimler erken aşamada ve farklı ajan çerçeveleri arasında birlikte çalışabilirlik henüz netleşmiş değil.
MITRE ATLAS da saldırgan taktik ve tekniklerini AI destekli sistemler açısından katalogluyor ve böyle kimlik zincirlerinin nasıl hedef alınabileceğine dair referans çerçevesi sunuyor. Buna karşın raporda çizilen temel çizgi değişmiyor: Zincirdeki her bağlantının bir kimliği, bir kapsamı, bir süresi ve sonunda sorumlu bir insanı olmalı. Sürekli yetkilendirme yaklaşımı, tek giriş kararını ajanın davranışı, veri kaynakları ve çalışma bağlamı değiştikçe yeniden puanlayarak dinamik hale getiriyor; ancak bu da yalnızca davranışsal sinyal varsa çalışıyor.
Analizin sonunda, provizyonu yöneten ama yürütmeyi görmeyen bir AI ajanı kimlik çerçevesinin politika niyeti ürettiği, operasyonel güvence sağlamadığı vurgulanıyor. Ajanlar zaten işlem yapıyor; kurumların yanıtlaması gereken soru, ortamın bu işlemleri kanıtlayıp kanıtlayamadığı olarak bırakılıyor.