· kaynak dev.to (home feed)
MCP'nin 2026-07-28 revizyonu stateless oldu: yerleştirilen prompt'lar yeniden kullanılabilir kimlik bilgilerine dönüşüyor
Temmuz 2026 MCP revizyonu oturumları ve initialize el sıkışmasını kaldırıyor; böylece protokol durumu artık modelin context window'unda dizeler olarak taşınıyor ve prompt injection burada çalışan kimlik bilgileri ekebilir ya da çalabilir.

Oturumsuz bir protokol
Model Context Protocol'ün 2026-07-28 revizyonu, initialize el sıkışmasını ve Mcp-Session-Id başlığını kaldırıyor; bu ikisi daha önce her çağrıyı tek bir sunucu sürecine sabitleyen mekanizmalardı. Bir MCP sunucu yazarının dev.to analizine göre, SEP-2575 ve SEP-2567 spec önerileriyle gelen bu değişiklik, herhangi bir isteğin düz bir round-robin load balancer arkasındaki herhangi bir örneğe düşebileceği anlamına geliyor; ne sticky session var ne de paylaşılan oturum deposu. Stateless bir MCP sunucusu artık diğer her HTTP iş yükü gibi davranıyor: serverless fonksiyonlar, auto-scaling ve round-robin dağıtım, örnekler arası koordinasyon olmadan çalışıyor.
Eskiden bağlantı başına bir kez paylaşılan metadata — protokol sürümü, istemci kimliği, yetenekler — artık her istekte bir _meta bloğu içinde seyahat ediyor. Araç listeleri de ttlMs ve cacheScope ipuçlarıyla açıkça önbelleklenebilir hale geldi. Yazar bir yan etkiye dikkat çekiyor: zehirlenmiş veya bayat bir araç kataloğu artık daha geniş bir etki alanına sahip, çünkü her istemci ve aracı, eski modelin bağlantı başına listeleri yerine aynı önbelleklenmiş kopyayı paylaşıyor olabilir.
Handle'lar yeni kimlik bilgileri
Çağrılar arasında gerçekten durum gerektiren sunucular için spec'in çözümü explicit-handle deseni: bir araç çağrısı bir handle üretir ve model bu dizeyi sonraki çağrılarda sıradan bir argüman olarak geri geçirir. Resmi çerçeve bunu bir özellik olarak sunuyor — durum modele görünür oluyor, loglarda denetlenebilir hale geliyor ve transport metadata'sından daha kolay debug ediliyor.
VentureBeat'in 5 Eylül tarihli haberinde netleştirdiği sonuç şudur: bir saldırganın yerleştirdiği bir prompt artık çalınmış bir kimlik bilgisinin işini yapabilir. Saldırganın artık sunucuyu, bir token kasasını veya transport'ı ele geçirmesi gerekmiyor. Modelin güvendiği bir context window'a bir dize yerleştirmesi ve sonra modelin bunu geri vermesini sağlaması yeterli. Her endpoint, bir handle'ın neyi yetkilendirdiğine karar veriyor ve dev.to yazarının belirttiği gibi, çoğu sunucudaki varsayılan davranış, doğru öneki taşıyan herhangi bir dizeyi kabul etmek olacak.
İstismarın üç yolu
İlki retrieval. Bir agent bir Jira ticket'ını, bir GitHub issue'sunu veya bir web sayfasını bir araç üzerinden okuyor ve bu içerik, düz token olarak dönen saldırgan kontrollü metin oluyor. Önceki meşru bir çağrıdan gelen bir handle hâlâ context window'da duruyorsa, enjekte edilmiş metin ona adıyla atıfta bulunabilir ve modeli onu yeniden oynatmaya yönlendirebilir.
İkincisi araç çıktısı. Getirilen metni birebir döndüren okuma tarzı bir araç — yazarın çoğu okuma yönelimli MCP aracı için böyle dediği tür — aynı yanıt içinde bir handle ve bir talimat teslim edebilir. Bu payload'ın içinde system prompt ya da API anahtarı yok; bu, agent'ın çağırması söylenen bir araçtan gelen, hem bir kimlik bilgisini hem de onu kullanma talimatını içeren bir dizedir.
Üçüncüsü bu sürümde yeni. 2026-07-28 revizyonu ayrıca MCP Apps'i resmileştiriyor; burada bir sunucu, istemcinin IDE veya agent penceresi içinde sandbox'lı bir iframe'de görüntülediği HTML'i render ediyor. VentureBeat'in analizine göre, stored XSS artık AI istemcilerinde render edilen HTML'de görünebilir; terminallerin, dosya sistemlerinin ve bağlı diğer her MCP sunucusunun üzerinde konumlanmış olarak. Sandbox'lı bir iframe tarayıcı istismarını içerir ama agent'ı içermez — ki agent onun yanıında, onu başlatan kişinin kimlik bilgileriyle çalışıyor.
Uygulama endpoint'e taşındı
Protokol güvenliği zorunlu kılmıyor ve dev.to analizi, revizyonun şimdi başlamama konusunda açık olduğunu vurguluyor. Zorunlu kılma gateway'lere ve endpoint'lere kaydı ve istek başına hale geldi: her çağrı incelenmeli, yalnızca oturumun başı değil. Sürümün OAuth-native yetkilendirme çalışması sunucu başına token üretiyor ve onları bir audience'a bağlıyor; böylece bir sunucu için verilen bir token başka birine karşı yeniden oynatılmamalı — ve bu doğrulamayı yapmak protokolün değil, sunucunun işi.
Bu artık varsayımsal değil, üretimde. VentureBeat, dört Tier 1 SDK'nın tamamının ilk günün sonunda yeni sürümü konuştuğunu, Cloudflare'in Agents SDK'sının ilk günden itibaren desteklediğini, Sentry ve Linear'ın ise çoktan üzerinde olduğunu bildiriyor. AWS Architecture Blog 1 Eylül'de sütun sütun bir inceleme yayınladı ve on iki aylık bir deprecation politikası, değişiklikleri en azından 2027 ortasına kadar kilitliyor. Dev.to yazarının temel uyarısı şu: yeni yüzeyi çalıştıran çoğu sunucu, istek başına handle doğrulaması eklemedi, çünkü desen yepyeni ve SDK'lardaki hiçbir şey bunu onlar için uygulamıyor.
Neden önemli
Stateless yeniden tasarım, gerçek bir operasyonel sorunu — sticky altyapı olmadan yatay ölçekleme — çözerken protokol durumunu, prompt injection'ın zaten hâkim olduğu tek yere, modelin context window'una taşıyor. Bu, getirilen her ticket'ı, issue'yu ve web sayfasını potansiyel bir kimlik bilgisi taşıyıcısına dönüştürüyor ve erişim kontrolü sorumluluğunu protokol katmanından bireysel sunucu operatörlerine aktarıyor. 2026-07-28 revizyonunda bir MCP sunucusu çalıştırıyorsanız, istek başına handle ve token doğrulaması artık isteğe bağlı bir sertleştirme değil; güvenlik sınırının kendisidir.
- #mcp
- #model-context-protocol
- #prompt-injection
- #security
- #ai-agents
İlgili yazılar
- AgentRender, agent destekli ekran görüntüleri, PDF'ler ve sayfa çıkarımı için MCP araçlarıyla demo API'yi yayına aldı
- Spam göndericileri ASCII smuggling'e geçti: Yapay zeka döneminin görünmez metin saldırısı ana akım e-postaya taşınıyor
- Breeze v2, Go web frameworkünü yerleşik MCP ile AI-öncelikli platform olarak yeniden konumlandırıyor