Model Context Protocol has crossed the line that separates a promising spec from production infrastructure. I want to make the case that the more interesting story is in the changelog.
I spend my days on the security side of the agent ecosystem, reviewing MCP servers and monitoring what gets published to the public registries. When I find vulnerabilities in agent tooling, I report them. From that seat, a spec revision reads differently than release notes. Protocols encode assumptions about trust, and when those assumptions change, everything built on top inherits the change, usually without noticing. Over the last two revisions, MCP has been changing one assumption in particular: what a connection is allowed to remember.
Changes in the last two MCP revisions
They moved trust, one piece at a time, from the connection to the request. The 2025-06-18 revision classified MCP servers as OAuth resource servers and required clients to implement Resource Indicators (RFC 8707). That sounds bureaucratic until you translate it. With correct audience validation, a token issued for one resource is rejected by another. Clients must also avoid forwarding tokens to unintended resources.
Picture an agent connected to your deployment server and to some third party notes server: before resource binding, a compromised notes server could take a token it saw and try it against your deployments. With correct audience validation, a token is accepted only by its intended resource server. The specification defines a defense against token misuse; client and server implementations still have to enforce it.
The 2025-11-25 revision kept pulling the same thread. Authorization server discovery now supports OpenID Connect. Incremental scope consent through WWW-Authenticate (SEP-835) lets a server ask for more access when a task actually needs it, instead of demanding everything up front. OAuth Client ID Metadata Documents (SEP-991) became the recommended way for clients to identify themselves. And in June the trajectory reached production: Enterprise-Managed Authorization went stable, putting MCP server access under the organization's identity provider, with Okta first and support across Claude, VS Code and major servers at launch. Each change takes something that used to be implicit in the connection and makes it explicit in the request.
That distinction matters because of where the protocol is heading next.
Security hidden in the session
More than anyone assigned to it. The next revision makes it visible: the 2026-07-28 release candidate, published in May and described by the maintainers as the largest revision since launch, moves MCP to a stateless core, with Tasks and MCP Apps as extensions, a formal deprecation policy and six more proposals hardening authorization.
Update, September 3, 2026: the 2026-07-28 revision shipped as final on July 28 with the stateless core described here. I wrote up what that leaves to server implementations in MCP 2026-07-28 moves the security boundary to the server.
Under 2025-11-25, initialization negotiates version and capabilities, and Streamable HTTP can use a session identifier. That identifier is not authentication. The authorization requirements still apply to individual requests. Implementations that infer permission only from an established session can violate this distinction.
The 2025-11-25 revision already points away from that model. Tasks (SEP-1686), experimental in that revision, let a request outlive its connection: you submit work and disconnect, and the result waits until you come back for it. Servers may now close SSE streams at will (SEP-1699), with clients resuming by polling. Each of these changes makes the connection carry less weight. Follow the trajectory and you land exactly where the 2026-07-28 revision lands: any request may arrive at any instance, with no shared memory behind it.
For platform teams this is good news of the plain kind. You can scale horizontally without sticky sessions, and retries get simpler because there is less half open connection state to reason about. But if the session disappears as a unit of continuity, everything the session was implicitly carrying has to move somewhere explicit. Identity has to arrive with every request. So does authorization context. The audit trail stops being "what happened on this connection" and becomes "what evidence does each call carry on its own".
Seen from there, the authorization work of the last two revisions stops looking like an unrelated pile of OAuth plumbing. Tokens bound to a resource, discoverable authorization servers, incremental scopes, standardized client identity: these are the pieces needed to authenticate and authorize requests independently of connection state. The protocol made request identity and authorization context explicit before the stateless revision, so statelessness does not arrive on top of implicit trust. As someone who reviews agent infrastructure for a living, that ordering is the most reassuring thing about the roadmap.
What does this ask of server authors today?
Validate authorization on each request, including when supporting older protocol revisions. Review any implementation that keys identity or permissions only by a connection or session identifier.
A session identifier was never a substitute for those checks, including in older revisions.
For anyone maintaining a server, the adjustments are concrete and worth starting now.
- Treat every request as the first one. Validate the token on each call and honor resource binding, so a token minted for someone else's server never works on yours.
- Scope narrowly and ask again when needed. Incremental consent exists precisely so you don't have to load permissions up front. A database server can start read only and ask for write access the first time a task actually needs it. A server that requests everything at install time is training users to approve without reading.
- Attach evidence to calls, not connections. Log the authenticated identity, the tool and the arguments per request. When state moves out of the protocol, per-call records should be correlated with application and infrastructure evidence. The day someone asks who dropped a table last Tuesday, "the 10:03 connection" is not an answer. "This identity called this tool with these arguments" is.
- Design tools for retries and deferred results. With tasks, your tool may run detached from the requester and deliver its result later. The classic failure here is a deployment tool that runs twice because a retry landed. Idempotency stops being optional, and so does deciding explicitly who owns a result.
Where does this get decided?
In public, and that is the point. The 2025-11-25 revision also formalized how MCP is governed (SEP-932 and SEP-1302): working groups with defined scope and changes that move through the SEP process. Every change I described above went through a public proposal that anyone could read and comment on. If you run MCP in production, you have field data the spec authors need, and there is now a defined door to walk through with it.
The security changes landed as pull requests under open review: resource indicators, discovery documents and client identity, one proposal at a time. That is what stewardship of a protocol is for, and it is the strongest signal that the protocol is being hardened deliberately.