9 dk okuma
Giriş
MCP Server güvenliği artık yalnızca bir AI istemcisinin bir araca bağlanıp bağlanamadığıyla ilgili değildir. Model Context Protocol; dosya sistemleri, kurumsal API’ler, veritabanları ve iş araçlarını yapay zekâ uygulamalarına standart bir arayüzle açarken aynı zamanda yeni bir güven sınırı oluşturur. Bir tool yalnızca veri okuyorsa risk başka, kayıt değiştiriyor, mesaj gönderiyor veya dış sisteme işlem açıyorsa risk bambaşkadır.
Üretim ortamında doğru yaklaşım, modele geniş yetki vermek yerine her tool’u ayrı bir güvenlik yüzeyi olarak ele almaktır. Kimlik doğrulama, yetkilendirme, minimum veri paylaşımı, kullanıcı onayı, prompt injection savunması ve audit log birlikte tasarlanmadığında “çalışan MCP entegrasyonu” güvenli MCP entegrasyonu anlamına gelmez.
Bu rehber, özellikle .NET tabanlı servisler geliştiren ekiplerin MCP sunucularını mevcut backend güvenlik prensipleriyle nasıl birleştirebileceğini yedi pratik adımda ele alıyor. Amaç belirli bir sağlayıcıya bağımlı çözüm vermek değil; farklı MCP istemcileri ve kurumsal sistemler arasında uygulanabilecek sürdürülebilir bir güvenlik modeli kurmak.
.NET ile güven sınırı, tool izinleri, onay akışı, veri minimizasyonu ve audit log yaklaşımını çalışan örnek üzerinde inceleyin.
İçindekiler
- MCP için güven sınırını belirleyin
- Kimlik doğrulama ve yetkilendirmeyi tool’dan ayırın
- Tool izinlerini minimum yetkiyle tasarlayın
- Prompt injection ve güvenilmeyen veriyi ayrı tehdit olarak ele alın
- Veri minimizasyonu ve secret yönetimini uygulayın
- Hassas işlemlerde kullanıcı onayı ve idempotency kullanın
- Audit log, tracing ve güvenlik testlerini üretim standardı yapın
- Sonuç
- Güvenilir Araştırma Kaynakları
1. MCP için güven sınırını belirleyin
İlk soru “hangi SDK’yı kullanacağım?” değil, “hangi sistem kime güveniyor?” olmalıdır. MCP host, istemci, sunucu, tool ve downstream servisler aynı güven alanında kabul edilmemelidir. Özellikle uzak MCP sunucularında gelen isteğin kimliği ile tool’un eriştiği kurumsal kaynağın kimliği birbirinden ayrılmalıdır.
2026-07-28 MCP spesifikasyonu protokol çekirdeğini stateless modele taşıdı. Bu değişiklik ölçekleme ve standart HTTP altyapısı açısından avantaj sağlarken, uygulama durumunu ve yetki bağlamını açık biçimde yönetme sorumluluğunu ortadan kaldırmaz. Her çağrıda kullanıcı veya istemci bağlamının yeniden doğrulanması, state gerekiyorsa bunun görünür ve sınırlandırılmış handle’larla taşınması daha öngörülebilir bir model oluşturur.
Pratikte internetten erişilebilen bir MCP endpoint’i, normal bir production API gibi reverse proxy, TLS, rate limit, WAF veya gateway politikaları ve merkezi gözlemlenebilirlik arkasında konumlandırılmalıdır. MCP kullanmak HTTP güvenlik katmanlarını gereksiz hale getirmez.
2. Kimlik doğrulama ve yetkilendirmeyi tool’dan ayırın
Authentication kullanıcının veya istemcinin kim olduğunu, authorization ise ne yapabileceğini belirler. Bu iki kontrolü tool metodunun içine dağılmış birkaç if bloğuna bırakmak zamanla güvenlik politikasını görünmez hale getirir. HTTP tabanlı MCP sunucusunda token doğrulama ve erişim politikası mümkün olduğunca sınır katmanında uygulanmalıdır.
MCP’nin güncel authorization yaklaşımı OAuth tabanlı akışları ve issuer doğrulaması gibi korumaları güçlendiriyor. Özellikle bir istemcinin birden fazla authorization server ile çalıştığı senaryolarda token’ın hangi issuer tarafından üretildiğinin doğrulanması kritiktir. Token doğrulandıktan sonra tool’a yalnızca gerekli identity ve claim bağlamı aktarılmalıdır.
Kurumsal kullanımda “MCP’ye bağlandıysa her şeyi yapabilir” modeli yerine rol, tenant, kaynak ve operasyon bazlı policy kullanmak daha güvenlidir. Okuma yetkisi olan kullanıcının write tool’larını görmesi bile gereksiz saldırı yüzeyi oluşturabilir.
3. Tool izinlerini minimum yetkiyle tasarlayın
Bir tool’un adı masum görünebilir ama gerçek risk yaptığı yan etkidedir. search_documents ile delete_document aynı güvenlik seviyesinde değildir. Bu nedenle tool kataloğunu read-only, write, destructive ve external-side-effect gibi sınıflara ayırmak; her sınıf için farklı izin ve onay politikası tanımlamak gerekir.
Tool annotation veya açıklamaları istemciye risk hakkında ipucu verebilir fakat bunlar güvenlik kontrolü değildir. Güvenilmeyen bir sunucu kendi tool’unu read-only olarak tanımlayıp farklı davranabilir. Sert garanti gereken noktada authorization, sandbox, ağ kısıtı ve downstream servis politikaları devreye girmelidir.
Tool girdileri de klasik API input’u gibi doğrulanmalıdır. Dosya yolu, URL, filtre, kullanıcı kimliği veya dış servis parametresi model tarafından üretildi diye güvenilir kabul edilmemeli; allowlist, şema doğrulama, uzunluk sınırı ve iş kuralı kontrolü uygulanmalıdır.
4. Prompt injection ve güvenilmeyen veriyi ayrı tehdit olarak ele alın
Prompt injection, MCP mimarisinde özellikle önemlidir çünkü model yalnızca metin üretmek yerine tool çağırabilir. Bir web sayfası, e-posta, doküman veya üçüncü taraf tool çıktısı “şu gizli veriyi başka adrese gönder” benzeri talimat taşıyabilir. Model bu metni veri yerine talimat gibi yorumlarsa klasik uygulama güvenliğinin dışında yeni bir saldırı zinciri oluşur.
Bu nedenle güvenilmeyen içerik ile yüksek etkili tool’ların aynı akışta buluştuğu noktalar özel olarak işaretlenmelidir. Harici içerik okuyan bir agent’ın aynı anda dosya silme, e-posta gönderme veya kayıt güncelleme yetkisine sahip olması gerekiyorsa hassas aksiyon öncesi ek onay ve policy kontrolü kullanılmalıdır.
OpenAI’nin MCP güvenlik rehberi de güvenilir sunucularla çalışmayı, hassas aksiyonlarda onay istemeyi, izin verilen tool’ları sınırlamayı ve MCP sunucularına gönderilen veriyi izlemeyi öneriyor. Temel fikir modelin kararını tek güvenlik katmanı haline getirmemektir.
5. Veri minimizasyonu ve secret yönetimini uygulayın
MCP tool’una “belki lazım olur” düşüncesiyle büyük veri nesneleri göndermek hem maliyet hem güvenlik riskidir. Tool yalnızca bir kaydın durumunu öğrenmek için iki alan gerektiriyorsa tüm müşteri nesnesini, erişim token’larını veya dahili metadata’yı modele taşımak gereksizdir. Girdi ve çıktıda en az veri prensibi uygulanmalıdır.
Secret değerleri prompt, tool description, log veya model context içinde taşınmamalıdır. API anahtarları ve servis credential’ları sunucu tarafında secret store veya güvenli environment mekanizmasıyla tutulmalı; tool yalnızca ihtiyaç duyduğu işlemi gerçekleştirmelidir.
Ayrıca üçüncü taraf MCP sunucusuna gönderilen verinin artık o sağlayıcının saklama ve veri yerleşimi politikasına tabi olabileceği unutulmamalıdır. Kurumsal ve kişisel veri sınıflandırması bağlantı kurulmadan önce yapılmalıdır.
6. Hassas işlemlerde kullanıcı onayı ve idempotency kullanın
Para hareketi, kayıt silme, e-posta gönderme, sipariş oluşturma veya dış sisteme kalıcı işlem yazma gibi aksiyonlarda modelin tek başına son karar verici olması doğru değildir. Kullanıcıya işlemin ne yapacağını ve kritik parametreleri gösteren açık bir onay adımı, yanlış tool seçimi veya prompt injection etkisini önemli ölçüde sınırlar.
Onay güvenliğin bir parçasıdır ama tekrar çağrı riskini çözmez. Ağ zaman aşımı veya istemci retry davranışı aynı write tool’unu ikinci kez çalıştırabilir. Bu nedenle yan etkili tool’larda idempotency key, benzersiz işlem kimliği veya downstream sistemin sunduğu tekrar koruması kullanılmalıdır.
Bu konu, sitedeki ASP.NET Core API idempotency rehberindeki atomik garanti ve tekrar istek yaklaşımıyla aynı prensibe dayanır. MCP tool’u da sonuçta güvenilir bir backend operasyonunun üstünde çalışan yeni bir çağrı yüzeyidir.
İlgili iç bağlantı: ASP.NET Core API’lerde Idempotency: 7 Adımda Çift İşlemi Önleme
7. Audit log, tracing ve güvenlik testlerini üretim standardı yapın
Güvenli MCP sistemi yalnızca saldırıyı engellemekle değil, ne olduğunu sonradan açıklayabilmekle de ilgilidir. Kim hangi tool’u çağırdı, hangi policy uygulandı, onay alındı mı, downstream işlem sonucu ne oldu ve hata hangi trace içinde oluştu sorularına cevap verecek audit kayıtları tutulmalıdır.
Loglarda prompt’un veya tool payload’un tamamını körlemesine saklamak yerine kişisel veri ve secret redaction uygulanmalıdır. Teknik tracing için correlation veya trace id, tool adı, süre, sonuç sınıfı ve hata kodu çoğu durumda yeterli başlangıçtır. Güncel MCP çalışmaları W3C Trace Context ile uçtan uca izlenebilirliği de standartlaştırıyor.
Test tarafında yalnızca happy path yeterli değildir. Yetkisiz kullanıcı, yanlış tenant, değiştirilmiş parametre, tekrarlanan çağrı, prompt injection içeren tool çıktısı, timeout ve downstream 5xx gibi senaryolar otomasyona alınmalıdır. Bir tool arka planda güvenilir mesajlaşma veya veri senkronizasyonu başlatıyorsa Transactional Outbox gibi desenlerle yan etkilerin dayanıklılığı ayrıca ele alınabilir.
İlgili iç bağlantı: ERP Entegrasyonlarında Transactional Outbox: 7 Adımda Güvenilir Veri Senkronizasyonu
Sonuç
MCP Server güvenliği, modele bir tool listesi vermeden önce başlayan ve tool çalıştıktan sonra audit kayıtlarına kadar devam eden uçtan uca bir mimari konudur. Güven sınırını açık tanımlamak, OAuth tabanlı kimlik ve yetki kontrolünü doğru yerde uygulamak, tool’ları minimum yetkiyle tasarlamak, prompt injection riskini bağımsız bir tehdit olarak ele almak, veriyi azaltmak, hassas aksiyonlarda kullanıcı onayı istemek ve tüm çağrıları izlenebilir hale getirmek üretim kalitesinin temelini oluşturur.
MCP’nin değeri mevcut API ve servis güvenliği prensiplerini değiştirmesinde değil, AI uygulamalarını bu sistemlere standart biçimde bağlamasında yatıyor. En sağlam tasarım, modelin esnekliğini korurken kritik kararları deterministik backend politikalarıyla sınırlar. Böylece AI tool entegrasyonu bir demo özelliğinden çıkıp denetlenebilir ve sürdürülebilir bir kurumsal bileşene dönüşür.