MCP Authorization Scope Is the Hole the New Spec Handed You
See where the 2026 MCP spec fixed authentication and skipped authorization scope, and get the runtime audit CISOs need now.
The new enterprise MCP spec ships July 28, and MCP authorization scope is the one control it left out. The security press read the release as a fix and pointed to token binding, a stateless core, and credential-issuer checks. All of that is great work, but what should stop you cold in your tracks is that a connection-layer defense running a human approval on every single call still let 6 of 10 modeled attacks through. I’ll show you where that hole lives and what to do about it before your next agent rollout.
What the New Spec Got Right
Give the maintainers their due. The Model Context Protocol started life in 2024 as a way to wire a local model to a few tools on your laptop, and it grew into the default connector for agents talking to business systems. The 2026-07-28 revision is the biggest rewrite since MCP’s launch, and legacy versions will get a 12-month deprecation window. That is a serious, well-run standards effort, and I won’t pretend otherwise.
The headline change is that MCP goes stateless at the protocol layer. Sessions are gone. Any server instance can answer any request, which kills a whole class of session-hijacking problems that came from sticky sessions and shared session stores. On the auth side, six specification enhancement proposals (SEPs) harden how MCP rides on OAuth 2.1 and OpenID Connect. Clients validate the issuer on every authorization response per RFC 9207, which shuts down the mix-up attack in which one authorization server’s response gets replayed against another. Registered credentials bind to the authorization server that issued them. Tokens carry an audience, so a server can reject a token minted for somewhere else.
Audience-bound tokens aren’t new to this release. Resource indicators landed in the June 2025 spec under RFC 8707. This revision hardens that work rather than inventing it. If a vendor tells you server-bound tokens are the shiny new 2026 feature in the enterprise MCP specification, they either didn’t read the changelog or they’re hoping you didn’t. The front door is stronger than it was, and I give the maintainers full credit for the authentication story.
What It Opened, and Onto Whom
When the protocol stops enforcing something, that something doesn’t vanish. It moves to whoever builds the server. Maxim Zavodchik, who runs threat research at Akamai and co-wrote the sharpest analysis of the release, put it plainly. With the protocol going stateless and adding rich UIs and async tasks, the critical security boundaries now hang entirely on how developers build them. His team’s read is that the update improves the foundation by removing old protocol-level risks, and from there the build choices decide your security posture.
Walk through what that hands you. The stateless model replaces sessions with tracking identifiers the server hands the client. Make those identifiers predictable and you have opened the door to workflow hijacking and cross-tenant access. The new MCP-specific HTTP headers carry method and tool names for routing. Map a secret into one of those headers by accident, an API key or a token or a piece of PII, and it rides straight into every load balancer, proxy, and log along the path. MCP Apps let a server render interactive HTML in the client, which is a genuine user-experience win and also drags stored cross-site scripting into a place it never used to live. Long-running tasks are cheap for the client to start and expensive for the server to hold, which is a denial-of-service vector wearing a feature’s clothing.
The spec also deprecates roots, the capability a host used to declare which files and folders a server could touch. Nothing breaks yet. The deprecation is annotation-only with a year-plus runway. The direction is set, and the one host-declared boundary every server had to respect turns into guidance you handle through per-tool settings and server config. That is one more control moving from protocol-guaranteed to build-it-yourself.
None of this means the protocol got less secure. The attack surface of the servers your teams build on top of it got wider. That distinction matters, because it tells you where to point your budget. Not at the spec. At your own server code and the vendors shipping it to you.
Tool Poisoning Is the Tell
If you want to see why authorization scope is the whole game, look at MCP tool poisoning. A tool description isn’t documentation. The model reads it, trusts it, and acts on it. That makes the description an input the attacker controls, sitting inside your trust boundary. Microsoft’s security team framed it well in their 2026 checkpoint on the state of MCP security. Once a model picks its own tools and calls them, it has stopped returning text and started running actions on your systems, and code that acts sits inside a trust boundary.
Researchers demonstrated this with ShareLock, an attack that splits a malicious instruction into benign-looking pieces, scatters them across several tool descriptions, and reassembles them at run time after a quiet trigger planted during a server update. Tested across mainstream models on two MCP clients, it held an average attack success rate above 90% while sliding past the tool-description review that most guidance tells you to run. Read that number again. The control everyone recommends, inspect the description before you approve the server, gets beaten better than nine times in ten.
Scope enforcement doesn’t stop tool poisoning. A poisoned tool with tight scope is still poisoned. What scope decides is how far the damage travels once a tool goes rogue. Poisoning is the match. Missing scope is the pile of dry timber you stacked next to it. You won’t prevent every poisoned description. You get to decide whether a compromised tool can read one support ticket or drain your secrets store.
MCP Authorization Scope Is the Gap the Spec Won’t Name
Now, I also think there is a big miss in the updated spec. The spec tells a server which client is calling and which issuer vouched for it, but it never specifies what that tool is allowed to do once the call is authenticated. Those are different questions, and the second one is where agent incidents start. By scope, I mean what a tool may do at run time, on each call, not which server minted the token.
The authorization section says so itself. Authorization in MCP is optional. It lives at the transport level through OAuth. The spec states outright that the authorization server details are “beyond the scope of this specification,” and it leaves the scope values to whoever builds the thing. Someone will point at incremental scope consent and say scope is handled. Step-up consent decides what a user approves at login. It does nothing about what the tool does on call number 500 an hour later, with no human watching. The six authorization SEPs I praised earlier are all about the handshake. Issuer validation, credential binding, step-up consent at login time. Not one defines a per-tool capability that the server has to check on every invocation, or a deny it has to be able to produce. Even the roadmap items on the horizon, proof-of-possession and workload identity federation, bind identity more tightly. They don’t bound what a tool may do.
Someone benchmarked this exact gap, and it produced the number from my intro. A June 2026 study of MCP-style runtimes built 10 attack cases and tested 3 defenses. A naive connection-layer runtime let all ten through. A practice-informed connection-layer defense, the kind you would build today with metadata linting, session checks, and human approval on every call, blocked four and let six through. A runtime that enforced scope as an explicit execution-time invariant blocked all ten. The controls the new spec leans on live in that middle column. They beat nothing. They don’t close the gap.
You don’t need a lab to see it. In June 2025, attackers fed a Supabase agent support tickets loaded with instructions. The agent held privileged service-role access, and it handed over integration tokens. The privilege is what made the theft possible. An agent scoped to read the support queue and nothing else never holds the credentials to give away. That incident is the whole thesis in one sentence. Authentication was fine. Scope is what would have saved them.
The gateway crowd hits the same wall. WorkOS, which runs an OAuth server for MCP and has no reason to talk the spec down, flagged that when a request passes through a gateway, the protocol says nothing about how the downstream server learns what the original client was allowed to do. Their word for it was silent. The protocol goes silent exactly where your data-loss prevention and your policy enforcement need it to speak.
Governance as Architecture
None of this makes the maintainers wrong. They said in the March roadmap that deeper security and authorization work sits in the “on the horizon” pile, not in this cycle’s top four. I will take an honest roadmap over a vendor pretending the problem is solved any day of the week. Give Anthropic and the MCP maintainers real credit for putting the deferral in writing, so you can plan around it. The counter you will hear is that a protocol shouldn’t dictate authorization policy. Fair. Then say that in the spec, and hand implementers a scope primitive instead of silence. Silence is how you get a hundred incompatible answers.
The problem is architectural. OAuth 2.0 standardized the handshake and left the scope values to whoever built the authorization server. The strings were implementer-defined by design. We then spent the better part of a decade cleaning up overbroad grants, scopes that meant different things at different providers, and tokens that could do far more than anyone intended. A protocol that nails authentication and punts authorization doesn’t remove the authorization problem. It guarantees a hundred teams solve it a hundred ways, and your incident response inherits the mess. Your SOC can’t write one detection that holds across servers when every server means something different by “allowed.” MCP is running the same play. You can see the ending from here.
Encode scope where it belongs, at run time, and stop treating it as a connection-time checkbox. Here is the CARE version you can start tomorrow.
Create the inventory first. You can’t scope what you can’t see, so list every MCP deployment and every tool each server exposes, including the ones a team wired up last quarter without telling you. Adapt each tool to a runtime scope. Can it read, can it write, can it act, and against which resource? A tool that reads a support queue and a tool that moves money don’t get the same grant. Run the test that matters, which is the deny. Make every vendor and every internal team show you a blocked over-scope call in the logs, with the decision and the audit record attached. If they can only show you a successful call, they proved authentication and told you nothing about authorization. Evolve it on a cycle. Scope drifts as tools get added, so this belongs in your quarterly review next to access recertification, not in a one-time project that rots on a wiki.
Ask every vendor you encounter, “Where is authorization scope enforced, and can you show me the deny?” If the answer is a diagram of the OAuth flow, they answered a different question. Keep asking until someone shows you the runtime decision or admits there isn’t one.
Key Takeaway: MCP authorization scope is a runtime decision your servers have to make and prove on every call, and until the spec forces it, the deny is yours to build and yours to demand.
What to Do Next
Start the inventory and the deny test this week, before the July 28 final spec turns every enterprise MCP rollout into a live deployment you are accountable for. Run the CARE loop against your agent fleet and put scope on the same review cadence as identity. For the deeper argument on why a tool description is an attacker-controlled input rather than documentation, I have written about treating the model as an actor instead of a component over at rockcybermusings.com, and about why least agency beats least privilege once tools can act at rockcyber.com. If you read my earlier breakdown of the NSA MCP design guidance, this is the same authorization gap, one spec revision later.
👉 For ongoing analysis of agentic AI governance frameworks, the conversation continues at RockCyber Musings.
👉 Visit RockCyber.com to learn more about how we can help with your traditional Cybersecurity and AI Security and Governance journey.
👉 Want to save a quick $100K? Check out our AI Governance Tools at AIGovernanceToolkit.com
👉 As a bonus, check out my conversation with AI Cyber Magazine, where we talked about everything from Context Rot to Least Agency. My interview is also highlighted in the AI Cyber Magazine 2026 Summer Issue.
The views and opinions expressed in RockCyber Musings are my own and do not represent the positions of my employer or any organization I’m affiliated with.