MCP Protocol Spec Changes That Create New Defensive Requirements

MCP spec changes bring new features and call for new defenses. Each revision changes where trust must be checked, so updating a library cannot make an older deployment secure on its own. From the 2025-03-26 OAuth 2.1 layer to the 2026-07-28 stateless core, the practical lesson is the same. Security teams must check how the controls in their running systems cover each change to the architecture.

How the MCP specification has evolved since launch, and why each revision changed the security picture

MCP launched in November 2024 with the initial 2024-11-05 specification. Four post-launch versions followed, namely 2025-03-26, 2025-06-18, 2025-11-25, and 2026-07-28. Each shifted assumptions on which earlier security controls depended. The official changelog lists both breaking changes and smaller changes that affect security, so it is the clearest way to track that shifting baseline.

The direction of travel explains the pressure. MCP grew from a local, single-user integration tool toward use in the cloud at enterprise scale, with more systems and identities in the mix. The original session-based model became untenable at that scale. The 2026-07-28 release candidate describes the largest revision since launch, with breaking changes to the core protocol, extensions, and authorization. That makes the version a deployment supports a security question.

What the 2025-03-26 OAuth 2.1 layer demanded from teams that had shipped without it

The 2025-03-26 revision introduced an OAuth 2.1-based authorization framework where the protocol had required none before. Servers already in production had thus shipped before the protocol required an authorization layer. Teams could not rely on the previous specification to have required protection on earlier servers. Existing deployments needed an authentication retrofit.

The gap concerned who could cause a server to act and whose permissions governed that action. Microsoft describes a confused-deputy attack in which an MCP server uses its own broad privileges to reach data or take actions that the user was never allowed to. In some cases, the user approves nothing. The defensive requirement was therefore to audit every deployed server for the presence and correctness of OAuth 2.1, PKCE, and redirect-URI enforcement. A specification update could not close a gap in a server that still lacked those controls.

What the 2025-06-18 Resource Server classification added on top — and why token audience binding is the core new requirement

The 2025-06-18 revision kept the OAuth 2.1 layer and added another boundary. It formally classified MCP servers as OAuth Resource Servers and required clients to implement Resource Indicators under RFC 8707. A token issued for one server must not be accepted by another. Teams that had finished adding authorization now had to establish that credentials were bound to the right destination.

Without that binding, a credential issued for one MCP server can be replayed against a different server. The protocol states the rule clearly, but the code in each system must carry out the audience check. A valid token is not enough if it is valid for somewhere else. Microsoft recommends an identity-aware gateway in front of every server that rejects calls without a valid, audience-bound token.

This revision also introduced protected resource metadata so clients could discover the corresponding authorization server. Under RFC 9207, clients MUST validate a present iss parameter against the recorded issuer before redeeming an authorization code. Audience binding and issuer validation address different boundaries, and completing one does not satisfy the other.

How the 2026-07-28 stateless core broke the assumptions that session-based security controls depended on

The 2026-07-28 specification removes the Mcp-Session-Id header and the initialize / notifications/initialized handshake. A control built to inspect, validate, or revoke a protocol session identifier now has nothing to act on. Stateless operation moves responsibility away from the session and into individual requests and application logic.

Protocol version, client identity, and client capabilities now travel in _meta on individual requests. Gateways and inspection tools must therefore enforce policy at the request layer. Servers that need to keep state across calls create explicit handles, which clients pass as ordinary tool arguments. Those handles move state management into application code, so a review that looks only at protocol sessions will miss it.

Retry handling changes too. The changelog removes SSE stream resumability and message redelivery, including Last-Event-ID and SSE event IDs. Clients MUST re-issue broken requests as new requests with new request IDs, so defenses must cover retry-based abuse. The removal of ping, logging/setLevel, and notifications/roots/list_changed also retires familiar control points. Log level now travels per request through io.modelcontextprotocol/logLevel in _meta, requiring centralized log-level controls to be rebuilt there.

The three new attack surfaces the 2026-07-28 revision introduced alongside the stateless core

The revision removes the protocol-level session-hijacking surface but adds three others, beginning with MCP-specific HTTP headers. Mcp-Method is required on every Streamable HTTP POST request, while Mcp-Name is required on named-target requests such as tools/call, resources/read, and prompts/get. Conflicting header and JSON-RPC body values create a protocol confusion, or desync, risk. The x-mcp-header directive also lets tool parameters populate custom headers, where accidental mappings can leak API keys, tokens, or PII. These values require inspection and sanitization as untrusted input.

The second surface is MCP Apps, which first launched as an official extension on January 26, 2026. Under the 2026-07-28 formal extensions framework, they become a first-class protocol extension through which a server can supply interactive HTML for a host to render inside a sandboxed iframe. That brings risks in the browser, including stored cross-site scripting. Rendering contexts need browser-grade content security controls because a sandbox does not prevent every injection path.

The third surface is redesigned elicitation. The Multi Round-Trip Requests pattern in SEP-2322 replaces server-initiated requests with an InputRequiredResult pattern, after which the client re-issues its request with answers. Security controls must cover that retry flow. The elicitation specification also says that, to collect sensitive credentials such as passwords or API keys, servers MUST NOT use form mode and MUST use URL mode instead. Implementations must enforce that rule and verify that server-initiated requests occur only while a client request is actively being processed.

Authorization hardening in 2026-07-28 — what DCR deprecation and credential binding require in practice

DCR remains available in its deprecated status. That distinction creates a migration period in which DCR and flows based on client metadata documents can coexist, leaving teams uncertain about which mechanism their deployment uses. Teams whose credential storage was built around DCR must migrate to flows based on client metadata documents. Teams must also address how persisted credentials are separated.

The changelog requires clients to key persisted credentials by issuer identifier, forbids reuse with a different authorization server, and requires re-registration when that server changes. Authorization servers SHOULD include iss in authorization responses, and clients MUST validate it when present before redeeming the code. These rules make the issuer a storage boundary. That matters when one MCP server holds credentials for several downstream systems.

Ignoring those boundaries can lead to token passthrough, where an upstream token is forwarded into downstream tool calls. A credential then reaches systems it was never intended to touch. OAuth 2.0 token exchange under RFC 8693 is the replacement identified in the defensive requirements.

Why tool poisoning and prompt injection become harder to detect when the spec removes session context

Tool poisoning predates the stateless redesign, but the loss of session context changes detection. There is no longer a protocol session over which anomalous patterns can accumulate. Each request arrives without that built-in continuity. This removes context that session-based inspection depended on.

A language model consumes tool descriptions and parameter schemas that the person triggering the action rarely sees at runtime. Malicious instructions hidden there can therefore influence the model without appearing in the user interface. Microsoft recommends treating tool descriptions and outputs as untrusted input, inspecting the full schema before approving a server, requiring human approval of the tool list, and showing the full tool call.

Caching adds persistence to that risk. The new ttlMs and cacheScope fields on tools/list results allow a poisoned definition to survive across many requests without being fetched again. Advance declaration of UI templates lets hosts prefetch, cache, and review them, but that advisory mitigation supplies no cryptographic integrity check on tool definitions. The x-mcp-header extension adds another path because a poisoned tool can direct values into headers that infrastructure trusts for routing.

What the Tasks extension moving out of core means for audit coverage of long-running agent work

Moving Tasks from core into an official extension under SEP-2663 may look like a change on paper, but it changes what an audit covers. Long-running asynchronous work now needs its own extension negotiation. Teams that do not explicitly enable and monitor Tasks lose visibility into background activity previously included in core. Security review must therefore cover negotiation itself, using the new extensions field in both ClientCapabilities and ServerCapabilities.

The redesigned extension also changes the evidence available to audit tools. Polling through tasks/get replaces the blocking tasks/result method, so capturing a synchronous result no longer covers the work. The new tasks/update interaction carries client input during a running task and must enter the audit log. Meanwhile, removing tasks/list means active-task enumeration must be rebuilt outside that protocol primitive.

Unsolicited task handles create the sharpest governance concern. Servers can return them without per-request opt-in, allowing autonomous background work that is not anchored to an explicit user action. If that work touches regulated data, the audit requirement does not disappear with the missing opt-in. Teams must log and attribute those handles independently so the work remains traceable to its origin.

The identity gap the spec still does not close — workload identity for agents running without a user present

Enterprise-Managed Authorization governs who can enter an MCP server. It does not establish the workload identity of an autonomous agent running without a user present. Two questions remain beyond that boundary, which are what the agent may touch once inside and whose name appears on the resulting action. This is a limit of protocol responsibility.

The MCP OAuth Client Credentials extension addresses unattended authentication for machine-to-machine calls. Standardized agent identity and delegation, including the chain from user authorization to a specific agent instance, are still being developed and have yet to become final specification text. Microsoft identifies the related exposure from credential aggregation, where compromising one server can expose credentials for several systems. Organizations must add per-user credentials, scoped access, workload identity, and attributable audit trails outside the protocol.

Translating each spec revision into a concrete checklist of defensive controls

For 2025-03-26, audit OAuth 2.1, PKCE, and strict redirect-URI enforcement on every existing server, and confirm that per-client consent cannot be bypassed. For 2025-06-18, verify audience binding throughout token issuance and validation, validate present iss values before code redemption, and put an identity-aware gateway in front of each server.

For 2026-07-28, move inspection and log-level enforcement to individual requests, review application-managed handles, and cover the new retry flows. Sanitize MCP-specific headers, apply browser-grade content security policy to MCP Apps, and audit elicitation against the prohibition on sensitive credentials in form mode. Establish whether DCR remains in use, migrate to client metadata document-based flows, segment credentials by issuer, and replace token passthrough with token exchange. Review tool schemas and cached definitions as untrusted content rather than treating protocol compliance as proof of integrity.

Finally, rebuild the view of task activity from poll responses, inputs to running tasks, and unsolicited handles traced to their source. Make extension negotiation part of the security review and add workload identity and per-user delegation outside MCP. A deployment passes the test when every trust boundary the newest version moves has a working control in its new location.