Anthropic introduced the Model Context Protocol (MCP) in November 2024. Less than two years later it is cross-vendor infrastructure with thousands of public servers.
Pace explains part of that growth, but a specific assumption is baked into the authorisation model itself, one that only starts to matter once a human is no longer at the screen to grant consent. That assumption, and where it still breaks, is what this article unpacks, sitting inside the wider MCP security landscape.
What is the Model Context Protocol (MCP), and why did it become a security problem so fast?
The growth numbers are familiar ground. MCP is the standard interface through which an AI agent reaches tools, files and services, one shared contract that lets a model call whatever a server chooses to expose. The protocol grew from three published implementations in October 2024 to 6,878 servers by November 2025, and past 9,400 public servers by April 2026, which is the arc traced in how MCP’s security model evolved from adoption to containment.
The gap is measurable. A study of nearly 8,000 live servers found roughly 40% expose tools with no authentication configured, and only 8.5% use OAuth at all. That distance between what the specification intended and what got deployed is the MCP Authentication Gap, a violation of zero-trust thinking in the agentic stack. Scaling that fast also produced attack classes conventional scanners miss. If you are securing a deployment, the canonical starting point is the project’s own security best practices documentation.
Why does MCP’s authorisation model assume human consent when its deployments face autonomous workloads?
The authentication gap has a design cause, and it begins with where MCP came from. The assumption comes from the protocol’s local roots: when server and client share a machine, the user’s physical presence substitutes for real authentication, so the design could lean on a person to approve things as they happened. The specification’s security principles make this explicit: users must explicitly consent to and understand all data access and operations. The literal touchpoint is the OAuth consent screen, where someone signs in and grants each client permission. Per-client consent reinforces it: your general sign-in does not authorise any specific client to act on your behalf, a safeguard that exists to head off the confused deputy problem. Elicitation adds the same requirement before a server-provided URL is opened.
Autonomous workloads break all of this at once. An agent that plans and executes a multi-step task makes tool calls with no human present to approve, and the window for intervention shrinks to seconds. When no one is there to answer the consent prompt, the flow either stalls or fails. That is the consent gap.
What stands in for the missing human is where the industry is heading. Enterprise-Managed Authorisation lets an identity provider govern which clients reach which servers with no per-user consent screen. Workload identity gives the agent its own verifiable identity, a SPIFFE ID and its signed SVID, rather than borrowing the human user’s identity. On-Behalf-Of delegation, built on token exchange in RFC 8693, re-issues a token with a narrower scope that carries both the human being acted for and the agent doing the acting. The framing that ties it together is the oversight spectrum: human-in-the-loop, human-on-the-loop, and human-out-of-the-loop. MCP’s design assumed the first, while most autonomous workloads run in the third, and that mismatch is what turns human oversight into a governance requirement.
What does the MCP authorisation specification’s OAuth 2.1 framework actually require?
The specification’s answer was to borrow rather than build. MCP adopted OAuth 2.1, the authorisation code flow with PKCE made mandatory, piggybacking on a battle-tested standard instead of inventing a bespoke protocol. Discovery follows a chain: the server returns a 401 challenge carrying a resource metadata URL, the client fetches Protected Resource Metadata (RFC 9728), then Authorisation Server Metadata (RFC 8414) to find where to authenticate.
Authorisation is optional for MCP implementations. The specification recommends it for user-specific data, audit needs and enterprise controls, but deliberately left it off the hard-requirements list to ease adoption. Making it a gate would have slowed server onboarding.
That discovery sequence carries a specific risk. A client follows metadata URLs that a malicious server controls, and if those URLs point at internal addresses, the client’s own outbound requests become an attack path. That is server-side request forgery (SSRF), and it is among the most commonly reported vulnerability classes against public servers, which is why a gateway layer is where this discovery risk is best contained. Beside the framework sit the mandatory patterns that hold the trust boundary together: per-client consent, audience validation via Resource Indicators (RFC 8707), and a ban on token passthrough.
Dynamic Client Registration or Client ID Metadata Documents: which fits an open MCP ecosystem?
Client registration is where the consent gap stays unresolved. Dynamic Client Registration (DCR) lets clients obtain credentials at runtime, which lowers onboarding friction, but it was also a major source of MCP flaws: servers that accepted unauthenticated registrations effectively let anyone register any client, the same path that feeds credential and confused-deputy failures. Client ID Metadata Documents (CIMD) take the opposite approach, using a stable, domain-hosted URL as the client’s identifier so a server can verify who it is talking to rather than trust self-asserted metadata.
For an open ecosystem, CIMD is the better default. It gives you verifiable identity without closing the door, and it is now the specification’s recommended approach, with DCR kept as the fallback for clients that cannot host metadata. The trade-off is honest: DCR favours growth and automation, CIMD favours verification and abuse resistance. Registration establishes who the client is; protecting the token is a separate concern, handled by PKCE and audience validation. The normative reference for both is the MCP authorisation specification’s client registration section, worth reading closely, because which requirements are settled versus still moving keeps changing as the ecosystem matures. When you are weighing up a server before an agent goes near it, knowing what evidence to demand about client registration is part of that call.
The consent gap is the consequence of a model that assumed a human presence autonomous workloads do not provide. The specification borrowed OAuth 2.1 to harden the protocol, then kept authorisation optional and left client registration unsettled, so who consents is now an architectural and governance decision rather than a protocol detail. OAuth 2.1, mandatory PKCE, per-client consent and audience validation have each hardened the protocol, yet they still presume an authorisation decision can be made somewhere. Client registration and workload identity are where the industry is now naming the agent instead of waiting for the person, and that work is still settling. When you weigh whether an autonomous agent should touch production systems, that is the question to keep asking: what stands in for the missing human? Read it as one chapter in MCP security, from adoption to containment, where the attack classes, credential failures and governance questions that follow all trace back to this same design choice.
Frequently Asked Questions
Does implementing OAuth 2.1 make an MCP server secure?
No. OAuth 2.1 is a necessary foundation, not a complete security posture. A server can adopt the authorisation code flow with PKCE and still fail through unauthenticated client registration, missing token audience validation, or token passthrough. Security depends on the whole chain, including the mandatory patterns the specification pairs with OAuth 2.1 and the operational controls you add around them.
What happens if an autonomous agent reaches an MCP consent screen and no human responds?
The authorisation flow stalls. Per-client consent and elicitation both assume someone is present to approve access, so an unattended workflow either waits indefinitely or fails outright when the consent step cannot be completed. That is the consent gap in practice: the protocol has no built-in way to record a decision when no person is there to make it.
What is server-side request forgery (SSRF) in MCP OAuth metadata discovery?
SSRF is when a client is tricked into making requests to endpoints it should not reach, such as internal services. During MCP discovery, a client follows metadata URLs from a 401 challenge through Protected Resource Metadata (RFC 9728) and authorisation server metadata (RFC 8414). If those URLs are attacker-influenced, the client can be steered toward internal addresses, turning its own outbound requests into an attack path.
Where can I find the official MCP security best practices?
The canonical reference is the Model Context Protocol project’s own security best practices documentation, published alongside the specification. It covers authentication, authorisation, token handling, and deployment guidance for server operators. Treat it as the baseline for any deployment, then layer your own controls on top, because the gap between specification intent and real-world configuration is where most exposure sits.
Where is the MCP authorization specification and the client registration guidance?
Both live in the MCP authorization specification. The document sets out the OAuth 2.1 framework, the discovery sequence, and the mandatory patterns such as per-client consent and audience validation. Its client registration section is the normative reference for Dynamic Client Registration and Client ID Metadata Documents, and it is the place to check which requirements are settled versus still moving.
What is the confused deputy problem in MCP?
A confused deputy is a privileged component that is tricked into misusing its authority on behalf of someone with less privilege. In MCP, an authorisation server or proxy holding broad credentials can be manipulated into acting for an attacker, especially when tokens are passed through without proper audience checks. Per-client consent and token audience validation exist precisely to stop that misuse.
Is prompt injection a risk to MCP authorization?
Yes, indirectly. Prompt injection lets an attacker influence an agent’s behaviour through malicious content, which can push it to call tools or request access it should not. The authorisation model still governs what those calls can actually reach, so prompt injection makes the consent and token validation layers more important, not less. MCP’s risk taxonomy sits alongside broader OWASP Agentic AI guidance.
What is token passthrough and why does MCP forbid it?
Token passthrough is when a server accepts a token issued for one audience and forwards it to another service without validating that it was meant for that call. MCP forbids it because it breaks the trust boundary between services, enables confusion over who the token represents, and lets a compromised server replay credentials elsewhere. Proper audience validation (RFC 8707) keeps each token scoped to its intended resource.
What is the difference between human-in-the-loop, human-on-the-loop, and human-out-of-the-loop?
Human-in-the-loop means a person approves each significant action before it happens. Human-on-the-loop means a person monitors and can intervene, but does not pre-approve every step. Human-out-of-the-loop means the agent acts without real-time human involvement. MCP’s original design assumed the first, yet most autonomous workloads now run in the third, which is why the consent assumption breaks.
Do I still need PKCE and audience validation if I use Client ID Metadata Documents?
Yes. CIMD answers who the client is, not how the token is protected or which resource it is for. PKCE guards the authorisation code exchange against interception, and audience validation (RFC 8707) ensures a token is only accepted by the resource it was issued for. Registration method and token hardening solve different problems, so you need both together.
Is MCP an open standard or an Anthropic product?
Anthropic created and open-sourced MCP in November 2024, but it now functions as a community standard with a public specification and a growing ecosystem of independent servers and clients. That open reach is exactly what turned a trusted local tool into an internet-scale surface, and it is why the authorisation model’s original assumptions matter more as adoption spreads beyond Anthropic’s own tools.
How does workload identity help when no human is present to authorise an MCP agent?
Workload identity gives the agent or its host a verifiable identity of its own, commonly through standards such as SPIFFE and SVIDs. Enterprise-Managed Authorization and On-Behalf-Of delegation (RFC 8693) then let that workload act under a defined policy rather than waiting for a person. Together they replace the missing human with a named, auditable principal the authorisation server can trust.
