Kod değil, metin: MCP araç açıklamaları ve wildcard scope'lar ajanları injection'a açık bırakıyor

Saldırı yüzeyi, modelin okuduğu metin

dev.to'da yayımlanan iki yazı, Model Context Protocol kurulumlarında en gözden kaçan riskin kötü niyetli kod değil, modelin bir aracı çağırmadan önce okuduğu metin olduğunu savunuyor. İlk yazı, tool description injection adını verdiği saldırıyı tanımlıyor: bu saldırı için bir güvenlik açığı, kötü bir bağımlılık ya da supply-chain ihlali gerekmiyor; yalnızca modelin okuyup güvendiği bir metin alanı yeterli.

Bir MCP araç tanımı büyük ölçüde JSON'dan oluşur: bir isim, bir açıklama ve kendi açıklamalarını taşıyan özelliklere sahip bir input schema. Tüm bu metin, model hangi aracı hangi argümanlarla çağıracağına karar vermeden önce ona bağlam olarak ulaşır. Yazının örneği, açıklaması meşru görünen ama modele önceki talimatları yok saymasını ve konuşmada bulunan herhangi bir credential'ı bir notes alanına geçirmesini söyleyen bir hava durumu aracı. Araç yine de hava durumunu getiriyor, dolayısıyla çalışma zamanında ne yürüttüğünü denetleyen bir audit hiçbir sorun bulamıyor. Injection, tamamen modelin talimat olarak gördüğü metnin içinde yaşıyor.

Payload'lar nereye gizlenir

Üst düzey description alanı tarayıcıların çoğunun kontrol ettiği yerdir, ancak yazıya göre aynı payload, input schema özelliklerinin açıklamaları ve başlıklarında, enum değer etiketlerinde ve metnin araç seçimi için kullanılan prompt'a birleştirildiği her yerde işe yarıyor. Yalnızca üst düzey alanı okuyan bir tarama, modele kullanıcının ne istediğinden bağımsız olarak bir flag'i her zaman true yapmasını söyleyen bir özellik açıklamasını kaçırır.

Yazı ayrıca manifest'in insan gözüyle taranmasından sağ kurtulacak şekilde tasarlanmış encoding hilelerine de dikkat çekiyor: editörde veya mcp'nin hızlı bir okumasında hiç görünmeyen ama modelin yine de tokenize ettiği zero-width ve Unicode tag-block karakterleri; model tüm string'i okuduğu halde bir diff içinde payload'u görsel olarak geri plana iten HTML yorumları; otomatik olarak kötücül olmayan ama ikinci bir bakışı hak eden base64 benzeri blob'lar.

Belirtilen başarısızlık modu, kimsenin manifest'leri incelememesi değil; config incelemesinin hangi sunucuların ve scope'ların tanımlandığını kontrol etmesi, her açıklama string'inin ne dediğini ve elbette görünmez karakterler içerip içermediğini kontrol etmemesidir.

Wildcard scope'lar etki alanını genişletiyor

Yoldaş dev.to yazısı ise izin tarafını hedefliyor: mcp dosyaları çoğu zaman admin:* veya full_access gibi scope'larla sonuçlanıyor; bunun nedeni kimsenin bilinçli olarak geniş admin yetkileri seçmesi değil, sunucunun README'sinin wildcard'ı hızlı yol olarak göstermesi ve enumerate edilmiş alternatifin belgelenmemiş olması.

Yazı, admin:* ile tanımlanmış bir dahili CRM sunucusunu contacts:read, contacts:write ve notes:read olarak enumerate edilmiş bir sunucuyla karşılaştırıyor. Sunucu yalnızca üç endpoint'e dokunuyorsa ikisi de aynı etkili erişimi verebilir, ancak enumerate edilmiş versiyon daha sonra yapılacak herhangi bir incelemeye o endpoint'lerin tam olarak hangileri olduğunu söyler. Wildcard, biri sunucunun kaynak kodunu okuyana veya bir şey ters gidene kadar hiçbir şey ortaya koymaz.

Yazıya göre asıl sorun, aylar sonra, ikinci bir ilgisiz MCP sunucusu (örneğin rastgele web içeriği okuyan biri) aynı ajan oturumuna katıldığında ortaya çıkar. Taraflardan biri kapsamlı bir wildcard olduğunda bu eşleşmenin anlamlı olup olmadığına karar vermek zordur ve baştan dar bir şekilde kayıt tutulmadıysa scope creep'i geriye dönük denetlemek neredeyse imkânsızdır.

Statik kontroller neler yapabilir, neler yapamaz

Her iki yazı da yazarın herhangi bir ağ çağrısı yapmayan yalnızca manifest'e odaklanan tarayıcısı sentinel-scan-cli'ya işaret ediyor. Bu araç, açıklamalarda ve schema başlıklarında emredici-override dili, güvenilir-talimat çerçevelemesi, görünmez Unicode, HTML yorumları ve şüpheli base64 blob'ları tespit edip bulguları OWASP LLM01'e eşleştiriyor; bunun yanı sıra wildcard scope'lar, args içindeki sabit kodlanmış credential'lar, düz metin remote transport'lar ve eksik provenance metadata'sı için kontroller sunuyor.

Yazılar sınırlar konusunda açık sözlü. Pattern matching, kimsenin daha önce görmediği bir şekilde ifade edilmiş bir payload'u yakalayamaz ve statik bir scope kontrolü, bir wildcard'ın API düzeyinde ne çözüldüğünü söyleyemez ya da scope'unu eksik bildiren ama kodda yetkisini aşan bir sunucuyu yakalayamaz. Çözüm tarafında, scope yazısı scoped permission'ları destekleyen sunucuların çoğunun enumerate edilmiş izinleri de desteklediğini, wildcard'ın basitçe README'deki daha kısa örnek olma eğiliminde olduğunu ve enumerate etmenin yaklaşık beş dakikalık bir sunucu araç listesi okuma maliyeti olduğunu belirtiyor.

Neden önemli

Ajan güvenliği çabası, araçların çalışma zamanında ne yürüttüğüne odaklanma eğiliminde. Bu iki yazı ise daha yüksek frekanslı hataların metinsel olduğunu savunuyor: modeli yönlendiren açıklamalar ve bir aracın neye dokunabileceğini gizleyen scope'lar. İkisi de yetenek denetimlerine ve özensiz config incelemesine görünmezdir ve ikisi de daha fazla sunucu tek bir ajan oturumunu paylaştıkça birikir. Wildcard scope'lar ve incelenmemiş açıklama metinleri ekosistemin varsayılan yolu olmaya devam ederse, least-privilege enumeration ve manifest taraması, ajanları gerçek sistemlere bağlayan herkes için temel bir hijyen haline gelir.