Research · MCP · authorization
Specified, Not Enforced.
The MCP authorization specification is not vague. It says MUST, repeatedly and precisely. Meanwhile around forty percent of MCP servers reachable from the internet carry no authentication whatsoever. That gap is not a specification problem, and treating it as one is how it stays open.
01 · The gap
A requirement nobody checks is a suggestion.
MCP is the vertical layer of the agent stack: it governs how an agent reaches a tool, where A2A governs how an agent reaches a peer. Through 2026 it acquired the authorization apparatus a protocol of that reach needs — OAuth 2.1 as the baseline, PKCE mandatory, Protected Resource Metadata for discovery, audience-bound tokens, and an explicit prohibition on forwarding a received token upstream as though it were your own.
The same year produced a CVE wave against MCP implementations — thirty in a single sixty-day window early in 2026, of which roughly forty-three percent were command-injection patterns. One of them, an authentication bypass in a widely deployed proxy, became the first MCP defect added to CISA's Known Exploited Vulnerabilities catalog, with exploitation confirmed. Censys counted more than twelve thousand MCP services reachable from the internet in April, and the recurring finding across independent scans is that a large fraction of them demand no credential at all.
It is tempting to read that as a specification failure. It is not one. The specification is unusually clear, and the July revision tightened it further. What the specification cannot do is run. Between a document that says MUST and a deployment that does there has to be something that looks, and for MCP that layer does not exist yet — no conformance suite, no certification, nothing a buyer can ask for. The requirements are stated and unenforced, and the question worth asking is what it would take to enforce them from outside.
02 · What the July revision changed
Three moves, all narrowing who may assert authority.
01Dynamic Client Registration deprecated. Registration without human involvement was the convenience that let a client appear from nowhere and be issued credentials. Removing it moves the trust decision back to a point where somebody makes it.
02Issuer validation made explicit. A token is now required to come from an issuer the resource trusts, stated as a requirement rather than left as an implication of audience checking.
03Enterprise-Managed Authorization as an extension. An organisation can have its own identity provider issue the grant, which is the first mechanism in the specification that lets a deployment say whose authority a token actually carries.
Read together, the three point the same way. Earlier revisions were concerned with whether a token was valid. This one is concerned with whose authority it carries and who vouched for that — the question a delegation chain actually turns on, and the one the rest of this page is about.
03 · The verifiability cut
Which expectations can be decided from outside.
A prober in a client position holds what any client holds: the ability to open a connection, to run the authorization flow, and to present tokens of its own choosing. It does not hold the server's configuration, its source, or its logs. The cut below asks, for each expectation, whether a deployment that meets it and one that does not produce different observations from that position.
The bypass answers here are differential, and that is not a detail of implementation. A server that admits a request with a forged credential has told you nothing on its own: a server that asks for nothing admits everything, and that is a legitimate local deployment rather than a bypassed boundary. The finding is the difference between a matched baseline from the same target and the probe that follows it — refused with nothing, admitted with anything. A bypass probe without its baseline is a finding you invented. The match is usually taken within one scan; MCPA10 is the exception and carries its reference across scans, and MCPA04 needs no control at all, because a published document is either there or it is not.
Seven external, two configuration, one undecidable. The headline is the seven. Almost every one of them is a few requests from a position any client already occupies: send no token, send someone else's token, send a token for another resource, drop the header and keep the session. A deployment's compliance with most of its own authorization expectations is a morning's work to establish, which means the forty-percent figure is not telling us these things are hard to see. It is telling us that this verification is not yet routine at the deployment level: MCP scanners exist, but they look at tool poisoning, prompt injection and client configuration rather than at whether an announced authorization boundary holds. What a probe from this position establishes is also narrower than it looks — it can demonstrate a specific violation, never full conformance.
MCPA10 is the one external case that costs more than a morning, and for an honest reason: the name of a withdrawn tool is absent from tools/list by definition, so it has to come from a baseline an observer recorded earlier. That makes it decidable across scans rather than within one — still external, but on a longer clock than the rest.
The two configuration cases are worth separating from the undecidable one, because they are often lumped together as "you can't check that". You can. A client cannot, but the organisation running the server can read its own code, and an auditor with the deployment in front of them can answer both in minutes. MCPA07 in particular — whether a received token is forwarded upstream — is a grep, not a mystery. What makes it invisible is the vantage point, not the property.
04 · The mapping
Ten expectations against the agentic taxonomy.
Cells carrying a marker are bindings the reference SARIF declares in relationships[]; a build gate compares this table against that file on every build, so a cell here cannot claim a binding the artifact does not assert.
declared in the reference SARIF · — no meaningful binding
ASI03 carries all ten, which is what you would expect and not what the table is for — an authorization specification produces identity and privilege findings by construction. The column to read is ASI07. Four expectations land there, and all four describe the same shape: a client and a server that disagree about who is speaking. A PKCE downgrade the server never sees, an authorization server discovered out of band, a credential crossing a boundary unchanged, an anchor the client supplies rather than the server issues. Inter-agent communication failures, in a protocol where one of the agents is a tool server.
05 · The tenth
Obtaining authority and applying it are different problems.
Nine of the expectations above are about how a server comes to believe a caller holds authority: where the token came from, who signed it, what it was minted for, whether a session can stand in for it. Every one of them is satisfied before the first tool runs.
The tenth is about what happens after. A server that restricts which tools it offers has made an authorization decision, and that decision has to hold at the method that executes as well as at the method that advertises. In at least one published case it did not: three environment variables restricted the tool set, the handler that answered tools/list honoured them, the handler that answered tools/call did not, and the fix was a single guard added to the second handler.
This is not a numbered MUST of the authorization chapter, and it is listed here with that said rather than quietly promoted. It is the property the chapter presupposes. Every requirement above is machinery for deciding what a caller may do, and machinery for deciding is worth exactly as much as the enforcement downstream of it. A deployment can satisfy all nine and still execute, on request, a tool it told the caller it does not have.
It is also the sharpest illustration of this page's title. The restriction was specified — in configuration, by the operator, deliberately. It was announced at discovery. It was not enforced at execution. Nothing about that failure is visible in how the server handles tokens.
06 · The residue
What is left when every checkable thing checks out.
Suppose a deployment passes all nine of the others. Its tokens are audience-bound and issuer-validated, PKCE is enforced, sessions authenticate nothing, no token is forwarded upstream, and every restriction it advertises holds at the method that executes. One thing is still not established, and it is the thing every other expectation exists to protect: that the token in hand was obtained with the user's informed consent, for this resource, at this scope.
That event happened somewhere else. It happened at the authorization server, at an earlier time, through a consent screen the resource never saw and cannot reconstruct. A token issued after a user read every scope carefully and a token issued after a user clicked through are byte-identical. There is no probe. There is no configuration file. The information was never created in a form anyone downstream can check.
This is the confused deputy, stated as a measurement problem rather than an attack. The usual framing has an attacker inducing the deputy to misuse its authority — and the authorization requirements above are aimed squarely at that attacker. But strip the attacker out and the deputy problem does not go away, because the deputy still cannot tell how much authority it was actually given, only how much it holds. The requirements establish that the authority is real. Nothing establishes that it is what was meant.
The same unbound pair appears one layer up, at the screen rather than the token: Approved, Not Shown defines the consent delta as the set of actions an approval authorizes minus the set it displayed, and finds nothing in the stack binding the two. MCPA09 is that class restated in bytes.
07 · Where this goes
Two directions out of the residue.
The first is to put the missing information on the wire. If a token cannot say whose authority it carries and how far that authority was meant to reach, then the delegation chain needs a primitive that can. HCAP is our proposal for that: capability and its provenance made explicit and verifiable down a chain, so that over-privilege and confused-deputy conditions become detectable rather than structural. Enterprise-Managed Authorization is the specification moving in the same direction from the other end — an organisation's own identity provider issuing the grant is the first mechanism MCP has for saying whose authority a token carries.
The second is to ask how much the gap actually costs, which is an empirical question nobody has answered. If a consumer holds more authority than the mandate it is executing under, and the state it reads was written by something with less, does the size of that difference predict how often the consumer steps outside the mandate? We have pre-registered that question — hypotheses, metric and falsification criteria fixed before any data, with a commitment to publish the null — and the answer will land either way.
Both directions start from the same observation this page is built on. The expectations that can be checked should be checked, by a tool, routinely, because seven of ten is a lot of ground to leave uncovered for want of somebody running the probes. And the one that cannot be checked should be named as such, rather than folded into a compliance percentage that quietly rounds it away.
08 · The artifact
Reference SARIF.
Ten rules, two taxonomies. Expectation identifiers bind as subset — each rule is one probe and does not establish that the expectation holds in every flow. ASI categories bind as relevant, which is a placement, not a coverage claim. Every rule carries a verifiability property, and the build gate fails if that property disagrees with the result kind the rule produced, or if this page's own verifiability column disagrees with the file.
Three rules also carry an implementation property naming the module in mas-sentry-toolkit that runs the probe — the authorization bypass, the protected-resource metadata walk, and the announce-versus-execute differential. The other seven are probe definitions without an implementation behind them yet, and the file says so by omitting the property rather than by claiming coverage it does not have.
Requirement text for the nine follows the specification; the tenth is stated as the enforcement property the chapter presupposes rather than as a numbered MUST. The verifiability classification, the probe definitions and the ASI bindings are ours, and the file says so in properties.source rather than leaving a reader to guess which half they are reading.
↓ mst-mcpauthz-reference.sarif.json
Cite the open question
Kiryak, E. (2026). Privilege-Differential Drift: Measuring Mandate Inflation in Hierarchical LLM Agent Systems — A Pre-Registration. Zenodo. 10.5281/zenodo.23513214
Sources
- Model Context Protocol — authorization specification and security considerations, revision 2026-07-28, modelcontextprotocol.io.
- Descope — analysis of the July 2026 authorization revision: deprecated Dynamic Client Registration, issuer validation, issuer-bound client credentials, Enterprise-Managed Authorization.
- RFC 9728 — OAuth 2.0 Protected Resource Metadata, including the Section 7.7 warning against following advertised authorization servers.
- GHSA-7488-6r32-c95q / CVE-2026-59822 — authentication bypass in an MCP proxy; the first MCP defect in CISA's Known Exploited Vulnerabilities catalog. Read off the published packages rather than a write-up.
- GHSA-cr22-wjx7-2w6m / CVE-2026-46519 — a tool filter honoured at
tools/listand not attools/call; the published case behind MCPA10. - Cloud Security Alliance — research note on systemic design weaknesses in MCP deployments, May 2026.
- Censys — count of internet-reachable MCP services, April 2026; independent scan estimates of the unauthenticated fraction.
- MASec Lab — Stateless, Not Traceless, 31.07.2026, on what the same revision cost detection.