Şimdi açık konuşayım: Microsoft’un Entra tarafında her hafta bir şey değişiyor, bazen “tamam geçtim” diyorsunuz, bazen de durup iki dakika bakmanız gerekiyor. Bu yazıdaki konu, ikinci gruba giriyor. Yanı üstünden hızlıca atlanacak bir duyuru değil; özellikle Agent ID’yi production’a almış olanlar ya da tam alacak ekipler için baya doğrudan etkisi var.
Konu şu: Entra Agent ID artık genel kullanıma, yanı GA’ya geçiyor ve bu geçişle birlikte sponsor olarak atayabileceğiniz grup tipleri biraz daraltıldı. Sadece dynamic membership groups ve Microsoft 365 groups kabul ediliyor. Public preview döneminde çalışan role-assignable groups artık desteklenmiyor. Fixed-membership security group’lar da yok (inanın bana). Evet, işin can sıkıcı kısmı bu.
Hmm, bunu nasıl anlatsamdı…
Şunu fark ettim: Detaya inmeden önce, neden bu kararın bu kadar önemli olduğunu anlatayım. Sonra teknik tarafa geçeriz, ama önce şunu net söyleyeyim: böyle değişiklikler kağıt üstünde küçük görünür, sahada işe bazen bir akşamı komple yer. Hani ne farkı var diyorsunuz, değil mi? Neyse, uzatmayalım.
Sponsor kavramı neden kritik?
Agent ID tarafında “sponsor” dediğimiz şey, işin açıkçası, bir etiket falan değil; bayağı sorumluluk zinciri. Bir agent çalışıyor, bir işi hallediyor, ama dür bir saniye — arkasında kim var? Kim onay veriyor? Kim gidip erişimi tekrar bakacak? İşte sponsor bu soruların cevabı oluyor.
Geçen ay bir bankacılık müşterimizde tam bunu konuşuyorduk. Compliance ekibi gelip “şu agent neden production veritabanına okuma yapıyor, sahibi kim?” diye sorduğunda, yanıtın 2 saniyede gelmesi lazım; yoksa işler dağılıyor. 30 saniye süren bir sorgu audit toplantısında savunulmuyor, hani orada lafı gevelemeye pek alan yok. Microsoft’un bu konuda geri adım atmasının asıl nedeni de bence bu: sponsor sorguları her ölçekte hızlı dönsün diye.
Ve işler burada ilginçleşiyor.
Sponsor ilişkisi sadece bir “tag” değil; bir attribution mekanizması. “Bu agent’tan kim sorumlu?” sorusunun cevabı production sisteminde milisaniyeler içinde dönmek zorunda. Yoksa hem güvenlik ekibi hem de otomasyon zincirleri tıkanır.
Hangı grup tipleri geçerli, hangileri değil?
İşin özüne geleyim. Tablo zaten olayı baya toparlıyor, ama yine de araya biraz yorum sıkıştırayım; çünkü kağıt üstünde basit görünen şeyler, pratikte bazen ufak bir sürpriz çıkarıyor.
| Grup Tipi | Preview’da | GA Sonrası | Yorum |
|---|---|---|---|
| Dynamic membership groups | ✅ | ✅ | Önerilen |
| Microsoft 365 groups | ✅ | ✅ | Önerilen |
| Role-assignable groups | ✅ | ❌ | Şimdilik dışarıda, ileride değerlendirilecek |
| Fixed-membership security groups | ✅ | ❌ | Yeni atamalar reddedilecek |
| Bireysel kullanıcılar | ✅ | ✅ | Hiçbir değişiklik yok |
Lafı gevelemeden söyleyeyim: Microsoft burada sponsor lookup tarafını daha düzenli, daha tahmin edilebilir ve açıkçası daha az baş ağrıtan bir yapıya çekiyor. Dynamic membership gruplar ile Microsoft 365 gruplar bu iş için uygun kalıyor,. Attribute tabanlı çözümleme tarafında zaten sistem onları farklı ele alabiliyor; yanı işin motoru orada biraz başka dönüyor.
Mevcut atamalar ne olacak?
Bilmem anlatabiliyor muyum, Peki eski atamalar? İyi haber şu: önceden atanmış sponsor’lar çalışmaya devam ediyor. Evet, aynen öyle. Ama yeni bir agent identity ya da blueprint oluştururken eski tıp bir grubu sponsor olarak vermeye kalkarsanız, API bunu kabul etmeyecek; yanı mevcut düzen bozulmuyor ama yeni kurulumlarda kapı biraz daha sıkı tutuluyor.
Bunu biraz açayım.
Burası bana geçen yılki telekom projesini hatırlattı. Dinamik gruplara geçerken eski security group atamalarını tek tek elle göçürmüştük; uğraştırdı mı, evet. Ama sonra geriye dönüp bakınca iyi ki yapmışız dedim, çünkü o temizlik işi sonradan çıkan saçma sapan uyumsuzlukları baya azalttı. Neyse, çok dağıttım, konumuza dönelim.
Açık konuşayım, bu değişiklik ilk bakışta ufak görünüyor. Ama sahada işler bazen tam buradan patlıyor; siz ne dersiniz?
Türkiye’deki kurumlar için bu ne ifade ediyor?
Açık konuşayım, Türkiye tarafında gözlemim şu: Agent ID gıbı yeni servislere kurumsal müşteriler önce biraz mesafeli bakıyor. Bir kamu kurumunda ya da büyük bir bankada “agent” fikri bile daha yeni oturmuşken, üstüne bir de sponsor grup tipi geliyor; doğal olarak ekipler hemen atlamıyor. Burada, peki neden? Çünkü işin içinde hem güvenlik var hem de alışkanlıklar var, yanı kimse sabah kalkıp “hadi bunu prod’a basalım” demiyor.
Bu değişikliğin etkisi bence iki ayrı kulvarda hissedilecek, ama aynı anda değil. Erken benimseyen büyük kurumlarda,. Büyük bankalarda, sigortada, telekomda, preview’da bir şeyler deneyip blueprint kuran ekipler için geçiş planı lazım; yoksa yarın bir gün elinizde yarım kalmış yapıların listesi uzayıp gider. Yeni başlayan tarafta işe iş biraz daha rahat, çünkü KOBİ’ler, scale-up’lar ve kamu projelerinin bir kısmı zaten doğrudan GA mantığıyla ilerliyor, sıfırdan dynamic group ile başlamak onlar için daha temiz duruyor.
Bir de TL bazında bakınca tablo fena değil. Microsoft 365 grupları çoğu kurumda E3/E5 lisansının içinde geliyor, ekstra para çıkmıyor; dynamic membership grupları için işe Entra ID P1 gerekiyor. Şey, burada can alıcı nokta şu: Türkiye’deki orta ölçekli müşterilerimde P1 maliyeti tek başına can sıkıcı görünse de, bunu agent yönetimi gıbı senaryolara yaydığınızda iş görüyor. Zaten birçok kurum o lisansı başka ihtiyaçlar için almış oluyor, dolayısıyla bu kısıt çoğu zaman yeni bir yük gıbı hissettirmiyor.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Geçiş planı: nereden başlamalı?
Eğer şu an elinizde bir Agent ID kurulumu varsa ve sponsor tarafında fixed-membership ya da role-assignable grup kullanıyorsanız, ben işi şöyle bölmeyi seviyorum: önce tabloyu netleştir, sonra grupları ayır, en son da sponsor referansını çevir. Kulağa basit geliyor, ama şey, küçük bir yazım hatası bile canlı ortamda gereksiz uğraş çıkarabiliyor.
- Envanter çıkarın. Hangı agent’ın hangı sponsor’a bağlı olduğunu tek tek listeleyin. Graph API ile bunu çekebilirsiniz; elle bakmaya kalkarsanız iş uzar, hatta bir noktadan sonra gözden kaçan kayıtlar başınızı ağrıtır.
- Hedef grup tipi belirleyin. Sponsor olacak grubun mantığı statik mi, dinamik mi? Eğer “şu departmandaki herkes” gıbı attribute tabanlı bir yapıdan gidiyorsanız dynamic group daha mantıklı ölür; ama “şu proje ekibi” gıbı açık üyelik istiyorsanız M365 group daha rahat yürür. Burada tek doğru yok, kullanım senaryosu neyse ona göre karar verin. (bu kritik)
- Yeni grupları oluşturun ve test edin. Üyeliğin doğru çözüldüğünü kontrol edin. Hele bir de de dynamic kuralda ufak bir yazım hatası yapınca grup bomboş kalabiliyor; hani en sınır bozucu kısım da bu oluyor. Canlıya çıkmadan önce bunu yakalamak lazım, yoksa sonra dönüp aynı yere bakıp duruyorsunuz.
- Sponsor atamasını güncelleyin. Blueprint ya da agent identity üzerinde sponsor referansını yeni gruba çevirin. Burada adım adım gitmek iyi fikir; önce bir iki agent ile deneyin, sonra toplu geçişe geçersiniz. Ben genelde böyle yapıyorum, çünkü topluca değiştirip geri dönmek bazen gereksiz risk yaratıyor. — ciddi fark yaratıyor
- Eski grupları en az 30 gün tutun. Hemen silmeyin. Bir şey patlarsa geri dönecek bir noktanız olsun. Tam da öyle; eski yapı ortadan kalkmadan yeninin oturduğuna emin olmak daha güvenli oluyor.
Graph API ile hızlı bir kontrol
Eh, İşin teknik tarafına biraz girelim. Mevcut sponsor’larınızı listelemek için Graph üzerinden basit bir sorgu çoğu zaman yeterli oluyor, ama dür bir saniye — burada asıl mesele sadece listeyi almak değil, dönen veriyi doğru yorumlamak. Yanı sorgu kolay, hata ayıklama kısmı biraz daha meşakkatli:
Bir dakika — bununla bitmedi. Bu konuyla ilgili azd Nisan 2026: Multi-Language Hooks ve Sessiz Devrim yazımıza da göz atmanızı tavsiye ederim.
GET https://graph.microsoft.com/beta/directory/agentIdentities
?$select=id,displayName,sponsors
&$expand=sponsors
# Belirli bir agent'ın sponsor grup tipini çekmek için:
GET https://graph.microsoft.com/v1.0/groups/{group-id}
?$select=id,displayName,groupTypes,membershipRule,securityEnabledDönen yanıtta groupTypes alanında "DynamicMembership" ya da "Unified" (M365 grup için) görmeniz gerekiyor. Eğer ikisi de yoksa, o sponsor’u değiştirmeniz gerekir. Peki bunu neden söylüyorum? Basit gıbı duruyor ama bazen veri modeli sızı ters köşeye yatırıyor; o yüzden çıktıyı ezbere değil, dikkatle okuyun.
Açık konuşayım, Not düşeyim: beta endpoint’i prod otomasyonlarda kullanmaktan kaçının. Ben genelde envanter çıkarma gıbı tek seferlik işler için beta’ya başvuruyorum, kalıcı işlemler için işe v1.0‘ı tercih ediyorum. Açık konuşayım, beta bazen iş görüyor ama uzun vadede insanı yorar; o yüzden kontrollü kullanmakta fayda var (ki bu çoğu kişinin gözünden kaçıyor)
Karşıma çıkan bir tuzak: dynamic group senkron gecikmesi
AZ-500’a çalışırken bile pek gündeme gelmeyen bir detay var. Dynamic membership grupları, kural tetiklendiğinde üyeyi hemen eklemiyor; bazen 5-15 dakika arası bekletiyor,. Mantıklı değil mi? Bir kullanıcının attribute’unu değiştirdiniz diye o kişi grubun içinde anında görünmüyor.
İşte, geçen ay bir lojistik müşterisinde buna takıldık. Yeni başlayan BT yöneticisinin agent sponsor’luğu hemen aktif olsun istediler, biz de “Department” attribute’unu güncelledik ve beklemeye başladık; 12 dakika geçti, hâlâ sonuç yoktu, sonra anladık ki dynamic group processor asenkron çalışıyor ve büyük tenant’larda kuyrukta kalması gayet normal (ilk duyduğumda inanamadım) Daha fazla bilgi için Copilot Code Review Faturalandırması: Actions Dakikası Devri yazımıza bakabilirsiniz.
İşin özeti şu: Agent provisioning zamanlamanızı dynamic group’un üye çözünürlük süresine göre ayarlayın. Eğer anlık ihtiyaç varsa, M365 grup ve manuel üyelik daha güvenli duruyor; hani biraz eski usul gıbı geliyor ama açıl senaryoda baya iş görüyor. Cosmos DB Azure RBAC Entegrasyonu: İki Dünya Birleşti yazımızda bu konuya da değinmiştik.
Evet.
Senaryo: küçük ekip vs büyük kurum
Hangı grup tipini seçeceğiniz, açık konuşayım, ekibin büyüklüğüne ve agent kullanımının hızına bağlı. İki üçü da biraz kurcalayalım. Işin aslı, 5 kişiyle 5000 kişi aynı dertleri yaşamıyor, hatta bazen aynı Azure tenant’ında bambaşka iki dünya gıbı davranıyorlar.
Küçük ekip / startup
10-50 kişilik bir yazılım ekibinde, mesela 5-10 tane agent çalıştırıyorsanız, sponsor olarak DevOps Team gıbı bir M365 grup gayet yeterli oluyor. Dynamic kuralla uğraşmaya gerek yok; hani o noktada ekstra otomasyon kulağa hoş geliyor ama pratikte sadece kafa yoruyor. Lisans tarafında da E3 çoğu zaman yetiyor (en azından benim deneyimim böyle). Setup süresi? Yarım gün. Evet, bu kadar. Bu ölçekte dynamic group’un verdiği esneklik var tabii ama getirdiği karmaşıklık pek iç açıcı değil, ben olsam oraya fazla abanmazdım.
Peki neden? Çünkü küçük ekipte değişim zaten hızlı oluyor ama yönetim yükü hâlâ elle taşınabiliyor; yanı birinin adını gruba eklemek ya da çıkarmak büyük olay ölmüyor. Şey, burada otomasyonun faydası var mı? Var, ama bazen fena değil dediğimiz çözüm en doğrusu oluyor.
Enterprise seviyesi
Bir şey dikkatimi çekti: Ama 5000+ kullanıcılı bir kurumdaysanız ve onlarca agent’ı aynı anda yönetiyorsanız, iş biraz sertleşiyor. Burada department -eq "Cloud Operations" -and accountEnabled -eq true gıbı kurallarla otomatik üyelik şart hâle geliyor; çünkü her yeni işe alımda manuel ekleme yapmak hem yorucu hem de açıkçası riskli. Bir de kullanıcı işten ayrıldığında attribute güncellenince sponsor listesinden otomatik düşmesi var ya, işte compliance tarafında asıl rahatlatan şey o oluyor (özellikle denetim zamanı gelince bunu daha net anlıyorsunuz).
Neyse uzatmayalım: Büyük yapıda dinamik üyelik baya iş görüyor. Küçük yapıda işe M365 grup daha sade kalıyor. Arada kalan orta ölçekli kurumlarda ben genelde ikisini birden kullanmayı tercih ediyorum; kritik agent’lar için dynamic gidiyorum, deneysel olanları işe M365 tarafında tutuyorum. Az önce biraz kesin konuştum ama aslında tek doğru yok; ekip nasıl çalışıyorsa karar da ona göre şekilleniyor.
Eksik bulduğum noktalar
İlginç olan şu ki, Açık konuşayım, bu kararın neredeyse tamamen yerinde olduğunu söyleyemem. Role-assignable grupların geri çekilmesi bazı senaryolarda can sıkıyor; çünkü PIM (Privileged Identity Management) ile birlikte bu grupları kullanınca, agent sahipliğini “talep ederek alma” modeline çevirmek mümkündü, şimdi o kapı kapanmış gıbı duruyor, hani biraz da tatsız bir boşluk kalmış. Microsoft “ileride değerlendireceğiz” demiş, bakalım gerçekten dönerler mi, ben açıkçası temkinliyim.
Açıkçası, Bir de dokümantasyon tarafı hâlâ biraz dağınık. Public preview’dan GA’ya — en azından ben öyle düşünüyorum — geçerken “elimde X tipinde grup var, en az uğraşla Y’ye nasıl çeviririm?” sorusuna net bir migration rehberi göremedim resmî tarafta; şey, böyle küçük bir tablo bile iş görürdü aslında (bu beni çok şaşırttı). Kendi notlarımı tutuyorum, lazım olursa paylaşırım, çünkü bazen en basit adım en çok vakti yiyor.
Konunun kimlik tarafına bakanlar için Entra External ID Native Auth: SSO ile WebView Köprüsü Geldi yazımdaki SSO yaklaşımları da fena değil, bakabilirsiniz. Agent dünyasının daha geniş resmini bir düşüneyim… görmek isteyenler için işe Microsoft Agent Framework’te Chat History: Nerede yazısı iyi bir başlangıç oluyor; hatta oradan yürüyüp başka yerlere de sapılabiliyor. Teams tarafında agent kurulumu için Teams Agent Kurulumu: Prompt’tan Production’a Sade Yol rehberini de öneririm, çünkü işin aslı orada biraz daha pratik detay var.
Kısa bir aksiyon listesi
Yanı, Lafı uzatmadan, bu yazıyı okuduktan sonra yapmanız gerekenler şöyle. Evet, kısa ama iş görüyor:
- Mevcut agent identity ve blueprint’lerinizdeki sponsor referanslarını tek tek listeleyin.
- Fixed-membership security group ya da role-assignable group olanları işaretleyin; çünkü burada iş biraz karışıyor.
- Bir sonraki provisioning döngüsünden önce dynamic ya da M365 grup karşılığını oluşturun, yoksa sonra koşuşturursunuz. (bence en önemlisi)
- Geçişi staging tenant’ında test edin — production’da sürpriz olmasın, hani hiç gerek yok buna. — ciddi fark yaratıyor
- Audit log’ları kontrol edin: hangı otomasyonlar sponsor atama API’sını çağırıyor? Onları da güncellemeniz gerekecek, başka yolu yok.
Sıkça Sorulan Sorular
Mevcut role-assignable group sponsor’larım çalışmaya devam edecek mi?
Evet, devam ediyor. Hani daha önce kurduğunuz sponsor ilişkileri olduğu gıbı duruyor, müşteri tarafında bir şey yapmanıza gerek yok. Ama şunu bilin: yeni bir agent (belki yanılıyorum ama) identity ya da blueprint oluşturup aynı role-assignable grubu sponsor atamaya çalışırsanız API isteği reddediliyor. Yanı aslında eski yapı dondurulmuş gıbı — dokunmayın, çalışıyor; ama genişletmeye çalışırsanız iş değişiyor.
Dynamic membership group için ek lisans gerekiyor mu?
Evet gerekiyor. Dynamic membership özelliği Entra ID P1 lisansı istiyor — hani eskiden Azure AD Premium P1 denen şey. Eğer tenant’ınızda P1 yoksa, sponsor olarak Microsoft 365 gruplarını (Unified groups) kullanmanız gerekiyor. M365 grupları zaten E3/E5 ile geliyor, mesela bu durumda ek bir maliyet çıkmıyor.
Bireysel kullanıcıyı sponsor olarak atayabilir mıyım?
Tamamen. Hiçbir kısıtlama yok. Bu değişiklik sadece grup tipleriyle ilgili, tek kullanıcı sponsorlukta hiçbir şey değişmiyor. Açıkçası preview’da ne yapıyorsanız GA’da da birebir aynısını yapabilirsiniz — sıfır fark.
Role-assignable group desteği geri gelecek mi?
Microsoft “ileride değerlendiririz” diyor, ama net bir tarih yok. Bence müşteri talebinin yoğun olması durumunda 2026 içinde dönebilir — ama bu tamamen benim tahminim. Şu an için planlamanızı bu özelliğin geleceğine güvenerek değil, mevcut iki grup tipi üzerinden yapın. Tecrübeme göre “yakında geliyor” beklentisiyle mimarı kurarsanız sonra zor durumda kalabilirsiniz.
Geçiş sırasında downtime ölür mu?
Doğru yapılırsa hayır. Sponsor değişikliği bir update operasyonu, agent’ın çalışması durmuyor. Ama yanlış grup üyelikleriyle sponsor atarsanız “kim sorumlu?” sorgularında boş yanıt dönebiliyor — yanı aslında sessiz bir hata bu, fark etmesi zor olabiliyor. O yüzden önce yeni grubu oluşturun, üyeliklerin doğru çözüldüğünden emin olun, sonra atamayı yapın. Sırayı karıştırmayın.
Kaynaklar ve İleri Okuma
Sponsor group type requirements for agent identities — Microsoft 365 Developer Blog
Microsoft Entra ID Resmî Dokümantasyonu
Dynamic membership rules for groups in Microsoft Entra ID
Microsoft Graph — group resource type
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.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
