On 28 July 2026, Anthropic published a blog post announcing that the fifth release of the Model Context Protocol specification was live, and that support was rolling out across Claude products. Buried in the announcement, alongside a stateless protocol core and a new extensions framework, was a line about hardening authorisation: MCP servers could now be authenticated against real identity providers, Entra, Okta, the enterprise standards, rather than whatever ad hoc scheme a given implementer had bolted on.
The same day, on the Isle of Man, one long build session away, a self-hosted MCP gateway called Airlock finished its fifth and final planned tier, without ever having heard of the announcement. Its threat model document contained a single, specific admission: it did not support networked transport, because MCP gave a server no way to trust who was actually calling it. That sentence had been true for as long as the project existed. By the time it was written down, it was already going out of date.
Worth being precise about this, because the announcement itself blurs a distinction that matters. MCP's new authorisation specification is a substantial, competently designed piece of work: OAuth 2.1, PKCE, dynamic client registration, token audience binding via RFC 8707, the mechanism that stops a token issued for one MCP server being replayed against a different one sharing the same identity provider. Read the actual specification rather than the marketing summary and one thing becomes clear immediately: every mechanism in it assumes HTTP. Tokens travel as Authorization: Bearer headers on HTTP requests. The entire document does not mention the protocol's other transport once.
That other transport is stdio, and it is not a footnote. It is how the overwhelming majority of MCP servers in production actually run today: spawned as a child process by the agent that talks to them, communicating over standard input and output, never touching a network at all. For that transport, the new specification changes nothing, because stdio never had the problem the specification solves. When you spawn a process yourself, you already know what it is. The question "who is calling me" does not arise when the answer is "whoever holds the file descriptor I handed them at spawn time."
So the honest summary is narrower than the headline. MCP grew a real identity model for its networked half. Its local half was left exactly where it always was, which is to say, nowhere in particular, because it never needed to be anywhere else.
Before this release, an MCP server had no reliable way to know who a networked caller claimed to be beyond a self-reported client name, sent once at handshake and never verified again. Any policy engine trying to make an access decision based on caller identity was, in practice, making that decision based on a string the caller had chosen to type. This is the kind of detail that reads as pedantic until the moment someone actually tries to build a gateway that enforces rules by caller, at which point it becomes the entire problem.
Airlock, the gateway mentioned above, was built on the assumption that this detail mattered enough to shape the architecture around it. Rather than expose itself over a network with a caller-identity field it could not trust, it stayed stdio-only: no listener, no socket, a filesystem drop-box for the one function (human approval of risky calls) that needed a rendezvous point at all. The reasoning, written into the project before this specification existed, was that a policy rule built on top of an unverifiable identity claim is not a policy rule; it is a rule about whoever was willing to type the right string.
That reasoning was correct when it was written and remains correct today, for exactly the transport it was written about. What changed is that the same reasoning no longer applies to the other transport. MCP servers speaking HTTP now have a real answer to "who is calling me." MCP servers speaking stdio still do not need one, and still do not have one, and the specification is honest enough not to pretend otherwise.
A second change in the same release is worth noting on its own terms, because it runs in the opposite direction: rather than adding a guarantee, it withdrew one that was never real. The Roots feature, which lets a client tell a server which directories it considers relevant, has been formally deprecated as of this specification version. The document's own language is unambiguous: Roots was always informational guidance rather than an access control mechanism, and the protocol never enforced that a server stay within the boundaries a client suggested.
This matters because "informational guidance" and "access control" get conflated constantly, by vendors under commercial pressure to describe a feature as more protective than it is, and by careful implementers who simply have not read the fine print. The specification's authors evidently decided that a mechanism widely capable of being mistaken for a boundary was worse than no mechanism at all, and removed it rather than leave the ambiguity standing. That is a defensible piece of protocol hygiene, and also, incidentally, confirmation that anyone who had already been treating Roots as untrustworthy was not being paranoid. They were reading the specification correctly before the specification said so in as many words.
The pattern worth naming here runs the opposite way to most of what fills this column. Usually the gap under examination is an institution's operational reality falling short of its governance claims: a control that exists on paper and nowhere else, a DPIA that was never filed, a firewall rule announced before it was written. This is not that. The MCP specification did the harder, less glamorous thing, and did it accurately: it built a real mechanism for the half of the protocol that needed one, said nothing about the half that did not, and quietly removed a feature that had been sitting in the ambiguous space between the two for years.
The interesting question this leaves is not whether the specification is honest. It appears to be. The interesting question is how many implementations built on top of it will describe "MCP now has enterprise authentication" as though it applied everywhere, rather than to the specific transport it actually covers. Until then, if someone tells you their local stdio MCP server is secured by Okta, the protocol isn't what needs auditing. The sales deck is.
Editor's note: Airlock will be rolled out to Codeberg and Forgejo within the next fortnight for those interested in the beta. The launch will be notified via Mastodon.
The Sovereign Auditor covers digital sovereignty, cybersecurity governance, and data protection policy, with particular focus on Isle of Man jurisdiction and Crown Dependency issues.
Payments via PayPal. Credentials delivered by email. No Substack. No Stripe. No middlemen.
