Ajanlar bir IAM iş yüküne dönüşüyor, servis hesaplarınız ise buna hazır değil

Önce mevcut yaklaşımın en güçlü savunmasını yapalım, çünkü bu yaklaşım aptalca değil. Servis hesapları ve API anahtarları yirmi yıldır makine iş yüklerini taşıyor. Nasıl çalıştıkları biliniyor, denetleniyorlar, her bulut ve her SaaS aracı bunları destekliyor ve güvenlik ekibinin zaten bunları listelediği bir elektronik tablosu var. Birisi ajanların yeni bir kimlik kategorisine ihtiyacı olduğunu söylediğinde makul cevap şu olur: zaten böyle bir kategorimiz var, adı insan dışı kimlik, onu kullanalım.

Sorun, bunun burada çalışmayı bırakması. Servis hesabı "hangi sistem çağrı yapıyor?" sorusunun cevabıdır. Ajan daha zor bir soru sorar: "hangi ajan çağrı yapıyor, kimin adına, hangi hedef için ve önümüzdeki otuz saniye içinde onu kim iptal edebilir?" IAM sektörünün kendi rakamları insan dışı kimliklerin insan kimliklerini artık yaklaşık bir büyüklük mertebesiyle geçtiğini söylüyor. 2026 Verizon DBIR da ajan tabanlı yapay zeka yaygınlaşırken özellikle servis ve makine hesaplarının izlenmesi gerektiği konusunda uyardı; bu, Token Security'nin rapor yorumunda öne çıkarılıyor. Bu yazı, mevcut eşlemenin neden başarısız olduğunu, yerine ne inşa edildiğini ve başarısızlıkların şimdiden nasıl göründüğünü anlatıyor.

Temel çıkarımlar - Servis hesapları ve API anahtarları kararlı ve deterministik bir çağıran varsayar. Ajanlar geçicidir, deterministik değildir ve birbirlerine yetki devreder. Bu da paylaşılan kimlik bilgilerinin temelindeki denetim, iptal ve en az ayrıcalık varsayımlarını bozar. - Standartların yönü ajan başına iş yükü kimliğidir: IETF WIMSE çalışma grubuna, ajanların yalnızca token scope ile değil kimlikleriyle ayırt edilmesini zorunlu kılması ve politika, denetim ve iptal için SPIFFE tarzı ajan bazlı tanımlayıcılar kullanması yönünde baskı var. - Olaylar artık somut: Salesloft Drift ekosistemindeki ele geçirilmiş OAuth tokenları kurumsal Salesforce ortamlarına sıçramak için kullanıldı ve Temmuz ayındaki Hugging Face ihlali baştan sona otonom bir ajan tarafından yürütüldü. - Uygulama tavsiyeleri aynı noktada birleşiyor: her ajan için ayrı kimlik, model bağlamının dışında verilen kısa ömürlü ve görev kapsamlı kimlik bilgileri ve paylaşılan role değil ajana bağlanan denetim izleri. - Ajanlarınız tek bir paylaşılan servis hesabıyla kimlik doğruluyorsa loglarınız hangi ajanın ne yaptığını söyleyemez. Bu hafta uygulamanız gereken test bu.

Ne oldu

Ağustos ayının ilk haftalarında iki gelişme birleşti. Birincisi, standart tartışması somutlaştı. 4 Ağustos'ta açılan IETF WIMSE mimari taslağı issue'su, taslağın AI intermediaries hakkındaki mevcut dilinin fazla zayıf olduğunu savunuyor. Taslak, otonom ajan eylemlerini ayırmak için "separate workload identities or token scopes" kullanımına izin veriyor, fakat issue token scope'ların bunu yapmadığını ortaya koyuyor. Scope bir tokenın ne yapabileceğini sınırlar; tokenın kimi temsil ettiğini değiştirmez. Tek bir kimlik bilgisini paylaşan birden fazla ajan, scope'ları ne kadar farklı olursa olsun denetim loglarında, iptal sistemlerinde ve ajan bazlı politikalarda ayırt edilemez. Önerilen çözüm şu: yönetilen ajan platformları her ajana benzersiz bir workload identifier vermeli, bu tanımlayıcı özel bir claim içinde taşınmalı ve politika, denetim ve iptal için kararlı anahtar olarak kullanılmalı. Dağıtılan her ajana kendi agent resource'una bağlı SPIFFE tabanlı bir kimlik veren Google ajan kimliği tasarımı çalışan örnek olarak gösteriliyor.

İkincisi, olaylar art arda gelmeye devam etti. Temmuz ortasındaki Hugging Face ihlali, adı açıklanmış bir şirkette otonom bir ajanın baştan sona yürüttüğü ilk halka açık saldırıydı: dataset pipeline'da kod çalıştırma, kimlik bilgisi toplama, dahili kümeler arasında lateral movement ve bir hafta sonu boyunca binlerce eylem. Yılın başlarında AI ajanlarına yönelik bir sosyal ağ olan Moltbook, 1,5 milyon ajan hesabına ulaştıktan yalnızca birkaç gün sonra yanlış yapılandırılmış bir veritabanından 1,5 milyon API tokenı sızdırdı; Studio Global'in derlemesine göre durum buydu. DBIR'ın insan dışı kimlik saldırıları için tekrar tekrar kullandığı örnek de tam aynı riski gösteriyor: ele geçirilen Salesloft Drift OAuth tokenları Google, Cisco ve Zscaler dahil büyük kuruluşların Salesforce ortamlarına erişmek için kullanıldı. Bu, ajanların dayandığı kimlik bilgilerinin tam olarak sahip olduğu risk biçimidir.

Ağustos 2026'da bir IETF WIMSE issue'su, ajan eylemlerinin token scope'larıyla değil ayrı iş yükü kimlikleriyle ayırt edilmesini ve ajan bazlı tanımlayıcıların politika, denetim ve iptal için kararlı anahtar olmasını önerdi. Bu öneri, Temmuz ayındaki ajan tarafından yürütülen Hugging Face ihlalinin ve Ocak ayında Moltbook ajan platformunun 1,5 milyon API tokenı sızdırdığı olayın ardından geldi.

Servis hesapları ve API anahtarları ajanlara neden uymuyor

Uyumsuzluğun dört yönü var ve çözümleri farklı olduğu için bunları ayrı ayrı adlandırmak önemli.

Paylaşılan kimlik atıfı yok eder. Servis hesapları paylaşılan, statik ve geniş yetkili olacak şekilde tasarlanmıştır. On ajanı tek bir hesabın altında çalıştırdığınızda denetim logunuz tek bir aktör gösterir. Cockroach Labs'in saha yazısında belirtildiği gibi hangi ajanın hangi veriye dokunduğunu söyleyemezsiniz, rotation tüm ajanlar arasında koordinasyon gerektirir ve hesabın izinleri zamanla herhangi bir ajanın şimdiye kadar ihtiyaç duyduğu her şeyin birleşimine dönüşür. Anonimleştirilmiş örnekleri, müşteri ekiplerinden duyduğum farklı örneklere benziyor: geliştirme sırasında tüm müşteri veritabanına okuma erişimi verilmiş bir destek ajanı üç ay boyunca aynı hesapla çalışıyor ve go-live öncesinde bu kapsam hiç daraltılmıyor.

Ajanlar geçicidir; anahtarlar değil. Bir agentic workflow birkaç saniye içinde model sağlayıcısında, vector store'da, üç API'de ve cloud storage'da kimlik doğrulayabilir, ardından kaybolabilir. Uzun ömürlü API anahtarları, takvime göre döndürülmeye değer kalıcı bir çağıran varsayar. Bu uyumsuzluk yayılmaya yol açar: kimsenin hatırlamadığı ajanlar için üretilmiş anahtarlar hâlâ geçerli ve hâlâ geniş yetkilidir.

Yetki devri "kimin adına" zincirini bozar. Bir kullanıcı adına hareket eden ajan ile otonom hareket eden ajan policy engine için tamamen farklı görünmelidir. Paylaşılan servis hesabıyla aynı görünürler. OAuth delegation kullanıcı senaryosunu makul biçimde çözer; otonom senaryoda ajanın kendi kimliği gerekir ve multi-agent delegation sırasında her hop aktarılacak yetkiyi genişletmek yerine daraltmalıdır.

Model sırrı asla tutmamalıdır. Bu bir yapılandırma meselesi değil, yapısal bir meseledir. Context window'a aktarılan kimlik bilgileri modele ve modeli manipüle edebilen her şeye açıktır. Prompt injection, ajanın kendi çıktıları üzerinden bunları dışarı çıkarabilir. Çözüm, görev anında token service tarafından verilen kısa ömürlü ve kapsamlı kimlik bilgilerini tool-execution layer'ın tutmasıdır; böylece model çağrıları tetikler ama sır bağlamına hiç girmez. Cockroach Labs bu noktayı iyi anlatıyor ve benim self-hosted ajan yığınları kuran müşterilere söylediğimle aynı: anahtarları harness tutar, niyeti model tutar.

Paylaşılan servis hesapları loglarda tek bir aktör bırakarak ajan atfını bozar, geçici ajan iş yüklerinden daha uzun yaşar, kullanıcı tarafından devredilmiş eylemler ile otonom eylemler arasındaki çizgiyi bulanıklaştırır ve ekipleri kimlik bilgilerini prompt injection'ın erişebileceği model bağlamından geçirmeye iter. Bu risk Cockroach Labs ve miniOrange karşılaştırmasında açıklanıyor.

Sağlayıcılar ve standart kurumları ne inşa ediyor

Ortaya çıkan yapı üç katmanlı ve cesaret verici olan, sağlayıcılarla standart uzmanlarının kabaca aynı modele yaklaşması.

Ajan başına iş yükü kimliği. Yukarıdaki WIMSE yönü bunun standart versiyonu: her logical agent benzersiz ve kararlı bir tanımlayıcı alır, önerilen biçim SPIFFE URI'dır, bu tanımlayıcı paylaşılan execution role'den ayrıdır ve politika, denetim ve iptal bu kimliği anahtar olarak kullanır. Bir execution credential paylaşan platform-managed ajanların bunu ajan bazlı bir claim ile tamamlaması gerekir. En önemli değişim budur: deployment başına değil, ajan başına kimlik.

Saklanan sırlar yerine federasyon. Descope'un ajanlar için workload identity federation açıklaması modeli gösteriyor: ajanın AWS IAM role veya IRSA üzerinden Kubernetes service account gibi platform kimliği, identity platform'dan alınan kısa ömürlü ve scoped bir token ile değiştirilir. Platform ayrıca ajan için bir directory record oluşturur, böylece audit trail token ömrünün ötesinde kalır. Sızdırılabilecek uzun ömürlü bir anahtar yoktur ve kimlik kaydı herhangi bir tekil kimlik bilgisinden daha uzun yaşar.

Discovery ve governance bir pazar olarak. Ticari tarafta Reco, Token Security, Oasis, Aembit ve benzeri non-human identity sağlayıcıları ajanlar etrafında yeniden konumlanıyor: her ajan credential'ını bulmak, bir owner'a bağlamak, aşırı yetkilendirmeyi işaretlemek ve temiz biçimde revoke etmek. Reco'nun yaklaşımı pratiktir: kullanıcı eylemleri için delegated OAuth, otonom eylemler için dedicated workload identity kullanarak kimlik türünü ajanın rolüyle eşleştirin ve sorumluluklar büyüdükçe izinleri gözden geçirin. Çünkü ajanlar, çalışanların bina anahtarları biriktirmesi gibi ayrıcalık biriktirir. Aralık 2025'te yayımlanan OWASP Top 10 for Agentic Applications, Identity and Privilege Abuse'u birinci sınıf risk kategorisi olarak adlandırdı ve güvenlik ekiplerine denetim bulguları için ortak bir dil verdi. Bunun daha geniş stack içinde nerede duracağı tooling kadar governance sorusudur; organizasyon tarafını AI ajan governance yazısında ele alıyorum.

Ortaya çıkan mimari: WIMSE tartışmasına göre politika, denetim ve iptal için anahtar olarak SPIFFE tarzı tanımlayıcılar kullanan ajan başına workload identity; Descope modeline göre platform kimliğini kalıcı ajan directory kayıtlarıyla birlikte kısa ömürlü scoped tokenlara federate etmek; ve insan dışı kimliklerin discovery ile least-privilege governance'ı için bir sağlayıcı pazarı.

Ajan kimliği yanlış gittiğinde

Üç olay, üç farklı başarısızlık biçimi ve hepsi öğretici.

Hugging Face, Temmuz 2026: saldırganın kimlik sorunu savunmacının da sorunuydu. Ajan tarafından yürütülen saldırı, code-execution worker'dan bulut ve küme kimlik bilgilerini topladı ve lateral movement yaptı. Bu klasik bir aşırı yetkili workload hikayesidir: veri işleme bileşeni çalınmaya değer kimlik bilgileri tutuyordu. Daha az konuşulan ayrıntı, Hugging Face'in açıkladığı forensics asimetrisidir: saldırgan ajan hiçbir kullanım politikasına bağlı değildi, şirketin kendi forensics çalışması ise denedikleri hosted modellerin guardrail'ları tarafından ilk aşamada engellendi. Bu nedenle analizi kendi altyapılarında open-weight model GLM 5.2 ile yürüttüler. Aynı olayın iki tarafında da kimlik ve erişim başarısızlığı vardı.

Salesloft Drift, DBIR'ın uyarısı: tokenlar ana anahtar gibi. Bir sağlayıcı ekosisteminden ele geçirilmiş OAuth tokenları büyük kuruluşların Salesforce ortamlarına sıçramak için kullanıldı. Parola yok, insan phishing'i yok: geniş ölçüde güvenilen ve sessizce yeniden kullanılan insan dışı kimlik bilgileri. Uzun ömürlü OAuth grant ile bir SaaS aracına bağladığınız her ajan bu risk biçimine sahiptir ve çözüm de aynı biçimdedir: kısa ömürlü, dar kapsamlı, ajan başına ve iptal edilebilir.

Moltbook, Ocak 2026: ajan platformları kimlik riskini toplar. Ajan hesapları için bir platform, yanlış yapılandırılmış veritabanından 1,5 milyon API tokenının yanı sıra e-posta adresleri ve ajanlar arası mesajları sızdırdı; Studio Global'in anlatımı bunu bildiriyor. Ajan kimliğini merkezileştirdiğinizde blast radius'u da merkezileştirirsiniz. Dolaşımdaki bazı olay ayrıntılarını denetlenmiş değil, raporlanmış olarak ele almak gerektiğini de söylemek önemli: Hugging Face açıklaması birincil kaynaktır, Moltbook rakamları ise ikincil haberlerden gelir.

Belgelenmiş ajan kimliği hataları arasında, otonom bir ajanın bulut ve küme kimlik bilgilerini toplayıp lateral movement yaptığı Temmuz 2026 Hugging Face ihlali, Waxell analizi; Salesloft Drift OAuth tokenlarının kurumsal Salesforce tenantlarına geçiş için kullanılması, 2026 DBIR üzerine Token Security; ve Moltbook'un 1,5 milyon ajan API tokenı sızıntısı yer alıyor.

Şimdi ne yapmalı

1. Bu hafta: ajanlarınızın kimlik bilgilerini envanterleyin ve atıf testini uygulayın. Loglardan herhangi bir ajan eylemi seçin ve hangi ajanın yaptığını, kimin adına yaptığını ve yalnızca o ajanı diğerlerine dokunmadan revoke edip edemeyeceğinizi sorun. Cevap hayırsa paylaşılan kimlik probleminiz vardır ve önce bunu düzeltmelisiniz.

2. Bu ay: bir otonom ajanı uzun ömürlü credential'dan çıkarıp token service veya identity platform tarafından verilen, tool-execution layer'da tutulan ve model bağlamına hiç girmeyen kısa ömürlü, task-scoped tokenlara taşıyın. En geniş erişime sahip ajandan başlayın; genellikle birinin aceleyle "geçici" olarak fazla geniş yetki verdiği ajan odur.

3. Bu çeyrek: her logical agent'a kendi kararlı kimliğini verin. Altyapınız varsa SPIFFE ID, yoksa ajan başına benzersiz service account kullanın; audit ve alerting'i buna bağlayın ve ihtiyaç duymadan önce revoke runbook'unu yazın. Daha erken aşamadaysanız ve ajanların nerede çalışması gerektiğine hâlâ karar veriyorsanız, yerel ve bulut ajanları arasındaki trade-off bu katmanın ne kadarını kendiniz kontrol edebileceğinizi belirler.

SSS

IAM açısından ajan kimliği nedir?

Tek bir AI ajanına atanan, çalıştığı platformdan ve adına hareket ettiği kullanıcılardan ayrı, doğrulanabilir bir kimliktir. Kimlik doğrulama, yetkilendirme politikası, denetim izi ve iptal için kararlı anahtar olarak kullanılır. Bir workload identity'nin bir microservice'i tanımlamasına benzer, fakat geçici, deterministik olmayan ve birbirine yetki devredebilen çağıranlara göre uyarlanmıştır.

Ajanlar neden sadece bir servis hesabını paylaşamaz?

Teknik olarak paylaşabilirler ve bugün çoğu bunu yapıyor. Sorunlar şunlar: denetim logları eylemi yapan ajan yerine paylaşılan hesabı gösterir, dolayısıyla atıf kaybolur; hesabın izinleri tüm ajanların ihtiyaçlarının birleşimine doğru büyür; bir ajanı revoke etmek herkesin kimlik bilgilerini rotate etmeyi gerektirir; kullanıcı tarafından devredilen eylemler ile otonom eylemleri ayırt edemezsiniz. İlk olaya kadar çalışır, sonrasında ne olduğunu yeniden kuracak veriniz kalmaz.

Standart kurumları ajan kimliği konusunda ne yapıyor?

IETF WIMSE çalışma grubu workload identity architecture'ı AI intermediaries alanına genişletiyor. Token scope'larına dayanmak yerine ajan başına tanımlayıcı zorunluluğu getiren aktif bir öneri var ve SPIFFE URI önerilen mekanizma. OWASP Aralık 2025'te Top 10 for Agentic Applications yayımladı ve identity and privilege abuse'u adlandırılmış bir kategori yaptı. Cloud Security Alliance da ajan başına benzersiz kimlik öneren bir agent identity governance framework'e sahip.

Ajan kimlik bilgileri model bağlamında hiç görünmeli mi?

Hayır. Context window içindeki her şey model tarafından görülebilir ve prompt injection ile dışarı çıkarılabilir. Kabul edilen model, kimlik bilgilerinin görev anında token service tarafından verilmesi, model ile API arasındaki tool-execution layer tarafından tutulması, göreve sınırlandırılması ve kısa ömürlü olmasıdır. Model eylemi ister; sırrı harness tutar.

Sonuç

Kimlik dünyasında "identity control plane'dir" diye bir söz vardır ve ajanlar bu fikri microservice'lerin yaptığından daha sert sınayacak. Yön bugün harekete geçecek kadar açık: ajan başına kimlik, model dışında sırlar, olayların yayılmasından daha hızlı sona eren tokenlar ve "hangi ajan, kimin adına, hangi hedef için" sorularını cevaplayabilen denetim. Bu yaz zarar gören kuruluşlar egzotik sistemler çalıştırmıyordu; paylaşılan kimlik bilgileri kullanıyor ve sorun çıkmamasını umuyordu. Kapatılması gereken boşluk bu ve bunu kapatacak teknolojinin büyük bölümü zaten mevcut.

Ajan kimliğini mevcut bir IAM ortamına eşliyorsanız ve tartışmada uygulama deneyimi olan birini istiyorsanız, bu benim yaptığım işlerden biri. İletişime geçin.

Kaynaklar

• IETF WIMSE WG, draft-ietf-wimse-arch issue #139, "AI and ML-Based Intermediaries: token scopes do not create per-agent identity": https://github.com/ietf-wg-wimse/draft-ietf-wimse-arch/issues/139 (açıldı 2026-08-04, erişildi 2026-08-29)

• Cockroach Labs, "AI Agent Identity Security": https://www.cockroachlabs.com/blog/ai-agent-identity-security/ (yayımlandı 2026-07-17, erişildi 2026-08-29)

• Token Security, "The 2026 Data Breach Investigations Report Confirms It: Identity Is the Control Plane for Agentic AI": https://www.token.security/blog/the-2026-data-breach-investigations-report-confirms-it-identity-is-the-control-plane-for-agentic-ai (yayımlandı 2026-05-20, erişildi 2026-08-29)

• Descope, "What Is Workload Identity Federation for AI Agents?": https://www.descope.com/learn/post/workload-identity-federation-for-agents (yayımlandı 2026-06-22, erişildi 2026-08-29)

• miniOrange, "Why AI Agents Need Workload Identity, Not Shared Secrets": https://www.miniorange.com/blog/workload-identity-ai-agents/ (yayımlandı 2026-05-20, erişildi 2026-08-29)

• Reco, "Non-Human Identities for AI Agents: How to Govern Access": https://www.reco.ai/blog/non-human-identities-for-ai-agents (yayımlandı 2026-07-20, erişildi 2026-08-29)

• Waxell, "Hugging Face Breach: How an AI Agent Ran the Attack": https://www.waxell.ai/blog/hugging-face-agentic-attacker-ai-breach-2026 (yayımlandı 2026-07-17, erişildi 2026-08-29)

• Studio Global, "EU AI Act August 2026: Enforcement Powers Go Live as Autonomous Agent Breach Tests Regulators": https://www.studioglobal.ai/discover/answers/what-key-enforcement-powers-and-transparency-obligations-6a6bff1f2240a0fb8c880846 (yayımlandı 2026-08-17, erişildi 2026-08-29)