Entra Agent ID GA: Sponsor Grup Tipi Kuralları Değişti

Geçen hafta bir müşterimizin kimlik mimarisi review’unda, tam ortasında ufak değil, bayağı can sıkıcı bir sürpriz yaşadık. Tahmin eder mısınız? Adam yıl başından beri Agent ID üstünde emek vermiş, blueprint’leri kurmuş, sponsor olarak da klasik role-assignable security group’ları atamıştı; public preview’da gayet yürüyen bu kurgu, Microsoft sessizce GA hazırlığı yaparken bir anda farklı kurallara takıldı ve bizim arkadaşın provisioning pipeline’ı bir sonraki cycle’da duvara toslamak üzereydi.

Mesele şu: Entra Agent ID, genel kullanıma yanı GA’ya geçerken sponsor tarafında artık sadece iki grup tipini kabul ediyor (ki bu çoğu kişinin gözünden kaçıyor). Dynamic membership group’lar. Microsoft 365 group’ları var, başka da pek kapı açmıyor; eskiden iş gören role-assignable group’lar listeden çıkmış durumda, sabit üyelikli klasik security group’lar işe zaten en baştan beri desteklenmiyor. Evet, olay bu kadar net.

Durun, bir saniye.

Şöyle söyleyeyim, Lafı dolandırmadan anlatayım; ne öldü, neden öldü ve sahada bunu nasıl yönetirsiniz, tek tek gidelim. Çünkü ilk bakışta küçük bir kısıtlama gibi dürüyor ama işin aslı öyle değil, agent yönetim modelinizi ciddi biçimde etkileyebiliyor (özellikle otomasyon tarafında sessiz sedasız kırılma yaratıyorsa insan sonradan fark ediyor).

Önce Şu “Sponsor” Olayını Bir Açalım

Hani, Agent ID hikayesine yeni girdiyseniz, “sponsor” kelimesi ilk anda biraz garip geliyor. Ben de ilk duyduğumda kısa bir duraksadım; “ne sponsoru ya, futbol kulübü mü kuruyoruz” diye düşündüm açık konuşayım.

Sponsor dediğimiz şey, bir agent kimliğinin kim tarafından sahiplenildiğini söyleyen attribution mekanizması (bizzat test ettim). Yanı aslında şu sorulara cevap veriyor: “Bu agent kimin sorumluluğunda?”, “Şu kullanıcı hangi agent’lardan mesul?”, “Agent ortada kalırsa kime gider?” Kurumsal tarafta bu iş küçük görünür. Değil; özellikle finans ya da sağlık gibi compliance yükü ağır alanlarda, burada yaşanan gecikme veya tutarsızlık audit tarafında baş ağrısı çıkarabiliyor.

Aslında, Sponsor iki şey olabiliyor: bir kullanıcı (user) ya da bir grup. Kullanıcı kısmı zaten pek olay çıkarmıyor (en azından benim deneyimim böyle). E peki, sonuç ne öldü? Asıl düğüm grup tarafında, orada iş biraz daha kıvrılıyor.

Sponsor, agent kimliğinin “kimin malı olduğunu” söyleyen attribution katmanıdır. Ne kadar hızlı ve güvenilir resolve edilirse, governance o kadar sağlam olur.

Kurallar Tam Olarak Ne Diyor?

GA tarafına geçince tablo biraz netleşti, hatta beklediğimden de netleşti diyebilirim; şu üç tip Agent ID nesnesi — agent blueprint’ler, blueprint principal’ları ve agent kimlikleri — sponsor olarak sadece iki grup tipini kabul ediyor:

• Dynamic membership groups — yanı üyeliği rule-based belirlenen, attribute’lara göre dinamik dolan gruplar
• Microsoft 365 groups — Teams/SharePoint/Outlook çevreiyle entegre, mailbox’ı olan grup tipi

Preview döneminde sponsor olarak atanabilen role-assignable groups işe GA setine girmemiş. Açık konuşayım, burada küçük bir sürpriz var; sabit üyelikli (assigned membership) klasik security grupları da işin içine alınmamış. Daha açık söyleyeyim, peki neden? Resmî tarafta sebep çok süslü anlatılmıyor ama pratikte sınır baya net.

Önemli bir detay daha var ama: Geriye dönük bir kırılım yok. Daha önce başka bir grup tipiyle atanmış mevcut sponsor ilişkileri çalışmaya devam ediyor,. Dün gece panikle sponsor değiştirme işine girişmenize gerek yok. Sadece yeni atamalarda bu kurallar devreye giriyor. Evet, durum bu kadar sade.

Hızlı bir karşılaştırma

İtiraf edeyim, Neyse, tablo zaten olayı anlatıyor. Dynamic membership. Microsoft 365 grupları rahatça ilerliyor, role-assignable tarafı işe preview’da kalmış gibi dürüyor; assigned security group için de aynı hikâye var. Sız ne dersiniz, böyle bir kısıtlama sizde kafa karıştırdı mı?

Şimdi gelelim işin can alıcı noktasına.

Kendi deneyimimden konuşuyorum, Bence asıl kritik nokta şu: mevcut yapı bozulmuyor ama yeni tasarım yaparken elinizi biraz daha dikkatli oynatmanız gerekiyor. Yanı işin aslı, eskiyi koruyup yenide daha sıkı davranmışlar.

Hani, Tam da öyle.

Microsoft Bunu Niye Yapıyor? Performans Hikâyesi

Bunu yaşayan biri olarak söyleyeyim, Açık konuşayım, ilk duyduğumda ben de biraz bozulmuştum. “Yine kısıtlama, yine geri adım” diye içimden geçirdim. Ama sonra Entra ID grup mimarisini biraz kurcalayınca, işin rengi değişti; hani bazen insanın sınırı geçiyor ya, tam öyle bir an öldü.

Sponsor sorgularının neye benzediğini bir düşünün. Bir admin “şu agent’ın sahibi kim?” diye sorduğunda cevap neredeyse anında gelmeli, yoksa sistem tökezliyor gibi hissediyorsunuz. Ters sorgu işe daha da can sıkıcı: “Şu kullanıcı hangi 200 agent’ın sponsoru?” İşte burada database tarafında özel index’ler, cache yapıları. Biraz da akıllı optimizasyon gerekiyor (aksi hâlde iş uzuyor, uzadıkça da herkes bakışıyor).

Çok konuştum, örnekle göstereyim.

Dynamic membership ve M365 grupları, Entra ID’nın underlying directory katmanında bu tip sorgular için zaten baya iyi ayarlanmış durumda. Role-assignable grupların işe başka bir resolution path’i var; RBAC değerlendirmeleri sırasında devreye giriyorlar ve sponsor lookup’ları için özellikle optimize edilmiş değiller. Yanı mesele pazarlama değil, teknik sınır; açıkçası bunu görünce “ha tamam” dedim.

Bunu Türkiye’deki şirketler açısından düşününce tablo daha da netleşiyor. Çoğu kurumsal müşteride Entra ID grup yapısı zaten epey karışık; eski AD’den hibrit gelen sabit üyelikli gruplar var, sonradan eklenmiş dynamic gruplar var, Teams açılırken otomatik oluşan M365 grupları var… Hepsi birbirine girmiş durumda. Microsoft’un bu kısıtla aslında müşterileri “agent’lara özel temiz bir grup taksonomisi kurmaya” itmesi bence kötü fikir değil — kısa vadede angarya, uzun vadede daha sade bir mimarı çıkarıyor ortaya.

Sahada Ne Değişecek? Pratik Etki

Bak şimdi, Logosoft’ta bir telekom müşterisinde, geçen ay tam bu konuyu masaya yatırdık. Adamların 60’ın üzerinde agent kimliği vardı; hepsi ayrı iş birimlerine bağlıydı, üstüne bir de sponsor tarafında iş birimine göre kurulmuş 12 tane role-assignable grup kullanıyorlardı, çünkü bu gruplar PIM akışlarında da rol alıyordu (buna dikkat edin). Kısacası yapı çalışıyordu, ama biraz da ip üstünde yürür gibiydi.

İki yol vardı. Ya bu role-assignable grupları olduğu gibi bırakıp yanına yeni dynamic gruplar açacaktık, ya da mevcut yapıyı M365 grubuna çevirmeye uğraşacaktık; ikinci seçenek kulağa temiz geliyor ama pratikte öyle değil, çünkü grup tipi değişmiyor. Yeniden kurmak gerekiyor. Peki neden bunu net söyleyebiliyoruz? Çünkü sahada insanın önüne çıkan şey teori değil, direkt kısıt oluyor (yanlış duymadınız)

Hmm, bunu nasıl anlatsamdı…

Sonunda şöyle ilerledik. Önce her iş birimi için Agent-Sponsors-{BU} formatında dynamic group’lar açtık, sonra membership rule’ları department attribute’una göre yazdık (user.department -eq "Network Ops" gibi), mevcut role-assignable grupları da PIM akışları için oldukları yerde bıraktık. Agent sponsorship’leri yeni dynamic gruplara taşıdık ve bir sonraki provisioning cycle gelmeden önce smoke test yaptık. Basit görünüyor, ama bazen en düzgün sonuç böyle yarım saatlik küçük kararlarla çıkıyor.

Toplam efor? İki günlük iş çıktı. Çok büyütülecek bir mesele değildi yanı. Ama planlamadan girseydik, işin aslı zaman zaman kafa şişiren bir karmaşa olabilirdi; hele o geçiş anında kim hangi grupta kalacak derken ekip birbirine bakıp kalırdı.

Tam da öyle. Daha fazla bilgi için Microsoft Discovery ile Ar-Ge’de Yeni Oyun: Agentic Yapılar yazımıza bakabilirsiniz.

Dynamic membership rule örneği

(user.department -eq "Engineering") -and 
(user.accountEnabled -eq true) -and 
(user.userType -eq "Member")

Bu kuralla Engineering departmanındaki aktif iç kullanıcılar otomatik olarak grubun üyesi oluyor. Birisi başka departmana geçtiğinde üyelik de kendiliğinden düşüyor; güzel tarafı bu, ama dur bir saniye — asıl rahatlatan şey sponsor attribution’ı insan eliyle takip etmek zorunda kalmamanız (en azından benim deneyimim böyle). Agent governance tarafında baya iş görüyor, hani bazen küçük görünen detaylar bütün yükü sırtlıyor ya, burada olay tam olarak o. .NET ve PostgreSQL ile Azure’da Cache’i Ciddiye Almak yazımızda bu konuya da değinmiştik. Daha fazla bilgi için langchain-azure-cosmosdb: Tek Veritabanıyla Agentic Uygulamalar yazımıza bakabilirsiniz.

Kurumsal vs Startup: Hangi Yaklaşım Size Göre?

Bak şimdi, Burada bir parantez açayım, çünkü “agent governance” deyince herkesin kafasında aynı resim oluşmuyor. Burada, peki neden? Küçük ekipte başka, holding tarafında bambaşka bir dünya var; aynı kelimeyi kullanıyoruz ama işin içi, hani, epey değişiyor.

Küçük bir ekipseniz, mesela 20-30 kişilik bir yazılım şirketiyseniz, 3-5 tane agent’ınız olur. Bunları da zaten bir-iki kişi çekip çevirir. Böyle bir tabloda sponsor olarak bireysel kullanıcı ataması yapın derim, grup işine hiç girmeyin; lead developer’ı ya da CTO’yu sponsor yaparsınız, tamamdır. Grup yönetiminin getirdiği ekstra yük var ya, açık konuşayım, sizin senaryoda pek karşılığı yok.

İlginç olan şu ki, Ama enterprise tarafındaysanız — diyelim ki bir bankadasınız ya da 1000+ kişilik bir holdingde çalışıyorsunuz — bireysel sponsor işi biraz sıkıntıya girer. İnsan ayrılır, departman değiştirir, sorumluluk dağılımı kayar; sonra bir bakmışsınız iş ortada kalmış. Burada dynamic group sponsorship gerekiyor, hatta ben her agent kategorisi için ayrı sponsor grubu kurmanızı öneririm (işin aslı bu yaklaşım daha temiz dürüyor):

• Production agent’lar için → “Agent-Sponsors-Prod” (dynamic)
• Geliştirme agent’ları için → “Agent-Sponsors-Dev” (dynamic) (bu kritik)
• Müşteri-facing agent’lar için → “Agent-Sponsors-Customer” (M365 — çünkü iletişim de gerekecek)

Migration Adımları: Pratik Rehber

Eğer şu an public preview’dan kalma role-assignable ya da assigned security group sponsor’larınız varsa, GA öncesi bu işi bir toparlamanızı öneririm (eh, fena değil). Şimdi, peki neden? Çünkü sonradan düzeltmek daha yorucu oluyor; bir de üstüne audit tarafında ufak sürprizler çıkabiliyor, yanı iş büyümeden el atmakta fayda var. Daha fazla bilgi için VSIX İçin SDK-Style Proje Desteği: Build Süresi %75 Azalıyor yazımıza bakabilirsiniz.

1. Mevcut sponsor’ları envantere alın

İlk iş, mevcut agent identity’lerin sponsor’larını ortaya dökmek (en azından benim deneyimim böyle). Microsoft Graph üzerinden bunu rahatça çekebilirsiniz; PowerShell ile de olur, Graph Explorer ile de olur (hangisi elinizin altındaysa önü kullanın). Ben olsam önce kaba bir liste çıkarır, sonra hangi agent’ın hangi grup tarafından sponsor edildiğini tek tek tabloya dizerdim. Kağıt üstünde karışık görünen şey, biraz düzenleyince hemen netleşiyor. Apple Watch’ta Token Taşıma: Entra External ID’de Yeni Dönem yazımızda bu konuya da değinmiştik.

Şimdi gelelim işin can alıcı noktasına.

2. Hedef grup tipini seçin

Şahsen, Burada karar aslında basit gibi dürüyor ama öyle her zaman değil — dürüst olayım, biraz hayal kırıklığı —. Her sponsor için “dynamic mi olsun, M365 mi” diye bakın. Eğer o grup aynı zamanda iletişim kanalı gibi davranacaksa M365 tarafı daha mantıklı geliyor; sadece attribution için duruyorsa dynamic security çoğu senaryoda baya iş görüyor (şaşırtıcı ama gerçek). Az önce basit dedim ama aslında küçük detaylar sonucu değiştiriyor, o yüzden kullanım amacını baştan netleştirin.

3. Yeni gruplar oluşturun, paralel çalıştırın

Doğrusu, Eski grubu hop diye silmeyin, orada acele etmeye gerek yok. Yeni dynamic ya da M365 grubunu açın, üyeleri doğrulayın, ardından agent sponsorship’i yeni gruba çevirin; ben burada bir hafta paralel takip yapmanızı öneririm (çünkü ilk gün her şey düzgün görünürken üçüncü günde tuhaf bir edge case patlayabiliyor). Evet, biraz temkinli yaklaşım ama açık konuşayım, çoğu göç işi böyle kurtuluyor.

4. Audit log’ları kontrol edin

Entra ID audit log’larında “agent sponsor” ile ilgili event’leri didik didik inceleyin (evet, doğru duydunuz). Sponsor resolution gecikmesi var mı, hata dönüyor mu, beklenmedik bir mapping mi oluşmuş; bunların hepsi burada kendini belli eder. Şey gibi düşünün: dışarıdan sessiz duran sistem bazen içeride minik minik takılıyor ve log’a bakmadan bunu yakalamak zor oluyor.

Bu konuda agent ekosistemini derinlemesine takip ediyorsanız, Teams Agent Kurulumu Artık Tek Komutla Tamam yazımı da okuyun — Agent ID ile beraber kullanılan deployment patterns’a değiniyorum.

Eksik Tarafı da Konuşalım: Bence Yetersiz Olan Şey

Bu değişiklik kağıt üstünde fena durmuyor. Hatta ilk bakışta mantıklı bile geliyor. Ama açık konuşayım — role-assignable group desteğinin GA’dan çıkarılması, hibrit RBAC ile agent governance kurmaya çalışan ekiplerin önüne gereksiz bir taş koyuyor; özellikle de sponsor lookup, yetki zinciri ve operasyonel kontrol aynı yerde dönüyorsa, iş iyice uzuyor.

Microsoft “ileride değerlendireceğiz” diyor. Evet, güzel cümle. Ama ben bu lafı kaç kez duydum, kaçı gerçekten geri geldi, doğrusu sayamadım. Asıl çözüm bence şuydu: role-assignable grupları desteklemeye devam et, sponsor lookup için ayrı bir caching katmanı ekle (yükü kullanıcıya değil kendi mimarine al), sonra performans nerede sıkışıyorsa orayı toparla. Ama Microsoft optimize etmek yerine kısıtlamayı seçti; anlaşılır, evet, ama içime tam sinmedi.

Yine de gözüm açık. Microsoft bu tarz GA anı kısıtlamaları — ki bu tartışılır — bazen 6-12 ay içinde gevşetiyor, hatta sessiz sedasız geri adım attığı da oluyor. “watch this space” dedikleri şey boşuna söylenmiyor olabilir. Peki neden? Çünkü bu tip kararlar çoğu zaman kalıcı tasarım tercihi değil, geçici yük azaltma hamlesi gibi dürüyor.

Eğer agent kimlik altyapısının başka tarafları da ilgini çekiyorsa, A2A v1 ile.NET’te Çapraz Platform Agent İletişimi yazısı agent-to-agent iletişiminin kimlik tarafını anlamak için iyi bir başlangıç noktası oluyor. Bir de Entra External ID Native Auth SSO: Tam Entegre Deneyim yazımda Entra’nın genel yönünü biraz daha açıyorum; bağlamı oturtmak isteyen için iş görüyor.

Sıkça Sorulan Sorular

Mevcut role-assignable group sponsor’larım çalışmaya devam edecek mi?

Evet, devam ediyor. Public preview döneminde atanmış sponsor ilişkileri GA sonrasında da sorunsuz işliyor. Kısıtlama sadece yeni atamalar için geçerli. Bence yine de uzun vadede yeni grup tiplerine geçmekte fayda var, hani ileride başka kısıtlamalar da gelebilir.

Bir security group’u dynamic membership group’a sonradan dönüştürebilir mıyım?

Hayır, maalesef doğrudan dönüştüremiyorsunuz. Üyelik tipi — yanı assigned mı dynamic mi — grup oluşturulduktan sonra değiştirilemiyor. Bunun yerine yeni bir dynamic group oluşturup üyeleri rule ile yeniden tanımlamanız gerekiyor. Biraz zahmetli, aslında baştan doğru tipi seçmek çok daha kolay.

Sponsor olarak bireysel kullanıcı atamak hâlâ mümkün mü?

Kısacası, i̇lginç olan şu ki, Evet, neredeyse tamamen mümkün. Bireysel user ataması GA’da hiç değişmedi. Küçük ekipler veya net sahiplik ilişkileri için gayet pratik. Ama tecrübeme göre sistem büyüdükçe grup bazlı yapıya geçmek kaçınılmaz oluyor.

Dynamic membership group için ekstra lisans gerekiyor mu?

Evet, dynamic membership Entra ID P1 lisansı istiyor. Açıkçası çoğu kurumsal Microsoft 365 E3/E5 paketinde bu zaten dahil, mesela büyük ihtimalle elinizde vardır. Sadece M365 Business Basic gibi alt paketlerdeyseniz lisans yükseltmesi gerekebilir. M365 group işe standart lisansla çalışıyor, orada sorun yok.

Sponsor değişikliği sonrası agent çalışmayı durur mu?

Aslında, Hayır, durmuyor. Sponsor sadece attribution. Governance katmanında bir şey — agent’ın runtime davranışını, token alma kabiliyetini veya API çağrılarını hiç etkilemiyor. Yanı gönül rahatlığıyla değiştirebilirsiniz, agent kesintisiz çalışmaya devam ediyor.

Kaynaklar ve İleri Okuma

Sponsor group type requirements for agent identities — Microsoft 365 Developer Blog

Microsoft Entra Agent ID Resmî Dokümantasyonu

Dynamic membership rules for groups in Microsoft Entra ID

Aşkın KILIÇYazar

20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.

AZ-305AZ-104AZ-500AZ-400DP-203AI-102

İlgili Yazılar

.NET ve PostgreSQL ile Azure’da Cache’i Ciddiye Almak4 May 2026

Copilot Cloud Agent Artık İmzalı Commit Atıyor: Neyi Değiştiriyor?3 Nis 2026

Veritabanı Federasyonu: Data API Builder Zincirleme ile Farklı Sistemleri Birleştirmek26 Mar 2026

Service Bus Batch İşlemede Mesaj Bazlı Settlement Devrimi29 Nis 2026