Model Context Protocol has published a major specification update that makes connections between agents and enterprise tools substantially easier to manage, alongside several authorization security improvements.
The short version: it is now much easier to see which agent is calling which tool, and what that agent is trying to do with it.
Stateless by default
MCP has moved to a largely stateless model. Each request now carries the information needed to understand it, rather than depending on a continuing session between client and server.
The immediate benefit is operational. Stateless servers are far easier to run and scale, which matters once MCP servers stop being a proof of concept on someone's laptop and start being infrastructure.
The security benefit is the one identity teams should notice. A request that explains itself can be evaluated on its own, by something sitting in front of the server, without reconstructing session state first.
The method and tool name are now in the headers
This is the change with the most direct consequence for access control.
The method and tool being called can now be exposed directly in HTTP headers. A security gateway can see that an agent is attempting to call a search tool or a delete tool, and apply controls to that individual request, without having to parse the full MCP message body to work out what is happening.
Authorization decisions have to happen somewhere cheap and early. Putting the tool name in a header is the difference between a policy engine and a body parser.
Practically, this means an organisation can stand up a single control point in front of a fleet of MCP servers and manage which agents are permitted to use which tools, centrally. That is a familiar shape. It is roughly what an API gateway does for services, and until now it was awkward to do for agent tool calls.
It also makes the audit question answerable. "Which agent called the delete tool, against which server, and when" becomes a log query rather than a research project.
The OAuth changes
MCP has also tightened its authorization story in three ways worth knowing.
Stronger checks on which authorization server issued a credential. Confused-deputy problems in this space usually start with a token being accepted by something that never established who minted it.
Binding credentials to the server that issued them. A token that only works where it was meant to work is much less useful once stolen.
Moving away from Dynamic Client Registration towards Client ID Metadata Documents. Dynamic Client Registration lets clients register themselves, which is convenient and difficult to govern. Metadata documents give you a client identity you can actually inspect ahead of time.
Why this matters beyond the spec
The pattern here is the same one playing out across agent identity generally. The first generation of a protocol optimises for making the connection work. The second generation optimises for someone being accountable for what happened over it.
This is a genuine step towards MCP being something an enterprise can place authorization controls around, rather than a convenient way for agents to reach tools that security teams then discover after the fact.
Two caveats. A specification allowing a gateway to inspect tool calls is not the same as your organisation having such a gateway, and the header only helps if something is actually reading it. And a stateless request model shifts work onto whatever issues and validates credentials, which raises the cost of getting the OAuth configuration wrong.
Still, the practical question for identity teams has changed. It used to be whether agent tool access could be governed at all. Now it is whether you have put anything in the path that governs it.
Source
The full MCP specification update, Model Context Protocol