MCP is quietly growing an identity layer

The adoption numbers get the headlines. Uber runs 60,000 agent tasks a week over MCP, and Google Cloud's MCP Toolbox for Databases managed 20 million tool calls in a single month. 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.

What did the last two spec revisions actually change?

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. A token issued for one server can no longer be replayed against another, and a malicious server can no longer collect tokens that were never meant for it. 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. Now a token only works where it was minted. A whole family of confused-deputy problems got closed at the protocol level, before any individual developer had to think about them.

The 2025-11-25 revision, the current one, kept pulling the same thread. Authorization server discovery now supports OpenID Connect. Incremental scope consent through WWW-Authenticate lets a server ask for more access when a task actually needs it, instead of demanding everything up front. OAuth Client ID Metadata Documents became the recommended way for clients to identify themselves. None of this is flashy. 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.

What security work was the session quietly doing?

More than anyone assigned to it. The AAIF project page describes the next specification release in one line: MCP is becoming stateless at the protocol layer.

In MCP today, a client and a server open a session. They negotiate a protocol version and exchange capabilities, then hold a connection over which everything else happens. That session carries a lot of security weight. Authentication happens at the front of it. Human approvals get amortized across it: approve once, and calls keep flowing. And identity is often positional, meaning many servers know who is calling because of when the connection was opened, not because of anything in the request itself. A typical case: two agents reach the same server through one shared connection. The server sees a single caller and approvals flow under a single identity. Afterward, nobody can say which of the two actually ran a given tool.

The current revision already points away from that model. Tasks, experimental in 2025-11-25, 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, with clients resuming by polling. Each of these changes makes the connection less load-bearing. Follow the trajectory and you land exactly where the foundation says the protocol is going: any request may arrive at any instance, with no shared memory behind it.

For operators 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. Resource-bound tokens, discoverable authorization servers, incremental scopes, standardized client identity: these are the pieces you need once there is no session left to vouch for the caller. The protocol is building its identity layer first, so that 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?

Start acting as if the session were already gone. From monitoring tens of thousands of skills and servers across the public registries, my observation is that most published MCP servers still assume the old model: a long-lived connection from a trusted client, with authentication handled once at connect time (if at all) and logs keyed by session.

None of that fails today. It just builds on an assumption the protocol is walking away from. 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 front-load permissions. 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 are the only audit trail that survives. 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: 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.

Infrastructure maturity rarely looks like a keynote. It looks like resource indicators and discovery documents landing one pull request at a time, under open review. That is what stewardship of a protocol is for, and it is the strongest signal I can point to that MCP is being built to last.