Agent Governance Toolkit ile MCP Güvenliği: .NET’te Yeni Katman
MCP tarafında asıl mesele ne?
Model Context Protocol, yanı MCP, açık konuşayım, AI dünyasında tool entegrasyonunu bayağı kolaylaştırdı. Bir anda modelin önüne servisler, komutlar, veri kaynakları koyabiliyorsunuz; hani eskiden tek tek özel entegrasyon yazardık ya, işte onun derdi ciddi ölçüde azalıyor. Ama tam burada güzel görünen şeyin küçük bir gölgesi çıkıyor: Her tool’u açınca güvenlik ve yönetişim işi de kapıya dayanıyor.
Ne yalan söyleyeyim, Ben bunu ilk kez 2024 Kasım’da bir finans müşterisinde gördüm. İstanbul Ataşehir’deki ekip, iç destek botuna birkaç dahili araç bağlamak istiyordu. İlk demo çok iyiydi; kullanıcı “şunu çek”, “bunu özetle” dediğinde sistem cevap veriyordu. Fakat tool açıklamalarından biri beklenmedik şekilde riskli bir yön taşıyınca — durun bir dakika — konu sadece işlev değil, kontrol meselesi öldü. Tool çalışıyor olması yetmiyor; neyin kayıt edildiği, neyin çağrıldığı ve neyin geri döndüğü de önemli.
Kısa bir not düşeyim buraya.
İşin aslı şu ki, MCP’nın gücü tam da burada biraz tersine dönüyor. Kolaylık arttıkça saldırı yüzeyi de büyüyor. Prompt injection benzeri talimatlar tool açıklamasına sızabiliyor, yanlış yapılandırılmış bir servis herkesçe çağrılabiliyor ya da çıktı tarafında gereksiz veri modele geri akabiliyor (inanın bana). Kağıt üstünde süper, pratikte göreceğiz artık dediğim nokta bu öldü.
.NET için gelen yeni paket ne yapıyor?
Microsoft’un duyurduğu Microsoft.AgentGovernance.Extensions.ModelContextProtocol paketi tam olarak bu boşluğu dolduruyor. Yanı sız mevcut MCP server kurulumunuza tek bir genişletme noktası ekliyorsunuz. Startup taraması, runtime politikası, response sanitization gibi katmanlar devreye giriyor — dürüst olayım, biraz hayal kırıklığı —. Bu bana yıllar önce Azure IaaS tarafında firewall kuralını sonradan değil en baştan düşünmenin farkını hatırlatıyor; gecikince maliyet büyüyor.
Bir dakika — bununla bitmedi.
Paketin hoş tarafı şu: yüzeyi küçük ama yaklaşımı net. IMcpServerBuilder zincirine oturuyor ve “güvenli yol = kolay yol” fikrini zorluyor. Ben AZ-500. AZ-305 hazırlıklarında da hep aynı şeyi anlattım: güvenlik sonradan eklenen bir aksesuar değil, mimarinin omurgası olmalı. Sız hiç denediniz mi? Burada da mantık aynı.
Geçen yıl Mayıs 2025’te Logosoft tarafında yürüttüğümüz bir üretim pilotunda benzer bir desen vardı; küçük ekipler genelde hızlı ilerlemek istiyor. Policy katmanı atlanınca ilk hata logu geldiğinde herkes birbirine bakıyor. İşte bu paket o “birbirimize bakma” anını azaltmayı hedefliyor. Bence doğru yönde atılmış adım.
Kısa bir not düşeyim buraya.
Startup scanning neden önemli?
Aslında — dur bir saniye, önce şunu söyleyeyim: En tehlikeli şey çoğu zaman çalışma anındaki saldırı değil, daha en başta sisteme giren kötü tanımdır (buna dikkat edin). Startup scanning bunun için var. Tool henüz dışarı açılmadan önce tanımı taranıyor ve riskli bulunanlar fail closed mantığıyla engelleniyor.
Bu yaklaşımın avantajı net: Hatalı tool prod’a sızmadan kesiliyor. Dezavantajı da var tabiî; yanlış pozitif üretebilir ve deploy sürecini biraz sertleştirebilir. Bilhassa startup hızının kritik olduğu küçük ekiplerde bu sertlik rahatsız edebilir. Enterprise tarafta ben bunu daha sağlıklı buluyorum.
Bir de şu var: Eğer takımınızda güvenlik review kültürü zayıfsa, startup gate sizi disipline ediyor. Kulağa sert geliyor ama sahada işe yarıyor. 2019’da kendi lab ortamımda benzer bir “fail open” yapı denemiştim; sonuç? Bir servis güncellemesiyle beklenmeyen tool açıklaması prod testine kadar taşınmıştı. O günden beri başlangıç doğrulamasını hafife almam.
| Konu | Paketin yaklaşımı | Sahadaki etkisi |
|---|---|---|
| Tool kaydı | Başlangıçta tarama | Kötü tanım erken yakalanır |
| Teslim edilen çıktı | Sanitization | Zararlı veri modele dönmez |
| Kural uygulama | Policy enforcement | Erişim kontrolü merkezî kalır |
| Gözlemlenebilirlik | Audit + metrics | Sorun çıktığında iz sürmek kolaylaşır |
Runtime governance pratikte nasıl hissediliyor?
Eh, Runtime tarafı daha ilginç çünkü asıl gerçek hayat orada başlıyor. Kullanıcı ya da agent tool’u çağırdığı anda identity-aware politika devreye giriyor; yanı her çağrı herkese açık değil. Bunu basitçe ofisteki kartlı geçişe benzetiyorum: Kapı açık diye herkes her odaya giremiyor.
Açık konuşayım, burada beni en çok rahatlatan şey response sanitization kısmı öldü. Çünkü sorun bazen girişte değil çıkışta çıkıyor; tool düzgün çalışsa bile döndürdüğü içerikte istemediğiniz bilgi olabilir. Tahmin eder mısınız? Örneğin destek sistemlerinde bazen müşteri notlarının içine hassas detay karışabiliyor ve model bunu istemeden tekrar üretebiliyor.
Nisan 2026’da Ankara’daki bir telekom projesinde buna çok yakın bir durum yaşadık: rapor servisi teknik olarak doğru sonuç veriyordu ama çıktı içinde operasyonel detaylar fazla görünüyordu. Çözüm olarak maskelenmiş alanlar kullandık; bu yeni governance katmanı da aynı kafada ilerliyor. Güzel özellik ama henüz ham… biraz daha pişmesi lazım diyebileceğim yerler var tabiî; örneğin politikaların okunabilirliği büyük organizasyonlarda ekstra dikkat istiyor.
Küçük ekip ile enterprise arasında fark ne?
Küçük ekipseniz hedefiniz hızlıca güvenli varsayılanları almak olmalı. Tek policy dosyasıyla başlayın, sonra ihtiyaç oldukça ayrıntı ekleyin. Büyük kurumsal yapılarda işe işler değişiyor; farklı roller, farklı agent kimlikleri ve ayrı audit beklentileri oluyor.
Bence startup’ların yaptığı en yaygın hata “şimdilik serbest bırakalım” demek oluyor. Enterprise tarafın hatası işe bazen aşırı sıkılık; her şeyi beş onaydan geçirince inovasyon boğuluyor! Dengesi önemli.
using AgentGovernance.Extensions.ModelContextProtocol;
builder.Services
.AddMcpServer()
.WithGovernance(options =>
{
options.PolicyPaths.Add("policies/mcp.yaml");
options.DefaultAgentId = "did:mcp:server";
options.ServerName = "contoso-support";
});Bence nerede çok işe yarar?
Küçük bir detay: Lafı gevelemeden söyleyeyim: İç araçları olan kurumlarda çok işe yarar. En çok da de helpdesk botları, finans raporlama ajanları, insan kaynakları self-servis çözümleri gibi senaryolarda MCP cazip geliyor ama kontrolsüz bırakılırsa ciddi risk oluşturuyor.
Ana fayda şu üçlüde toplanıyor: policy enforcement, runtime call kontrolü ve response sanitization. Bunların ayrı ayrı custom filter ile yapılması mümkün elbette ama dürüst olayım, o zaman bakım yükü artıyor. Her proje için yeniden aynı plumbing’i kurmak pek keyifli değil.
- Kayıt öncesi kontrol: Riskli tool tanımlarını erkenden yakalarsınız.
- Çağrı anı politika: Kim hangi aracı kullanabilir belli olur. (bu kritik)
- Cevap temizleme: Hassas veri modelden uzak tutulur.
- Araştırılabilirlik: Audit kayıtları olay sonrası analizi kolaylaştırır.
Dikkat etmeniz gereken eksikler de var
E tabi her yeni paket gibi bunun da sınırlı yanları olacak. Public Preview olması nedeniyle API değişiklikleri yaşayabilir,davranışlar olgunlaşmamış olabilir. Ben böyle durumlarda direkt prod’a koşmam.
Şöyle söyleyeyim, Dürüst olmak gerekirse dokümantasyon ne kadar iyi olsa da kurum içi politika tasarımı olmadan paket tek başına mucize yaratmaz. Yanı guardrail’i veriyor ama kural kitabını sizin yazmanız gerekiyor. Bu bende hafif hayal kırıklığı yaratmadı değil; çünkü bazı ekipler paketi takınca sihir bekleyebilir.
Ayrıca maliyet tarafını da düşünün. Azure dünyasında “tek satırla güvenlik” kulağa ucuz geliyor ama gerçek maliyet çoğu zaman operasyonel tarafta çıkıyor:policy bakımı,log saklama,audit inceleme,uyumluluk kontrolleri… TL bazında baktığınızda bunların hepsi toplam sahip olma maliyetini etkiler. Alternatif çözüm arayanlar için başlangıçta basit allowlist + manuel audit de düşünülebilir; bütçe kısıtlıysa bayağı otomasyona geçmeden önce bu yol iş görebilir.
Türkiye’de bunu nasıl okurum?
Bunu Türkiye’deki şirketler açısından değerlendirirsek mesele sadece teknoloji değil,güven kültürü meselesi oluyor (yanlış duymadınız). Kurumsal müşterilerimde gördüğüm kadarıyla bizim tarafta ekipler hızlı sonuç görmek istiyor; haklılar da,ama security review sonradan gelince emek boşa gidiyor. MCP gibi protokoller tam burada hem fırsat hem risk taşıyor.
Büyük bankalarda veya regülasyon ağırlıklı sektörlerde ben bu tarz governance katmanlarını neredeyse zorunlu görüyorum. Çünkü ajanlara verilen erişim arttıkça soru şuna dönüşüyor:“Bu araç çalışıyor mu?” değil,“Bu aracın bugün hangi kapsamda çalışmasına izin veriyoruz?” Startup’ta belki tek policy dosyası yeter,ama enterprise seviyede rol haritalaması,veri sınıflandırması ve log korelasyonu şart.
Sahada ilk iş ne olmalı?
- MCP server’daki mevcut araç listesini çıkarın.
- En riskli iki tool’u belirleyip önce onları tarayın.
.WithGovernance()ile policy dosyasını bağlayın. (bence en önemlisi)- Audit log’ları SIEM’e akıtıp birkaç gün izleyin.
- Tepki süresine bakıp false positive oranını ölçün. (bu kritik)
Sıkça Sorulan Sorular
MCP governance neden gerekli?
MCP araç entegrasyonunu kolaylaştırdığı için saldırı yüzeyi de büyüyor. Governance olmadan hani her tool’un kim tarafından çağrıldığı ve ne döndürdüğü kontrolsüz kalabiliyor. Bu yüzden güvenlik katmanı şart.
Bu paket production için hazır mı?
Paket şu an Public Preview aşamasında, yanı önce test ortamında denemek çok daha doğru olur. Küçük pilotlarla başlayıp davranışı ölçmek en sağlıklısı. Açıkçası prod kararı vermeden önce log ve policy sonuçlarına iyi bakın (bizzat test ettim)
.NET MCP server’a nasıl eklenir?
`dotnet add package Microsoft.AgentGovernance.Extensions.ModelContextProtocol` komutuyla ekleniyor. Sonra `AddMcpServer().WithGovernance(…)` zinciriyle policy yollarınızı bağlıyorsunuz. Kurulum aslında çok kısa, tecrübeme göre asıl iş policy tasarımında bitiyor.
Küçük ekipler için uygun mu?
Evet, bence özellikle uygun çünkü güvenliği baştan standardize ediyor (evet, doğru duydunuz). Ama fazla katman açmadan başlamanız lazım; yoksa geliştirme hızı düşebilir. Önce az sayıda rule ile ilerlemek mantıklı.
Kaynaklar ve İleri Okuma
Bir şey dikkatimi çekti: Microsoft.NET Blog — Agent Governance Toolkit MCP Extensions for.NET Duyurusu
Microsoft Learn — Model Context Protocol and.NET AI Uygulamaları
Model Context Protocol GitHub Organizasyonu
İlgili Yazılar
Hani, Prompt Injection’ı Durdurmak: Agent Framework’te FIDES:
Visual Studio’da Plan Agent: Kodu Yazmadan Önce Durup Düşünmek:
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.
Yorum gönder