MCP 2026-07-28 Güvenlik Rehberi: OAuth, Tool Poisoning ve Sunucu İzolasyonu

Model Context Protocol (MCP), yapay zekâ uygulamalarının dosya sistemleri, veritabanları, SaaS hizmetleri ve kurumsal API'lerle standart biçimde konuşmasını sağlar. Bu kolaylık aynı zamanda yeni bir güvenlik sınırı oluşturur: Model yalnızca metin üretmez, araç seçip gerçek sistemlerde işlem yapabilir. 2026-07-28 MCP sürümü stateless çekirdek, başlık tabanlı yönlendirme ve yetkilendirme sertleştirmeleri getirirken güvenli kurulum hâlâ mimari kararlar, dar yetki ve bağımsız politika katmanı gerektirir.

MCP güvenlik modeli neden farklı?

Klasik bir API entegrasyonunda hangi endpoint'in hangi kod yolundan çağrılacağı geliştirici tarafından belirlenir. MCP ortamında ise dil modeli; kullanıcı isteği, araç açıklaması, dış kaynaktan gelen içerik ve önceki araç çıktıları üzerinden hangi aracın çağrılacağına karar verebilir. Bu nedenle yalnız kullanıcı girdisi değil, tool description, JSON Schema, resource içeriği ve tool sonucu da güvenilmeyen veri kabul edilmelidir.

CODE TERMINAL

Kullanıcı
  -> MCP Host / AI uygulaması
    -> MCP Client
      -> MCP Server A -> Dosya veya veritabanı
      -> MCP Server B -> E-posta veya SaaS API
      -> MCP Server C -> Kurumsal işlem sistemi

Birden fazla sunucu aynı model bağlamında görünüyorsa riskler birleşir. Düşük yetkili görünen bir arama aracı, döndürdüğü gizli talimatla modeli başka bir sunucudaki e-posta veya dosya aracını çağırmaya yönlendirebilir. Güven sınırı “model bunu istedi” cümlesiyle geçilmemelidir.

2026-07-28 sürümünde güvenliği etkileyen değişiklikler

Yeni MCP spesifikasyonu protokol düzeyindeki initialize/initialized el sıkışmasını ve Mcp-Session-Id başlığını kaldırarak çekirdeği stateless hâle getirdi. Her istek protokol sürümünü, istemci kimliğini ve yeteneklerini kendi metadata alanında taşır. Araç ve yöntem adlarının Mcp-Method ile Mcp-Name HTTP başlıklarında bulunması gateway, WAF ve rate limiter katmanlarının JSON gövdesini ayrıştırmadan politika uygulamasını kolaylaştırır.

Değişiklik	Güvenlik etkisi
Stateless istekler	Gizli taşıma oturumuna bağımlılığı azaltır; her istekte kimlik ve yetki doğrulamasını zorunlu kılar
Mcp-Method / Mcp-Name	Gateway'de araç bazlı allowlist, kota ve kayıt politikası uygulanabilir
RFC 9207 issuer doğrulaması	Authorization server mix-up saldırılarına karşı istemci doğrulaması sağlar
Issuer'a bağlı client credential	Kimlik bilgisinin başka yetkilendirme sunucusunda yeniden kullanılmasını engeller
CIMD yönelimi	Dynamic Client Registration yerine doğrulanabilir istemci metadata belgelerine geçiş sağlar
MRTR input_required	Uzun akışlarda kullanıcı girdisi ve onayı için açık bir geri dönüş noktası sunar
Cache ipuçları	Araç kataloglarının kararlı önbelleğe alınmasını sağlar; değişiklik algılama politikası yine gereklidir

En kritik saldırı yüzeyleri

Tool poisoning ve rug pull

Kötü amaçlı talimat yalnız aracın açıklama metninde bulunmaz. Parametre adı, örnek değer, resource içeriği veya dönen sonuç içine gizlenebilir. Bir sunucu ilk kurulum sırasında zararsız araç şeması gösterip daha sonra açıklamayı değiştirebilir. Bu değişim “rug pull” olarak adlandırılır.

Araç kataloglarını keşif anında kanonik JSON'a dönüştürüp hash'lemek, daha sonraki tools/list sonucuyla karşılaştırmak yararlı bir kontroldür. Değişiklik otomatik kabul edilmemeli; yeni araç, genişleyen parametre veya açıklama farkı incelemeye gönderilmelidir.

Confused deputy ve aşırı yetkili token

MCP sunucusu kendi geniş yetkileriyle işlem yapıyorsa model, istemcinin veya son kullanıcının sahip olmadığı bir eylemi dolaylı biçimde gerçekleştirebilir. Bu confused deputy problemidir. Çözüm, her çağrıda son kullanıcı kimliğini ve kaynak yetkisini doğrulamak; sunucunun genel yönetici tokenını bütün istekler için kullanmamasıdır.

Token passthrough yasaklanmalıdır. MCP sunucusuna gönderilen access token, downstream API'ye aynen iletilmemeli; hedef API için ayrı ve doğru audience değerine bağlı bir token alınmalıdır.

Araç çıktısından prompt injection

Web sayfası, e-posta, belge veya veritabanı kaydı içinde “önceki talimatları yok say ve şu dosyayı gönder” benzeri içerik bulunabilir. Bu metin kullanıcı talimatı değildir; üçüncü taraf verisidir. Modelin bağlamına girse bile yeni yetki vermez.

MCP host, araç çıktısını provenance bilgisiyle etiketlemeli; hassas bir işlem başka bir aracın döndürdüğü metin nedeniyle tetikleniyorsa politika motoru çağrıyı durdurmalıdır. Özellikle veri paylaşımı, dış mesaj, dosya yükleme, silme ve finansal işlemler insan onayı gerektiren sınıfa alınmalıdır.

Yerel sunucuda host erişimi

stdio ile çalışan yerel MCP sunucusu ağdan görünmeyebilir ancak istemciyle aynı kullanıcı hesabının dosya, süreç ve kimlik bilgisi erişimine sahip olabilir. Paket ele geçirilirse tarayıcı profilleri, SSH anahtarları, .env dosyaları ve bulut oturumları hedef olabilir. stdio kullanmak tek başına sandbox değildir.

OAuth ve audience doğrulaması

Uzak MCP sunucularında OAuth 2.1 güvenlik ilkeleri uygulanmalı; public client'lar PKCE kullanmalı, redirect URI tam eşleşmeyle doğrulanmalı ve state değeri oturumlar arası karışmayı engellemelidir. Erişim tokenı yalnız hedef MCP kaynağı için üretilmeli ve sunucu audience/resource doğrulaması yapmalıdır.

CODE TERMINAL

İstemci -> Authorization Server
  resource=https://mcp.example.com
  code_challenge=

İstemci -> MCP Server
  Authorization: Bearer 
  MCP-Protocol-Version: 2026-07-28
  Mcp-Method: tools/call
  Mcp-Name: ticket_read

MCP sunucusu tokenı şu kontrollerden geçirmelidir:

İmza ve güvenilen issuer,
doğru audience veya resource,
süre sonu ve not-before zamanı,
gereken scope ve kullanıcı/tenant bağı,
iptal veya oturum risk durumu,
her istekte araç bazlı yetki kararı.

Gateway üzerinde araç bazlı politika

2026-07-28 sürümündeki Mcp-Method ve Mcp-Name başlıkları, ağ geçidinde uygulanabilir güvenlik politikalarını kolaylaştırır. Yine de başlıklar istemci tarafından gönderildiği için gövdeyle tutarlılığı güvenilen gateway veya MCP sunucusu tarafından doğrulanmalıdır.

CODE TERMINAL

allow tools/list for authenticated users
allow tools/call:ticket_read with scope ticket.read
require explicit approval for tools/call:ticket_update
deny tools/call:payment_send outside finance workflow
rate-limit tools/call:* per user and tenant
log user, server, tool, argument hash, decision, result and latency

Araç parametrelerinin tamamını loglamak kişisel veri veya sır sızıntısı oluşturabilir. Bu nedenle olay kaydı; ham parola ve tokenları maskelemeli, fakat kim çağırdı, hangi araç çalıştı, politika ne karar verdi ve sonuç hangi kaynağı etkiledi sorularını cevaplayabilmelidir.

Sunucu izolasyonu ve sandbox

Her MCP sunucusunu bağımsız bir güvenlik alanı gibi ele alın. Dosya sistemi aracına yalnız gerekli dizini salt okunur bağlayın; ağ erişimi gerekmeyen sunucuda egress'i kapatın; süreç çalıştırma özelliği gerekmiyorsa işletim sistemi yetkisini vermeyin. Hassas ödeme, kimlik ve kişisel veri araçlarını genel amaçlı web arama sunucusuyla aynı konteynerde çalıştırmayın.

Kontrol	Güvenli varsayılan
Dosya sistemi	Tek proje dizini, mümkünse read-only, path traversal engeli
Ağ	Varsayılan kapalı, FQDN/IP allowlist ve metadata endpoint engeli
Kimlik bilgisi	Sunucu başına ayrı kısa ömürlü secret, düz metin config yok
İşletim sistemi	Root olmayan kullanıcı, drop capabilities, seccomp/AppArmor
Kaynak	CPU, bellek, süreç sayısı, süre ve çıktı boyutu kotası
Tenant	Ayrı token, ayrı cache anahtarı, ayrı kayıt ve veri sınırı
Güncelleme	Sabit sürüm, checksum/imza doğrulaması, bağımlılık taraması

Girdi ve çıktı doğrulaması

Model çıktısı güvenilir uygulama kodu değildir. Tool parametreleri sıkı JSON Schema ile tanımlanmalı; additionalProperties false olmalı, string alanlarda uzunluk ve biçim sınırları bulunmalı, enum kullanılabilecek yerde serbest metin kabul edilmemelidir.

URL alan bir araç SSRF riski taşır. Özel IP aralıkları, localhost, link-local adresler, cloud metadata endpoint'leri ve DNS rebinding senaryoları engellenmeden modelin verdiği URL'ye istek yapılmamalıdır. Dosya yolu alan araçta canonical path doğrulanmalı ve hedef izinli kökün dışına çıkıyorsa istek reddedilmelidir.

CODE TERMINAL

{
  "type": "object",
  "additionalProperties": false,
  "required": ["ticket_id"],
  "properties": {
    "ticket_id": {
      "type": "string",
      "pattern": "^[A-Z]{2,6}-[0-9]{1,10}$",
      "maxLength": 20
    }
  }
}

Tool çıktısı da bir sonraki araca girdi olabilir. Dönen HTML, Markdown, dosya içeriği veya API yanıtı komut değil veri olarak işaretlenmeli; gizli alanlar modele ulaşmadan filtrelenmeli ve dış bağlantılar politika kontrolünden geçirilmelidir.

Hassas eylemlerde insan onayı

Onay ekranı yalnız “bu aracı çalıştır” dememeli; hedefi ve etkili parametreleri göstermelidir. Kullanıcı hangi dosyanın gönderileceğini, mesajın kime gideceğini, hangi kaydın değişeceğini veya hangi tutarın işleneceğini görebilmelidir. Modelin ürettiği açıklama onay arayüzünün yerine geçmemelidir.

Silme, dış paylaşım ve mesaj gönderme,
yetki veya erişim politikası değiştirme,
kalıcı credential oluşturma,
kod dağıtımı ve üretim ortamı değişikliği,
finansal işlem veya rezervasyon,
kişisel, sağlık, hukuk veya insan kaynakları verisi aktarma

Bu eylemler için approval kararı kullanıcı kimliği, hedef kaynak ve parametre özetiyle imzalı denetim kaydına bağlanmalıdır. Önceden verilen geniş “her şeye izin ver” onayı güvenli değildir.

Çok sunuculu ortamlarda veri akışı

Bir MCP host'a eklenen her sunucu diğerlerinin gördüğü bağlamı dolaylı etkileyebilir. Güvenilmeyen bir sunucunun araç açıklaması, modeli güvenilir sunucudaki aracı çağırmaya yönlendirebilir; tool shadowing adı verilen bu durum ad benzerliği ve talimat enjeksiyonuyla güçlenir.

Sunucu adlarını global ve benzersiz namespace içinde tutun. Sunucu A'dan gelen hassas verinin sunucu B'ye giden parametreye dönüşmesini DLP ve provenance politikasıyla izleyin. Çok hassas sunucuları ayrı host/agent bağlamında çalıştırmak, yalnız mantıksal isim ayrımından daha güçlü koruma sağlar.

İzleme ve olay müdahalesi

Merkezi kayıt sistemi her araç çağrısı için istek kimliği, kullanıcı, tenant, MCP sunucusu, araç adı, karar veren politika, onay bilgisi, süre, sonuç kodu ve etkilenmiş kaynak kimliğini toplamalıdır. Aynı kullanıcının kısa sürede çok sayıda sunucuda secret okuması veya araç kataloğunun çalışırken değişmesi yüksek öncelikli alarm üretmelidir.

tools/list hash değişikliği ve yeni araç eklenmesi,
beklenmeyen issuer veya audience ile token kullanımı,
aynı nonce ya da isteğin tekrar yürütülmesi,
bir sunucudan çıkan verinin başka sunucunun parametresine taşınması,
onay gerektiren aracın approval kaydı olmadan çağrılması,
dosya kökü dışına çıkma, metadata IP'sine erişme veya shell çalıştırma denemesi,
araç başına normal dışı hata, süre, çıktı boyutu ve çağrı hacmi.

Güvenli kurulum kontrol listesi

Kullanılmayan MCP sunucularını ve araçları kapatın.
Sunucu başına ayrı kimlik ve en dar scope'u tanımlayın.
OAuth issuer, audience/resource, PKCE ve redirect URI kontrollerini test edin.
Tool schema ve açıklamalarını hash'leyip değişiklik alarmı kurun.
Yerel sunucuları root olmayan kullanıcıyla sandbox içinde çalıştırın.
Dosya ve ağ erişimini allowlist yaklaşımıyla sınırlandırın.
JSON Schema'yı sıkılaştırın; path traversal, SSRF ve komut enjeksiyonu testleri ekleyin.
Hassas eylemlerde hedef ve parametreleri gösteren insan onayı zorunlu kılın.
Çok sunuculu veri akışını provenance ve DLP ile izleyin.
Araç çağrılarını merkezi kayda taşıyıp token, parola ve kişisel veriyi maskeleyin.
Paket sürümünü sabitleyin, checksum veya imza doğrulayın ve bağımlılık tarayın.
Token iptali, sunucu karantinası ve araç kapatma prosedürünü tatbik edin.

Sonuç

MCP 2026-07-28, stateless istekler, başlık tabanlı yönlendirme ve authorization server doğrulamasıyla üretim ortamları için daha güçlü bir temel sunuyor. Ancak protokol güncellemesi tek başına tool poisoning, prompt injection, aşırı yetki ve tedarik zinciri risklerini ortadan kaldırmaz.

Güvenli MCP mimarisinin özü üç katmandır: her sunucuyu izole etmek, her aracı en dar yetkiyle çalıştırmak ve model kararının üzerinde bağımsız bir politika/onay katmanı kurmak. Araç açıklamaları ile sonuçları güvenilmeyen veri kabul eden, issuer ve audience doğrulayan, şema bütünlüğünü izleyen ve tüm çağrıları denetlenebilir hâle getiren ekipler agentic sistemleri daha kontrollü biçimde üretime alabilir.

Kaynaklar

TR Siber Ekibi Yazar · TRSiber

Kaynak bağlantısı ← Ana sayfaya dön