Least Privilege Ajanlar: Güvenliği Baştan Kurmanın Yeni Yolu
AI ajanlarıyla ilk demo’yu ayağa kaldırmak kolay. Zor taraf, önü gerçek dünyaya çıkarınca başlıyor. Çünkü işin içine müşteri verisi girince, “çalışıyor” demek yetmiyor; “kime neyi gösterecek?” sorusu tam ortaya oturuyor.
Ben bu meseleyi yıllardır farklı şekillerde gördüm. 2018’de bir finans müşterisinde, dışarıdan basit duran bir raporlama akışı yanlış rol eşlemesi yüzünden başka departmanın verisini göstermeye kalkmıştı. O gün şunu net anladım: güvenlik sonradan eklenen bir katman değil, tasarımın göbeği olmalı. Ajanlarda bu ihtiyaç daha da sertleşiyor. Ajan bazen kullanıcıdan hızlı davranıyor, bazen de fazla yaratıcı oluyor… ve işte o an hata pahalıya patlıyor.
Microsoft ile Curity’nın ortaya koyduğu yeni azd template, tam da bu noktada dikkatimi çekti. Kağıt üstünde sadece bir şablon gibi dürüyor ama aslında mesajı açık: ajanlara sınırsız erişim vermeyin, kısa ömürlü. Dar kapsamlı token’larla konuşturun. Açık konuşayım, bu yaklaşım fena değil; hatta kurumsal tarafta baya iş görüyor.
Çok konuştum, örnekle göstereyim.
Neden bu kadar dert ediyoruz?
Bi saniye — Bir ajan demo’su yaparken çoğu ekip önce modeli seçiyor, sonra tool çağrılarını bağlıyor, en son da auth kısmını “bir şekilde hallederiz” diye bırakıyor. İşte sorun burada başlıyor. Kimlik doğrulama tamam da yetkilendirme nerede? Kullanıcının kim olduğunu bilmek ayrı şey, hangi satırı görmesi gerektiğini bilmek ayrı şey.
Geçen sene Mart ayında İstanbul’daki bir perakende müşterisinde buna benzer bir durum yaşadık. Ajan stok sorusuna doğru cevap veriyordu ama bazı ürün gruplarında bölgesel veri sınırlarını hiç umursamıyordu; çünkü arka taraftaki API sadece giriş yapılmış mı diye bakıyordu. O gün aldığımız ders şu öldü: AI tarafı ne kadar zeki olursa olsun, veri sınırını sistem düzeyinde zorlamazsanız mevzu karışıyor.
Hmm, bunu nasıl anlatsamdı…
Ajanların farkı şu: klasik uygulamalar tahmin edilebilir istekler gönderir. Ajan işe niyet okur gibi davranır ama bazen yanlış okur. Prompt injection dediğimiz olay da cabası… Kullanıcı kötü niyetli olmasa bile model yön değiştirip istemediğiniz API çağrısını tetikleyebilir. Bu yüzden “model doğru karar verir” varsayımı üzerine güvenlik kurmak bana göre biraz hayal kırıklığı yaratır.
Kimlik var diye her şey çözülmüyor
Entra ID ile giriş yaptırmak güzel başlangıçtır ama tek başına yetmez. Asıl mesele erişim hakkının nerede kontrol edildiği. Eğer karar tamamen ajanın omzundaysa — ki bence olmamalı — orada güvenlik zaten kırılgan hâle gelir.
Curity’nın burada sunduğu bakış açısı hoş: token içinde yalnızca gerekli bilgi olsun ve API kendi kararını verebilsin. Yanı kapıya gelen kişinin adı belli olsun ama hangi odaya gireceğine bina yönetimi karar versin. Basit anlatıyorum ama mantık tam olarak bu.
Template’in verdiği yapı neden anlamlı?
Doğrusu, Bu şablon Azure üzerinde uçtan uca çalışan bir örnek kuruyor: Foundry tarafında C# tabanlı backend ajanı, MCP sunucusu üzerinden örnek portfolio API’si, Curity Identity Server ile authorization server katmanı. Bakın, entra ID ile kullanıcı kimliği doğrulaması… Peki bunu neden söylüyorum? Bir de gateway’ler var; token exchange ve audit logging işini sessizce arkada yapıyorlar.
Bence en değerli tarafı şu: herkesin gözünü boyayan “ajan demo” hissinden çıkıp gerçek mimarı düşünmeye zorluyor olmasıdır. Çünkü üretimde mesele sadece LLM değil; ağ sınırı var, loglama var, anahtar yönetimi var, veri ayrımı var… Hatta çoğu zaman asıl karmaşa modelde değil çevresindeki altyapıda çıkıyor.
Ajanlara güvenmeyin demiyorum; onlara körü körüne yetki vermeyin diyorum.
Küçük ekip için başka büyük kurum için başka
Bakın, Küçük bir startup iseniz her şeyi aynı anda kurmaya çalışmayın derim. Önce basit RBAC + kısa ömürlü access token + merkezî loglama üçlüsü yeterli olur çoğu senaryoda. Sonra ihtiyaç büyürse Curity gibi daha gelişmiş yetkilendirme katmanlarına geçersiniz.
Büyük enterprise yapısındaysanız iş değişiyor tabi… Veri kaynağı sayısı artınca tenant ayrımı, audit trail ve policy enforcement kritik hâle geliyor. En çok da bankacılıkta veya sigortada agentic workflow’u doğrudan API’ye bağlamak yerine gateway üzerinden geçirmek çok daha sağlıklı dürüyor.
| Kriter | Küçük Ekip | Büyük Kurum |
|---|---|---|
| Yetkilendirme modeli | Sade RBAC + scope | Cephe cephe policy + claim dönüşümü |
| Token süresi | Kısa ama yönetilebilir | Daha sık yenileme + exchange zinciri |
| Loglama | Basit izleme yeterli olabilir | Tam audit ve korelasyon şarttır |
| Maliyet yaklaşımı | MVP odaklı düşük operasyon yükü | Daha yüksek ama denetlenebilir yapı gerekir) |
OAuth token zinciri pratikte ne kazandırıyor?
Küçük bir detay: Açık konuşayım, OAuth’un gücü burada teoriden çok pratikte ortaya çıkıyor. Ajan permanent erişim almıyor; bunun yerine kısa süreli access token alıp işi bitiriyor. E peki, sonuç ne öldü? Böylece ele geçirilse bile zarar penceresi dar kalıyor.
2021’de Ankara’daki bir telekom projesinde benzer mantığı servis-servis iletişiminde kullanmıştık. O zaman problem agent değildi tabi, ama aynı prensip vardı:servisin elinde sürekli anahtar gezmesin.Kayıt defterine benzeyen uzun ömürlü secret’lar yerine görev bazlı erişim kullandığınızda kriz ihtimali baya düşüyor.
Peki neden iki kere token exchange? Çünkü aradaki hop’ları ayırarak hem kullanıcı bağlamını koruyorsunuz hem de iç sistemlerin dışarı taşmasını engelliyorsunuz. İlk bakışta biraz fazla prosedür gibi dürüyor,haklısınız;ama enterprise ortamda prosedür bazen can kurtarıyor.
Bana göre iyi tarafı ne?
Zincir sayesinde API şunu anlayabiliyor:bu istek gerçekten hangi kullanıcı adına geldi,hangi kapsamla geldi,hangi kaynak için izin aldı？ Mesela portfolio örneğinde user A’nın hesabına ait rapor üretirken user B’nın verisine dokunulmaması gerekiyor. Bunun yolu modeli eğitmekten çok doğru claim set’i tasarlamak.
Maliyet,operasyon ve Türkiye gerçeği)
Bunu Türkiye’deki şirketler açısından değerlendirelim: Şimdi dürüst olayım, pek çok ekip hâlâ cloud maliyetini dolar kuru üzerinden görünce frene basıyor. Haklılar da.Ama security’yi sonradan yamamak genelde daha pahalıya geliyor; özellikle denetim gerektiren sektörlerde.
Bakın, Eğer bütçe kısıtlıysa ilk aşamada Curity benzeri ağır bir kuruluma atlamak zorunda değilsiniz.Azure API Management ya da uygun scope tasarımıyla başlayıp küçük çapta least privilege prensibini oturtabilirsiniz. Fakat müşteri sayısı arttığında veya veri alanları keskinleştiğinde merkezî authorization server’a geçmek kaçınılmaz hâle gelir.
Eh, Kendi deneyimimde en büyük hata hep aynı öldü:ekipler önce özellik peşine düşüyor,güvenliği sonra düşünüyor. AZ-500’e hazırlanırken not ettiğim temel cümlelerden biri şuydu:“Yetki tasarımı yoksa otomasyon sadece hızlı risk üretir.” Bugün hâlâ bunun altına imza atarım (şaşırtıcı ama gerçek)
{
"iss": "curity",
"sub": "user123",
"aud": "portfolio-api",
"scope": "portfolio.read",
"act": {
"client_id": "agent-backend"
},
"exp": "short-lived"
}
- User identity ile resource permission’ı birbirine karıştırmayın.
- Ajanın aldığı izinleri minimumda tutun.
- Audit logging’i sonradan eklemeye çalışmayın; baştan planlayın.
- Pilot aşamada basit başlayın ama production sınırlarını erken çizin.
- Eğer prompt injection riski varsa policy’i modele emanet etmeyin.
Nereden başlamalı?
Lafı gevelemeden söyleyeyim: ilk adımınız mimarı çizim olsun, kod değil. Hangi kullanıcı hangi veriyi görecek, hangi tool’u çağıracak, hangi gateway’den geçecek — bunları kağıtta netleştirin. Sonra token flow’u çizin; kimden kime, ne kadar süreyle gidiyor diye bakınca işler hızlı toparlanıyor.
İkinci adım olarak test senaryolarınızı genişletin: Sadece mutlu yol yazmayın. Prompt injection deneyin,yanlış customer id deneyin,expired token deneyin,scope dışı resource isteyin… Geçen ay İzmir’deki bir SaaS firmasına bunu önermiştim; ilk hafta iki tane ciddi açık yakaladılar. Bekledikleri kadar temiz çıkmadı yanı, ama iyi ki erken çıktı.
Eğer Foundry veya benzeri agent framework kullanıyorsanız MVP sonrası şu soruyu muhtemelen sorun:“Bu agent yanlış yönlendirilirse en kötü ne olur?” Cevap sizi rahatsız ediyorsa mimariyi yeniden düşünmeniz gerekir. Ben genelde bunu müşteriye şöyle anlatıyorum:ajan sizin stajyeriniz gibi olsun, kasanın anahtarı onda olmasın: Basit ama etkili.
Foundry Toolboxes: Ajan Araçlarını Toplamak Neden Şart Öldü?
Microsoft Agent Framework ile.NET’te Ajan Kurmanın İncelikleri
Sıkça Sorulan Sorular
Ajanlarda least privilege neden bu kadar önemli?
Şöyle düşünün: ajanlar deterministik olmayan kararlar verebiliyor, yanı ne yapacaklarını tam olarak kestiremiyorsunuz. Yetkiyi minimumda tutarsanız hata payı da küçülüyor. Mesela prompt injection olsa bile etki alanı dar kalıyor — bence bu tek başına yeterince kuvvetli bir neden.
Sadece Entra ID kullanmak yeter mi?
Aslında — hayır dur, daha doğrusu tamamlayıcı bir çözüm ama tek başına yetmiyor. Hani kimlik doğrulama ayrı bir şey, kaynak seviyesinde yetkilendirme ayrı bir şey. İkisini birlikte düşünerek tasarlamak gerekiyor — açıkçası biri olmadan diğeri eksik kalıyor.
Küçük ekipler bu modeli nasıl uygular?
Önce sade bir scope yapısıyla başlayın, sonra audit logging ekleyin. Her şeyi aynı günde kurmaya çalışmayın; tecrübeme göre yavaş ilerlemek burada çok daha sağlıklı oluyor.
Bu template production için hazır mı?
Mimarı açıdan güçlü sinyaller veriyor, yanı iyi bir başlangıç noktası. Ama yine de kendi veri modellerinizle uyarlamanız şart. Açıkçası hazır çözüm diye körlemesine almak pek doğru olmaz.
Kaynaklar ve İleri Okuma
Orijinal Microsoft Blog Yazısı
Microsoft Entra ID Access Token Dokümantasyonu
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.
2 comments