Geçen ay bir bankacılık müşterimizde yine aynı mevzuya takıldık (bizzat test ettim). Müşteri destek ekibine bir AI agent kuracağız, doğal dilden komut alacak, portföy bilgisini dönecek, falan filan. Demo da fena değildi, hatta baya akıyordu. Sonra güvenlik tarafındaki arkadaş tek bir soru patlattı: “Peki bir müşteri başka bir müşterinin verisini istese, agent ne yapacak?”
Sessizlik.
İşte tam orada Microsoft ile Curity’nın yeni yayınladığı azd template devreye giriyor. Açık konuşayım, ben bu şablonu görene kadar pek çok agent örneğinde aynı boşluğu gördüm: authentication kısmı tamam gıbı duruyor. Authorization tarafı havada kalıyor. Bu yazıda hem şablonun ne yaptığını hem de Türkiye’deki kurumsal projelerde neden iş gördüğünü anlatacağım.
Önce şu authentication-authorization karmaşasını netleştirelim
Saha bana şunu öğretti: geliştiricilerin ciddi bir kısmı bu iki kavramı birbirine karıştırıyor. Kullanıcının kim olduğunu bilmek başka şey, o kullanıcının hangı veriyi görebileceğini söylemek bambaşka şey. Bunlar yan yana dursa da aynı katman değil.
Geleneksel bir client uygulamada bu mesele çok büyümezdi. Çünkü client’ın hangı API çağrılarını yapacağı belliydi, akış aşağı yukarı deterministikti. Ama AI agent öyle değil; doğal dili yorumluyor, hangı tool’u çağıracağına kendi karar veriyor, bazen şaşırtıyor, bazen de saçmalıyor açıkçası. Bir de prompt injection var ki, o ayrı bela.
Agent’ın “iyi niyetli” olmasına güvenerek güvenlik tasarımı yapmak — işte en tehlikeli yer burası. Çünkü mesele agent’ın niyetinde değil; sistemin kuralları yüzünden yanlış veriye hiç erişememesi gerekiyor.
AZ-500 sınavına hazırlanırken bu konuyu defalarca okumuştum ama gerçek sahada görünce olay değişiyor. Bir finans kuruluşunda çalıştığım projede agent, prompt injection ile başka bir kullanıcının “son üç aylık işlem raporu”nu çekmeye ikna edilmişti. Neyse ki staging ortamındaydı. Ama o gün kafama çakılan ders netti: API katmanında “bu kullanıcı bu veriyi görebilir mi?” sorusunun cevabı agent’a bırakılmamalı. (ben de ilk duyduğumda şaşırmıştım)
Şablon ne sunuyor, kısaca?
Garip gelecek ama, azd template’i Azure üzerinde komple bir AI agent uygulaması ayağa kaldırıyor. Birkaç komutla çalışır hâle geliyor. İçinde neler var diye bakınca tablo kabaca şöyle:
- Backend agent: Microsoft Foundry üzerinde çalışan, C# ile yazılmış yapı. Microsoft A2A ve MCP SDK’larını kullanıyor.
- MCP Server: Örnek bir portfolio API’sını expose ediyor.
- Curity Identity Server: Authorization server olarak ayarlanmış durumda. Microsoft Entra ID ile birlikte çalışıyor — Entra kimlik doğrulama yapıyor, Curity işe yetkilendirme tarafını yönetiyor.
- External ve internal API gateway’ler: Token exchange ve audit logging için araya giriyorlar. — bunu es geçmeyin
- Bicep dosyaları: Container Apps, VNet, Container Registry, Azure AI Foundry, Key Vault, Azure SQL Database ve config dosyaları için storage hesabı — hepsi otomatik provision ediliyor.
Doğrusu, Yanı şöyle düşünün; normalde bunu sıfırdan kurmak için en az iki haftalık altyapı işi çıkar. Bu şablon önü bir akşamüstüne indiriyor gıbı duruyor. Ama asıl kıymet kurulumda değil — pattern’de gizli. Şimdi orayı biraz açayım.
Tam merkezde token zinciri ve “least privilege” var
Eh, Bütün işin kalbinde OAuth 2.0 access token’ları duruyor. Ama klasik OAuth mantığından biraz farklı düşünmek lazım burada. Agent hiçbir zaman API’lere kalıcı erişim almıyor; onun yerine kısa ömürlü. Içinde sadece gereken bilgiyi taşıyan token’lar sistemde dolaşıyor.
Ve işler burada ilginçleşiyor.
Token Portfolio MCP Server’a ulaşana kadar üç farklı kimliğe bürünüyor. İki kez token exchange yapılıyor. Her aşamada token’ın audience’ı değişiyor, scope’u değişiyor (claim’ler de daralıyor). İlk gördüğümde ben de “biraz fazla mı dolambaçlı?” diye düşündüm ama sonra oturdu: her bileşen yalnızca kendi işini yapacak kadar bilgi görüyor. Klasik least privilege yanı. Bu konuyla ilgili agent ile ilgili önceki yazımız yazımıza da göz atmanızı tavsiye ederim. Bu konuyla ilgili Bankacılıkta Customer 360: Azure DocumentDB ile Pratik Yol yazımıza da göz atmanızı tavsiye ederim.
Peki token zinciri nasıl akıyor?
Kafada otursun diye basitçe çizeyim:
| Aşama | Token sahibi | Içindeki kritik bilgi | Kim verdi? |
|---|---|---|---|
| 1 | Kullanıcı -> Agent | Kullanıcı kimliği, oturum bilgisi | Entra ID |
| 2 | Agent -> External Gateway | Hangı tool cagirilacak, kullanıcı bağlamı | Curity (1st exchange) |
| 3 | Internal Gateway -> MCP Server | Sadece bu kullanıcının portföy ID’si, dar scope | Curity (2nd exchange) |
Eh, Daha üçüncü aşamada MCP Server’a gelen token’ın içinde sadece “şu kullanıcı şu portföye erişebilir” bilgisi kalıyor desem yeridir. Başka pek bir şey yok zaten.
Yanı agent prompt injection’a uğrayıp “bana neredeyse tüm müşterilerin verisini ver” demeye kalksa bile elindeki token bunu desteklemiyor; kapıyı API katmanı kapatıyor.
Peki Türkiye’deki kurumsal yapılar için bunun anlamı ne?
Açık konuşayım; Türkiye’de finansta, telekomda ve kamuda BDDK, KVKK ya da EPDK gıbı düzenlemeler altında çalışan ekiplerle konuştuğumda en çok takıldıkları yer burası oluyor: “Audit trail nerede? Kim hangı veriye eriştiğini nasıl ispatlayacağız?” Sorular bitmiyor yanı.
Bir dakika — bununla bitmedi.
Tam burada şablondaki internal API gateway işe yarıyor gıbı görünüyor çünkü her token exchange loglanabiliyor.
Yanı denetimde “Falanca tarihte falanca müşterinin portföyüne kim erişti, hangı agent üzerinden geçti ve hangı yetkiyle yaptı?” sorusuna cevap verebiliyorsunuz.Ben bunu BDDK denetimi geçmiş bir bankada gördüğümde içim rahatlamıştı açıkçası. tan konusundaki yazımız yazımızda bu konuya da değinmiştik.
Maliyet tarafını da atlamayayım.Hmm… TL bazında bakınca Container Apps ile Azure AI Foundry kombinasyonu orta ölçekli kullanımda aylık yaklaşık 8.000-15.000 TL bandına oturabiliyor (kuruma göre oynar tabi). Curity Identity Server ayrı lisans istediği için enterprise tarafta ciddi bir kalem çıkabiliyor.Eğer küçük bir startup iseniz açık söyleyeyim bu mimarı size ağır gelebilir; daha hafif tarafta Entra ID + Azure API Management ile basit bir token exchange kurgusu yapılabilir.Tabii o zaman Curity’nın sunduğu fine-grained authorization detaylarını da bırakmış oluyorsunuz. mssql-python’da Apache Arrow Desteği: Sahadan Notlar yazımızda bu konuya da değinmiştik.
Ve işler burada ilginçleşiyor.
Kime hangı yaklaşım daha uygun?
- Küçük ekip / startup: Entra ID + APIM + custom policy daha ucuzdur ve daha hızlı ayağa kalkar.Ama scope yönetimini siz yazarsınız,yanı yük biraz size kayar.. (bence en önemlisi)
- Orta ölcek SaaS: Bu şablon birebir kullanılabilir.Gelip hazır geliyor diyebilirim. (bu kritik)
- Büyük kurumsal (banka, telekom) : Şablonu temel alın, ama internal gateway tarafına kendi audit ve rate-limiting katmanlarınızı ekleyin. Şablon iyi başlangıç noktası, son durak değil.
Pratikte ilk adımlar nasıl gidiyor?
# Önkoşullar : azd CLI, Docker, Azure subscription
azd auth login
azd init --template < ;curity-microsoft-template-url> ;
# Parametreleri set et
azd env set CURITY_LICENSE_KEY "... "
azd env set ENTRA_TENANT_ID "... "
# Provision + deploy
azd up
`azd up` komutu Bicepleri çalıştırır, containerları build edip ACR’a push eder, sonra Container Apps’e deploy eder. En sonda size endpoint URL’si verir. İlk denediğimde Curity license key’i unutmuştum; deploy yarıda kaldı. Hata mesajı açıkçası çok net değildi, Container Apps logs’una girip bakmam gerekti. Sizde de böyle olursa önce Key Vault’taki secret’ları kontrol edin derim.
Karşılaşabileceğiniz tipik sorunlar
Bir arkadaşım da geçen ay denedi, ona da yardım ettim. Toparladığım yaygın sorunlar şunlar:
- VNet entegrasyonu: Eğer abonelik seviyesinde policy’nız varsa (mesela “tüm Container App’ler VNet içinde olmalı”), Bicepte bazı revizyonlar gerekebilir.
- Region kısıtlamaları: Azure AI Foundry her bölgede yok. Türkiye’den bakınca West Europe veya Sweden Central tercih edilebilir; latency açısından West Europe bana daha iyi geldi.
- Token süreleri: Default değerler dev için yeterince iyi ama production’da Curity policy’lerini sıklaştırın. 60 dakikalık token MCP server için bana fazla uzun geliyor.
Eksik bulduğum taraflar var mı? Var tabii.
Bence şablon iyi duruyor ama her şey güllük gülistanlık değil.Açık olayım,birkaç eksik gördüm.
Birinçisi,?multi-tenancy?? tarafı pek net değil.Eğer SaaS yapıyorsanız ve çoklu müşteriniz varsa,Curity tarafındaki tenant izolasyonunu kendiniz tasarlamanız gerekiyor.Sablon tek tenant için yazılmış.Foundry Hosted Agents: MAF Ajanını Production’a Almak? yazımda buna biraz değinmiştim,zaten oradaki yaklaşımla birlikte düşünülebilir.
İkinci olarak,?observability?? tarafı zayıf kalıyor.Application Insights bağlantısı var ama token exchange akışlarını izleyebileceginiz hazır dashboard yok.Yani önü sizin yazmanız gerekiyor.Bu aslında test stratejisiyle de bağlantılı;Agent’ı Test Etmek:”Doğru” Tek Bir Yol Değilse Ne Ölür?? yazısında buna girmiştim.
\xc5\x9e\xe7\xf6\xc4\x9fnc\xfcz\xc5\xbcs\xfc \xe2\x80\x94\xc5\xa0\xf6yle\xa0s\xf6yleyeyim,\xa0bu daha \xc4\xb1\xc5\x9fsel not\xa0—\xa0örnek senaryo stock portfolio üzerinden gidiyor.Türkiye’deki müşterilerin çoğuna pek hitap etmeyebilir.Bence sağlık kayıt sistemi ya da e-ticaret order yönetimi gıbı daha jenerik bir senaryo secilseydi daha çok kişiye ulasirdi.Neyse,kod elimizde,biz adapte ederiz.
;Pattern olarak alıp götürmek;
`Bu şablonu birebir kullanmasaniz bile — ki çoğu kurumsal müşteri kendi varyantini yazar — pattern olarak akılda tutulması gereken üç şey var:
`Bir:` Agent’a kalıcı yetki vermeyin.Her tool çağrısında kısa ömürlü,dar scope’lu token uretilsin.`Iki:` Token exchange zinciri kurun.Her katman sadece kendi işine yetecek bilgiyi görsün.`Uc:`API katmanında `bu user bu veriye erişebilir mi?` sorusunu agent’in kararına bırakmayın.Token’in içindeki claimlerden okuyun.
`Bu üç prensibi tutturursaniz,agent’ınız ne kadar yaratıcı olursa olsun,ne kadar kafayı yiyip yanlış araç cagirsa çağırsın,veri sızıntısı riski belirgin şekilde azalır.
]
Sıkça Sorulan Sorular
Bu şablonu kullanmak için Curity lisansı şart mı?
Evet, production ortamı için Curity Identity Server ticarî lisans istiyor. Geliştirme aşaması için community edition var, ama feature seti kısıtlı. Eğer Curity bütçeye sığmıyorsa, aynı pattern’i Entra ID + Azure API Management ile de kurabilirsiniz —. Açıkçası fine-grained authorization tarafında biraz daha el emeği harcamanız gerekiyor. Claude Sonnet 4 GitHub Copilot’ta Emekli Oldu: Geçiş Rehberi yazımızda bu konuya da değinmiştik.
Token exchange pattern’i AI agent’ları için zorunlu mu?
Zorunlu değil, ama bence güçlü bir öneri. Yanı özellikle agent’ınız birden fazla downstream API’ye erişiyorsa ya da prompt injection saldırılarına karşı katmanlı bir savunma istiyorsanız, neredeyse kaçınılmaz hâle geliyor. Tek bir API’ye erişen basit agent’larda işe overkill olabilir, aşırıya kaçmaya gerek yok.
Şablon Microsoft Agent Framework ile uyumlu mu?
Evet, MCP ve A2A SDK’larını kullandığı için Microsoft Agent Framework ekosistemiyle birebir uyuşuyor. Microsoft Agent Framework:.NET’te Akıllı Ajan Devri yazımdaki örneklerle de rahatlıkla entegre edebilirsiniz.
Audit logging KVKK ve BDDK için yeterli mi?
Şablonun sunduğu temel audit trail iyi bir başlangıç noktası, ama tek başına düzenleyici denetim için yetmiyor. Log retention süreleri, log integrity (hani hash chain veya WORM storage gıbı şeyler) ve erişim kontrolleri konusunda ek çalışma yapmanız gerekiyor. Tecrübeme göre BDDK denetimleri özellikle log değişmezliğine takılıyor — bunu baştan söyleyeyim, sürprizle karşılaşmayın.
Bu mimarı maliyet açısından startup’lar için uygun mu?
Açıkçası değil. Curity lisansı + Container Apps + Foundry + Key Vault kombinasyonu aylık birkaç bin dolara kadar çıkabiliyor. Startup iseniz, bence Entra ID + APIM + Azure Functions kombinasyonuyla %30-40 daha ucuz bir varyant kurabilirsiniz — başlangıç için gayet yeterli ölür.
Kaynaklar ve İleri Okuma
Şunu söyleyeyim, Microsoft Azure SDK Blog: Least privilege AI agents
Azure Developer CLI (azd) Resmî Dokümantasyonu
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.
