MCP üzerinde OAuth kimin çağırdığını kanıtlar, her bir tool çağrısının ne yapabileceğini değil

Yazının merkezindeki ayrım

dev.to'da bir yazı, bir Model Context Protocol dağıtımını güvene alırken kolayca bulanıklaşabilecek bir çizgi çekiyor: OAuth, bağlantının diğer ucundaki tarafın kim olduğunu belirler, ve bu kadar. Belirli bir tools/call isteğinin gerçekten çalıştırılıp çalıştırılmayacağı ayrı bir karardır ve bir access token tek başına bunu asla vermez.

Yazar bunu iki farklı soru olarak çerçeveliyor. Kimlik doğrulama, çağıranın kimliğini çözer. Tool çağrısı yetkilendirmesi ise çok daha durumsal bir şey kararlaştırmak zorunda: bu belirli principal'ın, şu anda, bu koşullar altında, bu kaynak üzerinde, bu belirli tool'u çalıştırmasına izin verilip verilmediği. Oturumu açmak için yeterli olan bir token, bu değişkenlerden hiçbiri hakkında bilgi vermez.

2026 spesifikasyonu neyi değiştiriyor, neyi açık bırakıyor

Yazıya göre 2026-07-28 tarihli MCP spesifikasyon revizyonu, protokolün kimlik doğrulama ve yönlendirme davranışını issuer doğrulaması, CIMD yönü ve yeni Mcp-Method ve Mcp-Name header'ları dahil olmak üzere birkaç yönden sıkılaştırıyor. Bunlar anlamlı eklemeler. Özellikle header'lar, bir isteğin hangi metodu ve hangi tool'u hedeflediğini ortaya koyarak policy katmanlarına, opak bir istek yerine incelenebilecek somut bir şey veriyor.

Ancak merkezî iddia şu: tüm bunlar kimlik doğrulama ve yönlendirme katmanında kalıyor. Kimin çağırdığını doğruluyor ve isteği doğru yere yönlendirmeye yardım ediyor; isteğin çalıştırılıp çalıştırılmayacağına karar vermiyor. O yargı tamamen, bir kurucunun protokolün çevresine inşa ettiği şeye kalıyor.

Her tool çağrısı aynı sürtünmeyi hak etmez

Yazar, noktayı vurgulamak için basit bir risk tayfı kullanıyor. Bir read_ticket sorgusu düşük risklidir ve asgari merasimle geçmelidir. Bir issue_refund çağrısı para hareketi yapar ve daha fazla inceleme hak eder. Bir drop_table işlemi yıkıcıdır ve en yüksek standardı gerektirir. Üçüne de aynı muameleyi yapmak — ki yalnızca OAuth'a güvenerseniz fiilen varsayılan durum budur — ya tehlikeli çağrılar için pervasızlıktır ya zararsızlar için gereksiz yavaşlıktır.

Kademelendirme için önerilen mekanizma yeni header'lardır: Mcp-Method ve Mcp-Name'i okuyun, gelen isteği riske göre sınıflandırın ve uygun miktarda denetimden geçirecek şekilde yönlendirin.

Çağrı başına kararları dayatmak için bir desen

Dayatma katmanın kendisi için yazı, MCP istemcisinden gateway'e, oradan PDP'ye ve MCP sunucusuna uzanan bir boru hattı taslak ediyor. Gateway, istemci ile tool sunucusu arasında yer alır; PDP, yani policy decision point, her isteği kurallara göre değerlendirir; sunucu yalnızca boru hattının onayladığını çalıştırır.

Tasarımı iki ilke taşır. Birincisi, varsayılan olarak reddet: bir istek, policy açıkça izin vermedikçe geri çevrilir. İkincisi, yüksek riskli işlemler için step-up denetimleri uygulayın; böylece hassas bir tool çağrısı, sıradan bir oturum token'ının sağladığından daha güçlü bir güvence talep eder.

Neden önemli

Agent entegrasyonları, tek bir bağlantının tetikleyebileceği ayrıcalıklı işlem sayısını çoğaltıyor ve bir modelin tool seçimi, bir insanın önceden gözden geçirdiği bir şey değil. Bu koşullar altında oturum düzeyinde kimlik doğrulama bir taban, bir tavan değil. Aktörün meşru olduğunu söyler; ama aktörün agent'ının giriştiği her eylemin bilgece ya da kasıtlı olduğunu söylemez.

Yazı, bir MCP sunucusuna OAuth bağlamanın yetkilendirmeyi bitirdiğini varsayan kurucular için yararlı bir düzeltme. 2026-07-28 revizyonunda tanıtılan header'lar ince taneli kararları uygulamayı kolaylaştırıyor ve istemciden-gateway'e-PDP'ye-sunucuya deseni bu kararlar üzerinde harekete geçmenin somut bir yolunu sunuyor. Zararsız okumalardan finansal işlemlere ve yıkıcı yazmalara kadar farklı hassasiyette tool'lar açan herkesin, tam olarak bu tür bir — çağıranı içeri kabul ile çağrıyı geçirme arasındaki — ayrıma ihtiyacı olacak.