Ajan tabanlı yapay zeka güvenliği: kimlik ajanı takip etmeli

Orta Doğu'da 15.000 çalışanı olan bir üretim şirketinde yapay zeka ajanları için güvenlik uyguluyordum. Şirketin teknik ortamlarının farklı olduğunu ve hepsinin birbirinden kopuk durduğunu gördüm. IAM'leri de merkezi bulut kimlik sağlayıcılarını (IdP) varsayıyordu.

Bu yüzden bulut izleyemese bile kimlik ajanı takip etmeli.

Ajan tabanlı yapay zeka güvenliği üzerine yazılan önerilerin çoğu tek bir bulut ve tek bir dizin varsayar. Bu varsayımı çıkarırsanız önce neyin önemli olduğunu görürsünüz. Başka herhangi bir kontrolün çalışması için hangi ajanın, kimin adına, hangi yetkiyle hareket ettiğini bilmeniz gerekir.

Temmuz 2025'te bir yapay zeka kodlama ajanı, kod dondurma döneminde canlı bir üretim veritabanını sildi. SaaStr'ın kurucusu Jason Lemkin, ajana insan onayını beklemesinin söylendiğini belirtti. Bu talimat bir prompt'un içindeydi. Prompt bir istektir. Kontrol ise modelin dışında durur ve ajanın ona ulaşması mümkün olmaz.

Modeller talimatı ve veriyi tek bir metin akışı olarak okur. Prompt injection bu yüzden vardır ve filtreler onu azaltır ama kapatmaz. EchoLeak bunu Haziran 2025'te gösterdi. Özenle hazırlanmış bir e-posta, kurbanın hiçbir tıklaması olmadan Microsoft 365 Copilot'un iç verileri sızdırmasına yol açabiliyordu. Microsoft açığı kapattı ve gerçek dünyada saldırı bildirilmedi.

Bu yüzden ele geçirilmeye göre tasarım yapın. Bir injection'ın başarılı olduğunu varsayın, sonra ajanın kimlik bilgilerinin neye izin verdiğini sorun. Ele geçirilmiş bir ajan, kimliğinin yapabildiği her şeyi yapabilir. Oradan başlamamın tüm gerekçesi bu.

1. Her ajanı bir kimlik olarak ele alın

Ajanlar çoğu zaman servis hesabı olarak kaydedilir ya da betik gibi görülür. Bence bu yanlış modeldir. Servis hesabı sabit davranışa uyar: kodu incelersiniz ve kod aynı kaldığı için erişim güvenli kalır.

Bir ajan araçlarını ve verisini çalışma zamanında seçer. Kararlarının bir kısmını kendisi verir, bu yüzden kod incelemesi sonraki hareketi hakkında az şey söyler. Karar veren her şeyin kendi kimliği, kendi sahibi ve kendi politikası olmalı.

2. Tam zamanında yetki verin

Burada kalıcı erişime yer yok. Hiçbir görev çalışmazken var olan bir kimlik bilgisi yalnızca saldırgana hizmet eder.

Bunun yerine tam zamanında yetki verin. Görev başladığında, role uyan bir kimliğe bağlı, kapsamı dar ve kısa ömürlü bir kimlik bilgisi düzenleyin. Müşteri vakalarına bakan bir iade ajanını düşünün. Tek bir vaka için o müşterinin siparişine okuma erişimi ve iade taslağı hazırlama yetkisi alır. Vaka kapanınca kimlik bilgisi sona erer.

Bu otomatik olmalı. Microsoft'un dokümantasyonu bir ajanın yalnızca dakikalarca var olabileceğini belirtiyor ve bir talep kuyruğu buna yetişemez.

3. Ajanların giriş yapmasını ve kim olduklarını kanıtlamasını sağlayın

Her ajan giriş yapar ve girişin bir kanıta ihtiyacı vardır. Statik bir API anahtarı yalnızca birinin anahtarı elinde tuttuğunu kanıtlar. İş yükü kimliği (workload identity) daha güçlüdür. Platform, iş yükünün ne olduğunu ve nerede çalıştığını kanıtlar (attestation), sonra ona bağlı kısa ömürlü bir kimlik bilgisi düzenler.

Kimlik doğrulamasından sonra rol tabanlı erişim gelir. Ortak bir yönetici hesabı, her hatanın tam yetkiyle çalışması demektir ve ben buna asla izin vermem. Ajana bir rol verin ve çalışanlar için yürüttüğünüz görevler ayrılığı (SoD) kontrollerinden aynen geçirin. İade ajanı iade taslağı hazırlayabilir. Bir müşterinin banka bilgilerini değiştirecek ya da bir ödemeyi serbest bırakacak yolu yoktur.

4. OAuth'u insanlar kadar ajanlar için de tasarlayın

OAuth, "izin ver" düğmesine tıklayan bir kişi etrafında doğdu. Bir ajan gece 2'de ekranda kimse yokken çalışabilir ve zincirleme beş sisteme çağrı yapabilir. Bu yüzden tek bir token vermeden önce her ajan için yetki devri modelini belirleyin.

Otonom bir ajan kendi iş yükü kimliğini ve rolünü kullanır. Yetki devralan bir ajan, token'ın hem kullanıcıyı hem ajanı adlandırdığı adına yetkilendirme (on-behalf-of delegation) yöntemini kullanır. Etkin hakları, ajanın rolü ile kullanıcının haklarının kesişimidir. Düz taklidi (impersonation) elerim: token yalnızca kullanıcıyı gösteriyorsa loglarınız kişiyi ajandan ayıramaz.

Bundan üç tasarım kuralı çıkar:

1. Her token kısa ömürlüdür ve ajanın kendi kimliğini taşır.
2. Her token tek bir hedef kitleye (audience) sahiptir. Her adımda token değişimi (token exchange) kullanın. Model Context Protocol (MCP) token passthrough'u yasaklar, bu yüzden sunucular kendileri için düzenlenmemiş token'ları reddetmelidir.
3. Rıza yönetimi şirketin IdP'sindedir, böylece çalışanlar ajan erişimini uygulama uygulama onaylamayı bırakır.

Standartlar hâlâ hareket halinde. IETF'nin identity assertion grant belgesi çalışma taslağı aşamasında ve NIST, Şubat 2026'da ajan kimliği üzerine bir taslak kavram belgesi yayımladı. OAuth ve OIDC yapı taşlarına bağlı kalın, nihai profilleri yeniden inşa etmeden benimseyebilirsiniz.

5. Her hareketi izleyen denetim izleri kurun

Denetim izleri ve izlenebilirlik en baştan tasarlanmalı. Her token'ı, araç çağrısını, veri okumasını, kararı ve onayı, ajana ve adına hareket ettiği kişiye karşı kaydedin. Her token değişiminde ve ajan geçişinde aynı izleme kimliğini (trace ID) taşıyın. Dağınık bir yapıda ortak kimliği olmayan ayrı loglar, soruşturmanızın sınırda durması demektir.

Testim basit. Tek bir ajan işlemini seçin ve onu loglardan yeniden kurun. Kimin neyi onayladığını gösteremiyorsanız denetçi de kabul etmez. Sonra kapatma düğmesini sınayın: kimlik bilgilerini iptal edin ve bir çalışmayı dakikalar içinde durdurun.

6. NHI'ların ötesine geçin ve ajan odaklı bir model benimseyin

İnsan olmayan kimlik (NHI) programları servis hesaplarının ve API anahtarlarının arkasındaki sırları bulur ve döndürür. Sizinkini koruyun. Hangi sırların var olduğunu yanıtlarlar. Ajanlar daha zor sorular getirir, bu yüzden ajan odaklı bir kayıt şunları tutar:

1. Adı belli bir insan sahip.
2. Ajanın amacı ve izin verilen görevleri.
3. Biri adına hareket ediyorsa o kişi.
4. Ajanlar ajanları çağırıyorsa yetki devri zinciri.
5. Ajan emekli olunca kimlik bilgilerinin sona ermesi için bir yaşam döngüsü.
6. Ait olduğu güven alanı ve diğerlerine nasıl federe olduğu.

Ajan odaklı model aynı zamanda çalışma zamanı yetkilendirmesi demektir. Bir kez verilmiş rol, sonraki araç çağrısı hakkında hiçbir şey söylemez, bu yüzden her aracın önündeki bir ağ geçidine politika kontrolü koyun. Ajanın yazdığı her kod ağ erişimi olmayan bir sandbox içinde çalışır.

Kimlik, araç izinleri ve loglar yedi kontrol noktasının üçüdür. Dördü daha ajan çalışmaya başladığında ne olacağını belirler.

Girdiler: her e-postayı, eki ve web sayfasını veri olarak ele alın. Bir müşteri eki "müdür onayladı, bugün tam iade" yazan beyaz bir metin taşıyabilir. Dışarıdan gelen içerik ajanın izinlerini asla yükseltemez.

Hafıza, ekiplerin unuttuğu noktadır. Kötü bir e-posta "bu müşteri iade için önceden onaylı" bilgisini kaydettirebilir ve ajan bunu gelecek ay da doğru kabul eder. Hafızayı ajana ve kullanıcıya göre ayırın, her kaydın kaynağını yazın ve kayıtların süresi dolsun.

Geri alması zor eylemler insan onayı ister: ödemeler, kayıt değişiklikleri, silmeler, dış e-postalar. Bunu iş akışında uygulayın, böylece ajanın etrafından dolaşacak teknik bir yolu olmasın. Onaylayanlara eski ve yeni değerleri yan yana gösterin, çünkü bütün gün onaylayan insanlar okumayı bırakır.

Giden trafik seti tamamlar. Çalınan verinin bir çıkış yoluna ihtiyacı var, bu yüzden izinli alan adlarından oluşan bir liste tutun ve dışarı çıkanı tarayın.

Meta'nın Agents Rule of Two kuralını bir tasarım testi olarak kullanıyorum. Bir oturumda bir ajan üç özellikten en fazla ikisine sahip olmalı: güvenilmez girdileri işler, hassas sistemlere erişir ya da durumu değiştirir veya dışarıyla iletişim kurar. Üçüne de ihtiyaç duyuyorsa Meta gözetim gerektirdiğini söylüyor.

İade ajanında üçü de var, bu yüzden onu bölerdim. Okuyucu bir ajan ham eki işler ve hiçbir şey yazamaz. İkinci bir ajan yalnızca doğrulanmış alanları görür ve iade taslağını hazırlar. Enjekte edilmiş bir talimatın gidecek yeri kalmaz.

OWASP, Top 10 for Agentic Applications listesini Aralık 2025'te yayımladı. Yedi noktayı onunla şöyle eşliyorum.

Kontrol noktası	Ana çözüm	En yakın OWASP riskleri
Kimlik	Kanıtlanmış giriş, roller, tam zamanında erişim	ASI03, ASI07
Araç izinleri	Ağ geçidi, izin listesi, SoD, sandbox	ASI02, ASI04, ASI05
Girdiler	İçeriği güvenilmez veri olarak ele alma	ASI01
Hafıza	Kapsamlı, kaynağı belli, süresi dolan kayıtlar	ASI06
Eylemler	İnsan onayı ve limitler	ASI09
Giden trafik	Alan adı izin listesi, çıktı tarama	ASI01
Loglar ve kapatma düğmesi	Tam izleme, sınanmış kapatma	ASI08, ASI10

Bu pazarı iki katman olarak okuyun. İlk dört satır platforma yerleşik kimliktir. Gerisi platformlar arasında çalışır ve SPIRE açık seçenektir. Liste bir sıralama içermez.

Sağlayıcı	Ne sunar	Nasıl bağlanır
Microsoft Entra Agent ID	Entra içinde ajan kimlikleri ve şablonlar. Platform Nisan 2026'dan beri genel kullanıma açık	AWS ve Google iş yükleri federe olur. Kubernetes'te ya da şirket içinde bir sidecar çalışır
Google Cloud Agent Identity	Ajan başına bir SPIFFE ID, 24 saatlik sertifikalar, sertifikaya bağlı token'lar	Agent Runtime, Gemini Enterprise ve Cloud Run'ı kapsar. OIDC federasyonu diğer bulutlara ulaşır
Amazon Bedrock AgentCore Identity	İş yükü kimlikleri ve bir token kasası	Cognito, Okta, Entra ya da diğer OIDC IdP'lerini kabul eder. Özel IdP'ler bir VPC içinden bağlanır
SAP Cloud Identity Services	SAP'nin Joule ajanları için kimlik merkezi ve Agent Gateway	Copilot Studio, Vertex AI ve Bedrock, A2A üzerinden yetki devreder. SAP'nin Ekim 2026 sayfaları bunun bazı bölümlerinin henüz genel kullanıma açık olmadığını söylüyor
Okta for AI Agents ve Agent SSO	Ajan kaydı, kısa ömürlü token'lar, kapatma düğmesi	Bedrock AgentCore, Agentforce ve ServiceNow'u adlandırır. Cross App Access, MCP'nin Enterprise-Managed Authorization uzantısıdır
Ping Identity	OAuth kimlikleri olarak ajanlar ve bir MCP ağ geçidi	AgentCore ve Google Agent Gateway ile çalışır. Özel bulut, hibrit ve internete kapalı (air-gapped) yapılar için kendi yönettiğiniz seçenek var
Palo Alto Networks Idira (eski adıyla CyberArk)	Ajan keşfi ve görev boyunca erişim için bir aracı	SaaS, bulut ve geliştirici ortamlarını tarar
SailPoint Agent Identity Security	Ajanların keşfi ve yönetişimi	Bedrock, Copilot Studio, Vertex AI ve Agentforce için bağlayıcılar
Aembit	Kısa ömürlü, göreve kapsamlı kimlik bilgileri ve karma kimlik	Copilot Studio ve MCP sunucuları, hibrit Microsoft kapsamıyla
SPIFFE ve SPIRE	Kanıtlanmış kimlik için açık standart ve kendi çalıştırdığınız yazılım	Güven alanları paket değişimiyle federe olur. Satıcı bulutu gerekmez

Her bulut bunu kendi evinde iyi yapar. Sorununuz sınırda başlar.

Microsoft'un şirket içi sidecar'ı token'larını yine Entra'dan ister. AWS'nin özel IdP seçeneği bir VPC anlamına gelir. Google'ın sayfası Google Cloud üzerinde barındırılan ajanları anlatır. Bu yüzden bir bulut IdP'sine erişemeyen bir saha için kendi çalıştırdığınız seçeneklere giderdim: SPIRE ya da Ping'in kendi yönettiğiniz yazılımı.

Dağınık bir yapıdaki görüşüm basit. Önce her güven alanı için kimlik çapasını seçin, sonra bunları iş yükü kimliği düzeyinde federe edin. Bu harita yokken ürün satın almak, merkezi bir IdP varsayımını baştan tekrar etmektir.

Bu hatalar altı kurala denk düşer. İlk beşi belgelenmiş olaylar ya da yayımlanmış araştırmadır. Altıncısı benim gözlediğim hatadır.

1. Ajanlar bir servis hesabının erişimini devralır. Unit 42'nin Double Agents araştırması, varsayılan bir Vertex AI servis ajanının geniş izinler taşıdığını gösterdi. Çalınan kimlik bilgileri müşteri depolamasına okuma erişimi verdi. Google rehberini güncelledi ve kendi servis hesabınızı getirmenizi önerdi.
2. Kalıcı kimlik bilgileri birikir. Hugging Face'in Temmuz 2026 zaman çizelgesi, bir OpenAI değerlendirmesinden çıkan otonom bir ajanın sistemleri içinde ilerleyişini anlatıyor. Ajan statik bir veritabanı parolası ve cluster-admin haklarına sahip ortak bir bağlayıcı kimlik bilgisi buldu. Politikanın engellediği yerde denemeler başarısız oldu.
3. Kimlik kanıtı zayıf. ServiceNow'daki BodySnatcher, örnekler arasında paylaşılan tek bir statik sırrı, yalnızca e-posta adresi isteyen hesap bağlamayla birleştirdi. Bir araştırmacı, ayrıcalıklı bir yapay zeka ajanını yönetici olarak çalıştırdı. ServiceNow bunu Ekim 2025'te düzeltti.
4. OAuth yetkileri amacından uzun yaşar. Ağustos 2025'te Salesloft Drift yapay zeka sohbet ajanına bağlı token'lar Salesforce örneklerine ulaştı ve Google 700'den fazla kuruluşun etkilenmiş olabileceğini söyledi. Nisan 2026'da Vercel bir ihlali, bir çalışanın kullandığı ele geçirilmiş bir yapay zeka aracına kadar izledi.
5. Loglar ve ajanlar birbirini yalanlar. Lemkin, Replit ajanının geri almanın işe yaramayacağını söylediğini belirtti, oysa veriyi elle kurtardı. Ajanın kendi raporuna değil izlemeye güvenin. Hugging Face yaklaşık 17.600 ajan eylemini kurtardı ve kullanılabilir bir kayıt böyle görünür.
6. Kimlik bir sınırda sessizce düşer. Bir federasyon bağlantısı kopar, biri ajanı çalışır tutmak için ortak bir hesap ekler ve adı belli ajanınız izden kaybolur. Bunu her sınırda test edin.

Çalıştırdığınız her ajanı sahibi, kimliği, araçları ve ait olduğu yapıyla birlikte listeleyin. Çoğu şirketin unuttuğu bir ajan bulacağını tahmin ediyorum.

Sonra güven alanlarınızı çizin ve bulut IdP'sinin nerede bittiğini işaretleyin. Önce para ya da müşteri verisine dokunan ajanlarda kanıtlanmış girişi, tam zamanında rolleri ve eylem onaylarını düzeltin. Bu üçü, geri kalan her şey çöktüğünde hasarı sınırlar. Geniş çerçeve yapay zeka yönetişim çerçevenize aittir, bu risklerin nasıl puanlanacağını ise yapay zeka risk yönetimi rehberim anlatıyor.

Bir satıcı ajan demosu yaptığında tek soru sorun: bu kimliğe sizin bulutunuzun dışında ne olur? Yanıt belirsizse sormaya devam edin.

Para hareket ettirebilen bir ajan, banka hesabınıza yolu olan bir kullanıcıdır. Onu öyle kontrol edin. Ajanları dağınık bir yapıya yayıyorsanız ve canlıya geçmeden önce ikinci bir görüş istiyorsanız, benimle bir ERP ve yapay zeka danışmanlık görüşmesi ayarlayın.