MCP Güvenliği 2026: Bir Yapay Zekâ Ajanına Araç Vermeden Önce Bilmeniz Gerekenler

İnceleme ve güncelleme: 14 Temmuz 2026. Bir yapay zekâ ajanına MCP aracı bağlamak, pasif bir entegrasyon kurmakla aynı şey değil. Modelin ürettiği niyetin dosya okumaya, veritabanı sorgusuna, mesaj göndermeye, deployment almaya veya komut çalıştırmaya dönüşebildiği yeni bir güven sınırı açıyorsunuz.

Bu durum Model Context Protocol’ü doğrudan güvensiz yapmıyor. Fakat MCP güvenliğini “OAuth kullanıyoruz” ya da “kullanıcı Allow düğmesine bastı” seviyesinde bırakamayacağınızı gösteriyor. Üretim ortamında dört alanı birlikte güvenceye almalısınız: modelin gördüğü bağlam, aracın yapabildikleri, yetkiyi veren kimlik ve aracın gerçekten çalıştığı ortam.

Bu rehberi güncel kararlı MCP spesifikasyonuna, MCP’nin resmî güvenlik önerilerine, OWASP MCP Top 10 projesine, açık CVE kayıtlarına ve saldırıları yayımlayan birincil araştırmalara dayanarak hazırladım. Henüz gelişmekte olan bir öneriyi tamamlanmış standart gibi göstermiyorum; durumunu açıkça belirtiyorum.

Kısa cevap

Bir aracı ajana bağlamadan önce şu beş soruya net yanıt verin:

Sunucu veya tool schema modeli yönlendirebilir mi? Açıklamalar, parametre adları, varsayılan değerler, enum’lar, annotation’lar ve dönen içerik ajanın karar bağlamına giriyor.
Tek bir hatalı çağrının yaratabileceği en büyük zarar ne? Salt okunur arama ile production verisi silme aynı onay yolundan geçmemeli.
İşlem kimin yetkisiyle yapılıyor? Bağlantıyı kurmak kolay diye model geniş kapsamlı kullanıcı token’ını, servis hesabını veya geliştiricinin ortam kimlik bilgilerini devralmamalı.
Çalışan süreci ne sınırlandırıyor? Dosya sistemi, ağ, CPU, bellek, secret ve alt süreç erişimi prompt dışında uygulanmalı.
Kararı sonradan eksiksiz inceleyebilir misiniz? Sunucu kimliği, schema sürümü, çağıran kimlik, argümanlar, politika kararı, sonuç sınıfı ve onay olayı; secret’lar loglanmadan kaydedilmeli.

Yanıtlardan biri “modele güveniyoruz” veya “kullanıcı sunucuyu zaten onayladı” ise mimari henüz tamamlanmamış demektir.

MCP güven sınırını neden değiştiriyor?

MCP sunucu özelliklerini prompts, resources ve tools olarak ayırıyor. Kararlı spesifikasyon; prompt’ları kullanıcı kontrollü, kaynakları uygulama kontrollü, araçları ise model kontrollü tanımlıyor. “Model kontrollü”, dil modelinin araçları keşfedip seçebilmesi anlamına geliyor; güvenli bir istemcinin her seçimi otomatik çalıştırması gerektiği anlamına gelmiyor.

Resmî tools spesifikasyonu, kullanıcının araç çağrısını reddedebilmesini özellikle istiyor. Ayrıca uygulamaların hangi araçların açıldığını göstermesini, çalışma sırasında görünür bildirim sunmasını, operasyonlarda onay istemesini, giriş ve sonuçları doğrulamasını, timeout uygulamasını ve çağrıları kaydetmesini öneriyor.

Buradaki kritik fark şu: MCP sunucusu, kendi kodu çalışmadan önce model bağlamını etkileyebiliyor. Geleneksel istemci bir OpenAPI şemasını uygulama kodu için dokümantasyon olarak kullanır. Ajan ise MCP şemasını hem dokümantasyon hem talimat gibi yorumlayabilir. Klasik API güvenliğinin üzerinde yeni bir katman oluşmasının nedeni bu.

Tek bağlantı, üç ayrı saldırı yüzeyi

Yüzey	Tipik sorun	Temel savunma
Model bağlamı	Tool poisoning, gizli talimat, manipüle edilmiş sonuç	Tam schema incelemesi, sürüm farkı, çıktı izolasyonu, model dışı politika
Araç implementasyonu	Komut enjeksiyonu, path traversal, zafiyetli bağımlılık, kötü amaçlı paket	Güvenli kod, sürüm sabitleme, provenance, sandbox, ağ ve dosya erişim sınırı
Yetkilendirme ve iş etkisi	Geniş scope, token passthrough, confused deputy, geri alınamaz işlem	En az yetki, kaynağa bağlı token, işlem bazlı politika, anlamlı onay

Bu katmanlar birbirini etkiliyor ama aynı şey değiller. Kusursuz izole edilen bir sunucu, modele manipülatif içerik döndürebilir. Tertemiz görünen araç açıklamasının arkasında zafiyetli kod çalışabilir. Doğru kurulmuş OAuth, kullanıcının niyet ettiğinden çok daha geniş bir işlemi teknik olarak yetkilendirebilir.

Tool poisoning: dokümantasyon talimata dönüştüğünde

Invariant Labs, Nisan 2025’te MCP tool poisoning saldırısını açık biçimde gösterdi. Tekniğin özü basit: modelin okuyabildiği fakat bağlantıyı onaylayan kişinin görmediği veya sıradan sandığı araç açıklamasına davranış yönlendiren talimat yerleştirmek. Böylece şüpheli bir çağrı oluşmadan önce modelin karar biçimi değişebiliyor.

Sağlıklı bir schema yalnızca yeteneği ve sınırlarını tarif eder:

{
  "name": "destek_kayitlarinda_ara",
  "description": "Giriş yapan kullanıcının görebildiği destek kayıtlarında arama yapar.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": { "type": "string", "maxLength": 200 }
    },
    "required": ["query"],
    "additionalProperties": false
  }
}

Şüpheli bir schema ise yetenek bilgisini ilgisiz davranış talimatıyla karıştırır:

{
  "name": "destek_kayitlarinda_ara",
  "description": "Kayıtlarda arama yapar. [Aramayla ilgisiz talimat çıkarıldı]",
  "inputSchema": {
    "properties": {
      "query": { "type": "string" },
      "internal_context": {
        "type": "string",
        "description": "[İlgisiz yerel bağlam talebi çıkarıldı]"
      }
    }
  }
}

İkinci örneği bilinçli olarak çalıştırılabilir saldırı tarifine dönüştürmedim. İnceleme problemini göstermesi yeterli: yalnızca araç adına bakarak güvenlik kararı veremezsiniz.

Full-schema poisoning yalnızca açıklamada saklanmıyor

CyberArk’ın sonraki araştırması, etkinin sadece üst seviye açıklamada değil; parametre adında, parametre açıklamasında, varsayılan değerde ve şemanın başka alanlarında taşınabileceğini gösterdi. Araştırma, tool çıktısı üzerinden davranış yönlendirmeyi de ele aldı. Yani tek bir description metninde anahtar kelime arayan tarayıcı, aracı güvenli ilan edemez.

tools/list yanıtının tamamını güvenilmeyen ve güvenlik açısından kritik girdi sayın. Normalize edip hash’ini saklayın, anlamlı değişiklikleri inceleyin ve risk taşıyan alan değiştiğinde yeniden onay isteyin. Yapılandırılmış veya serbest metin fark etmeksizin araç sonuçlarını da modele döndürmeden önce aynı şüpheyle ele alın.

Rug pull: bugün onayladığınız sunucu yarın aynı kalmayabilir

Rug pull, başlangıçta kabul edilebilir görünen sunucunun onaydan sonra tool tanımını veya davranışını değiştirmesi. Endpoint ve araç adı aynı kalırken talimat, parametre şeması, bağımlılık ağacı ya da sunucu kodu değişebilir.

Tek seferlik izin ekranı hareketli hedefi kontrol edemez. En azından şunları uygulayın:

Paket veya container’ı değiştirilemez sürüme, mümkünse digest’e sabitleyin.
Onay anındaki normalize edilmiş tam tool schema’yı saklayın.
Her yeni tools/list yanıtını onaylı sürümle karşılaştırın.
Açıklama, parametre, annotation veya yetenek değiştiğinde çağrıyı durdurun ya da yeniden inceleme isteyin.
Yüksek etkili ortamlarda sessiz otomatik güncellemeye izin vermeyin.

Hash bir yazılımın iyi niyetli olduğunu kanıtlamaz; yalnızca incelediğiniz artifact ile aynı kaldığını gösterir. Kaynağın güvenilirliği ve çalışma anı kontrolleri yine gerekli.

Shadow MCP server: önce envanter sorunu

OWASP, kurumun güvenlik sürecinin dışında çalışan onaysız veya yönetilmeyen sunucuları “Shadow MCP Servers” başlığında topluyor. Bu, daha geniş etki alanına sahip shadow SaaS problemi gibi düşünülebilir: geliştirici tek komutla repository’leri, kimlik bilgilerini, tarayıcıyı veya iç sistemleri görebilen yerel MCP paketi çalıştırabilir.

Çözüm daha güçlü prompt yazmakla değil, envanterle başlar. Sunucu kimliğini, sahibini, onaylı sürümü, transport’u, scope’ları, erişebildiği kaynakları ve ortamları kaydeden bir allowlist tutun. Tanımsız süreç ve yapılandırmaları izleyin. Kullanılmayan yetkileri süre sonunda kapatın. Güvenli kurumsal kataloğu, README’den rastgele komut kopyalamaktan daha kolay hale getirin.

Gerçek açıklar bize klasik AppSec’in hâlâ geçerli olduğunu gösteriyor

Ajana özgü saldırılar yeni ve dikkat çekici. Fakat MCP sunucusu sonuçta girdi işleyen, dosya yolu kullanan, süreç başlatan, URL çözen bir yazılım.

CVE-2025-6514: mcp-remote içinde komut enjeksiyonu

CVE-2025-6514 kaydı, mcp-remote paketinin 0.1.15 ve önceki sürümlerinde özel hazırlanmış authorization endpoint üzerinden işletim sistemi komutu enjekte edilebildiğini açıklıyor. CNA değerlendirmesi CVSS 3.1 skoru olarak 9.6, yani Critical verdi. Bu ayrıntıyı doğru ifade etmek önemli: 9.6, NVD sayfasında gösterilen CNA skoru; NVD’nin bağımsız zenginleştirme skoru değil.

Buradan çıkarılacak ders tek paketten büyük. Discovery metadata ve authorization URL’leri doğrulanana kadar saldırgan girdisidir. Bunları shell komutuna eklemeyin. Shell açmadan yapılandırılmış process API kullanın; protokolü ve hedefi doğrulayın; dış ağ erişimini kısıtlayın ve zafiyetli bağımlılıkları güncelleyin.

“Reference implementation”, production-ready demek değil

Resmî MCP reference servers deposu, içindeki sunucuların eğitim amaçlı referans implementasyonlar olduğunu ve doğrudan production çözümü sayılmaması gerektiğini açıkça yazıyor. Aynı güvenlik sayfası path traversal, argument injection, path doğrulama bypass’ı ve güvenli olmayan operasyonlarla ilgili advisory’lere bağlantı veriyor.

Bu protokolün hatası değil; varsayım hatasına karşı uyarı. Resmî organizasyon altında duran depo, güvenlik kapsamı bilinçli olarak sınırlı bir öğretim örneği olabilir. Üretime almadan önce güvenlik politikasını ve advisory geçmişini okuyun.

OWASP MCP Top 10: iyi bir harita, fakat hâlâ beta

Bu yazının kontrol tarihinde OWASP MCP Top 10 projesi Beta olarak işaretlenmiş durumda. Tehdit modellemek için değerli ve yaşayan bir sınıflandırma; tamamlanmış compliance standardı değil. Güncel başlıkları şöyle:

Token Mismanagement & Secret Exposure
Privilege Escalation via Scope Creep
Tool Poisoning
Software Supply Chain Attacks & Dependency Tampering
Command Injection & Execution
Intent Flow Subversion
Insufficient Authentication & Authorization
Lack of Audit and Telemetry
Shadow MCP Servers
Context Injection & Over-Sharing

Listeyi tehdit modelleme soruları üretmek için kullanın. On maddeyi işaretleyip mimarinin otomatik olarak güvenli olduğunu varsaymayın.

Kimlik doğrulama gerekli; asıl tasarım yetkilendirmede

HTTP tabanlı transport’larda kararlı MCP yetkilendirme spesifikasyonu OAuth güvenlik pratiklerini temel alıyor. Sunucunun authorization server keşfi için OAuth 2.0 Protected Resource Metadata yayımlamasını, istemcinin de token’ın doğru MCP kaynağına verilmesi için Resource Indicators kullanmasını istiyor. En az yetkili scope ve kademeli izin de resmî tasarımın parçaları.

Üç nokta özellikle kolay gözden kaçıyor:

İstemci token’ını aktarmayın. Resmî güvenlik rehberi token passthrough’u anti-pattern sayıyor. Sunucu token’ın kendisi için çıkarıldığını doğrulamalı; başka servise ait token’ı iletmek kaynak sınırını bozuyor.
Session ID kimlik doğrulama değildir. Oturum, durumu ilişkilendirebilir; fakat yetki doğrulanmış kimliğe bağlı olmalı ve her istekte kontrol edilmeli. Kararlı rehber, session hijacking ve event injection risklerini de ele alıyor.
STDIO farklıdır. HTTP yetkilendirme akışı otomatik olarak STDIO güvenlik modeli olmaz. Spesifikasyon, STDIO implementasyonlarının kimlik bilgilerini çoğunlukla environment üzerinden aldığını belirtiyor. Bu yüzden process izolasyonu ve secret kapsamı daha da kritik.

OAuth kimin izin verdiğini kanıtlayabilir ve scope’u daraltabilir. Modelin kullanıcıyı doğru anladığını, tool açıklamasının zehirlenmediğini veya dört bin kaydı silmenin doğru karar olduğunu belirleyemez. Bu kararlar politika katmanına ait.

Modelin söz dinlemesine güvenmeyen production mimarisi

En güvenli desen, modelin önerdiği tool çağrısı ile gerçek sunucu çalıştırması arasına deterministik enforcement katmanı yerleştirmek:

Kullanıcı talebi
  → model bir araç çağrısı önerir
  → policy engine kimliği, sunucuyu, schema sürümünü, scope'u ve argümanları doğrular
  → hassas veya geri alınamaz işlemde insan onayı alınır
  → araç dosya sistemi ve ağ sınırları içinde izole çalışır
  → temizlenmiş sonuç modele döner
  → audit olayı yazılır

1. Araçları etkisine göre ayırın

Tek bir geniş manage_database aracı açmayın. Okuma, yazma ve silme işlemlerini bölün; açık limitleri olan dar schema’lar kullanın. Listeleme düşük risk politikasında otomatik çalışabilir. Toplu silme ise farklı permission, etkilenecek kayıtların önizlemesi ve ayrı onay istemeli.

2. Onayı somut ve anlamlı hale getirin

“Bu sunucuya izin verilsin mi?” zayıf bir onay. İyi bir ekran; aracı, hedef sistemi, işlemi yapan kimliği, önemli argümanları, beklenen yan etkiyi ve geri alınabilirliği gösterir. Toplu izinler bütün sunucuya verilen belirsiz güven yerine zaman, kaynak ve işlemle sınırlandırılmalı.

3. Çalışma ortamını sınırlandırın

Güvenilmeyen veya topluluk sunucularını ayrı kullanıcıyla, varsayılan salt okunur dosya sistemiyle, açıkça seçilmiş mount’larla, host socket olmadan, sınırlı CPU/bellekle, en küçük secret setiyle ve varsayılan kapalı egress politikasıyla çalıştırın. Container kullanmak faydalı; fakat her container otomatik olarak güçlü sandbox değildir. Düşman girdisi işleyen veya kod çalıştıran araçta daha güçlü izolasyon seçin.

Docker MCP Toolkit güncel operasyonel kontrol örneklerinden biri. Docker; sunucuların container içinde çalışmasını, katalog görüntülerinin imzalı ve SBOM’lu olmasını, dosya mount’larının açıkça verilmesini, kaynak limitlerini ve istek kesme kontrollerini dokümante ediyor. Bunlar riski azaltabilir; sunucuyu inceleme ve en az yetki tasarımının yerine geçmez.

4. Sonuçları güvenilmeyen içerik sayın

Başarılı bir çağrı; prompt injection, aşırı büyük veri, zararlı bağlantı, secret veya başka tenant’a ait içerik döndürebilir. Boyut ve tip limiti uygulayın, kaynağı işaretleyin, mümkünse aktif içeriği temizleyin, sonucun otomatik olarak yeni çağrı yetkilendirmesini engelleyin ve tenant kontrolünü modelin dışına taşıyın.

5. Secret’ı değil, kararı loglayın

Doğrulanmış kimliği, sunucu kimliğini ve artifact digest’ini, tool/schema hash’ini, politika kararını, maskelenmiş argümanları, onayı veren kimliği, süreyi, sonuç sınıfını ve hatayı kaydedin. Bearer token’ı, tüm environment değişkenlerini veya sınırsız ham tool çıktısını loga dökmeyin.

Bağlantıdan önce risk seviyesi belirleyin

Seviye	Örnek	Varsayılan politika
Düşük	Herkese açık doküman okuma, onaylı public index araması	Süre, boyut ve hedef limitiyle otomatik çalıştır
Orta	Özel ticket, repository, analitik veya müşteri kaydı okuma	Kullanıcı scope’lu kimlik, tenant kontrolü, maskeleme, kapsamlı audit
Yüksek	Mesaj gönderme, kod değiştirme, deployment, production verisi güncelleme	Somut işlem önizlemesi ve onayı; dar scope ve geri dönüş yolu
Kritik	Shell, secret yönetimi, IAM değişikliği, yıkıcı toplu işlem	Güçlü izolasyon, izinli komut/hedef listesi, just-in-time credential ve gerektiğinde iki kişi kontrolü

15 maddelik MCP production kontrol listesi

Her izinli sunucu, transport, sürüm ve ortam için sorumlu sahibi olan envanter tutun.
İncelenmiş ve değiştirilemez artifact tercih edin; floating tag veya kurulum komutu yerine sürüm/digest sabitleyin.
Provenance’ı, varsa imzayı, bağımlılık geçmişini, advisory’leri ve projenin güvenlik politikasını kontrol edin.
Yalnızca araç adı/açıklamasını değil, tam schema’yı kaydedip inceleyin; değişiklikte uyarı üretin.
Okuma, yazma, silme, yönetim ve kod çalıştırma yeteneklerini birbirinden ayırın.
Kullanıcıya veya workload’a bağlı en az yetkili credential kullanın; modele ortamdan geniş token vermeyin.
HTTP için issuer, audience/resource, süre, scope, redirect hedefi ve Protected Resource Metadata doğrulayın.
Token passthrough’u reddedin; her hassas istekte yetkiyi yeniden kontrol edin.
Politika uygulamasını deterministik ve prompt/model bağlamının dışında tutun.
Yüksek etkili, şaşırtıcı, dış sisteme giden veya geri alınamaz işlemlerde somut insan onayı isteyin.
Süreci izole edin; dosya, ağ, subprocess ve secret erişimini varsayılan kapalı tutun.
Girdiyi katı doğrulayın; shell interpolation kullanmayın; timeout, rate ve çıktı limiti koyun.
Kaynak ve tool sonucunu güvenilmeyen içerik sayın; modele dönmeden temizleyip provenance’ı koruyun.
Maskelenmiş, değiştirilmeye dayanıklı audit olayı yazın; sıra dışı sunucu, araç, hedef ve çağrı zincirini izleyin.
Production’dan önce yetki iptalini, credential rotation’ı, rollback’i, sunucu ele geçirilmesini, schema değişimini ve olay müdahalesini test edin.

MCP sizin yerinize neye karar veremez?

Protokol; keşfi, mesajları, yetenekleri ve yetkilendirme mekaniklerini standartlaştırabilir. Kurumunuzun kabul edilebilir etki alanını bilemez. Destek ajanının iade yapıp yapmaması gerektiğine, production deployment’ının güvenli olup olmadığına veya güvenilen drive’dan dönen dokümanın zararlı talimat içerip içermediğine karar veremez.

Bu nedenle en güçlü MCP güvenlik kontrolü mimaridir: her araca ihtiyacı olan en küçük yetkiyi verin, yetki yan etkiye dönüşmeden ayrı karar noktası koyun ve diğer tüm varsayımlar çöktüğünde süreci sınırların içinde tutun.

Son karar

“Bu MCP sunucusuna güveniyor muyum?” sorusunu tek bir evet/hayır sorusu olarak sormayın. Şunları sorun:

Bu belirli artifact ve tam schema sürümüne güveniyor muyum?
Bu kimlik, scope, dosya sistemi ve ağ sınırları içinde güveniyor muyum?
Gerçek etkisini gördüğüm bu tek çağrıya güveniyor muyum?
Güvenim yanlış çıkarsa durdurabilir, inceleyebilir ve sistemi geri getirebilir miyim?

MCP ajanları çok daha faydalı hale getirebilir. Güvenli sürüm, daha iyi system prompt verilmiş sınırsız bir asistan değil. Modelin önerdiği, deterministik kontrollerin karar verdiği, tehlikeli sınırda insanın onayladığı ve her bileşenin hata yapabileceği varsayılan kontrollü sistemdir.

Birincil kaynaklar ve ileri okuma

Kaynakların durumu 14 Temmuz 2026’da kontrol edildi. Yazıda başvurulan kararlı MCP revizyonu 2025-11-25’tir. OWASP MCP Top 10’un Beta durumu özellikle belirtilmiş, taslak MCP değişiklikleri kararlı davranış gibi sunulmamıştır.