MCP authorization shifts the security problem to identity layer control

At a glance

What this is: This is an analysis of MCP authorization hardening, showing that the central risk has moved from server code flaws to identity-layer decisions about consent, token scope, and provenance.

Why it matters: It matters because IAM, NHI, and agent governance teams now need to treat MCP authorization as a lifecycle and detection problem, not just an OAuth configuration problem.

By the numbers:

• 53% of MCP servers expose credentials through hard-coded values in configuration files.
• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.

👉 Read SlashID's analysis of MCP authorization, consent, and identity-layer gaps

Context

Model Context Protocol security is now less about whether the server is patched and more about who can obtain, exchange, and reuse identity grants across the MCP chain. In this article, the primary concern is MCP authorization, because the server may execute exactly as instructed even when the wrong identity was allowed to ask.

Once MCP moved from local tooling to remote HTTP endpoints, identity governance became the control plane. That creates direct implications for NHI, OAuth, IdP policy, and agent delegation, because the failure mode is no longer code injection alone but valid tokens being used in ways the original consent model never anticipated.

Key questions

Q: How should security teams govern MCP access when tokens are valid but behaviour is not trustworthy?

A: Security teams should treat token validity as the starting point, not the end of the control check. MCP access needs behaviour-based review, audience enforcement, and inventory of downstream hops, because a valid grant can still be used in ways the original consent never intended. The control question is whether the action still makes sense for that identity, not merely whether the token parses correctly.

Q: Why does MCP increase the governance burden for IAM and NHI teams?

A: Because one published capability can be reused across many hosts, models, and runtime surfaces. That portability expands the blast radius of a single access decision and makes entitlement, logging, and tenant separation essential. The control question changes from connector security to capability governance.

Q: What breaks when consent is handled by the wrong layer in MCP?

A: When consent is handled in the browser or app layer, the enterprise loses policy consistency and revocation control. A user prompt cannot explain delegation scope, downstream fan-out, or lifetime drift. In practice, the wrong layer turns a governance decision into a usability event, which is exactly how shadow access grows.

Q: Who should own MCP authorization in an enterprise?

A: MCP authorization usually sits at the intersection of IAM, API security, and platform engineering, but the ownership model should be explicit. Identity teams should own authentication and policy standards, platform teams should own gateway enforcement, and application teams should own the tool inventory and business justification.

Technical breakdown

How MCP authorization separates resource server and authorization server roles

The MCP authorization model follows OAuth 2.1 but removes the ambiguity that earlier designs created by forcing the MCP server to act as both resource server and authorization server. The current spec treats the MCP server as the resource server only. It validates tokens, checks audience, enforces scope, and serves requests, while the authorization server is a separate identity system that mints the token. That split matters because discovery, consent, and token binding now happen in distinct places. It reduces the risk of stale endpoint assumptions and prevents the server from becoming its own trust authority.

Practical implication: separate discovery, token issuance, and resource validation in your MCP architecture and do not let a single endpoint impersonate all three roles.

Why protected resource metadata and resource indicators matter for MCP

Protected Resource Metadata tells the client where to find the authorization server, and Resource Indicators bind the eventual token to a specific resource. Together, they prevent the common OAuth failure mode where a token issued for one surface is replayed against another. In MCP, that is critical because multiple servers, tools, and hosts may exist in one enterprise flow. The audience claim and the resource parameter must line up, or the token becomes a portable credential rather than a scoped grant. That is an identity control, not just a protocol detail.

Practical implication: enforce audience checks and resource binding for every MCP token so a grant issued for one server cannot be reused elsewhere.

How EMA changes enterprise consent in MCP

Enterprise-Managed Authorization moves consent away from the browser and into the IdP through token exchange and JWT-bearer delegation. The point is not convenience alone. It is to replace per-session consent screens with policy decisions made in the identity plane, where the enterprise can express who may connect what to which resource. This also changes the attack surface because the user-facing consent prompt is no longer the control that authorizes access. Instead, the IdP becomes the decision point, and that means policy quality, issuance context, and downstream token lifetime now carry the governance burden.

Practical implication: treat IdP policy as the consent authority for MCP integrations and review whether the enterprise can explain each delegated grant without relying on user prompts.

Threat narrative

Attacker objective: The attacker wants valid identity grants that can be reused beyond their intended scope to reach tools, data, and downstream agents without tripping protocol-level checks.

1. Entry occurs through a legitimate MCP authorization flow, where a user or client obtains a valid grant that is correctly minted but may later be reused beyond the original intent.
2. Escalation happens when the token is exchanged, reused, or forwarded in a way that preserves validity while losing the context that should limit its use across agents, hops, or resource boundaries.
3. Impact is unauthorized but protocol-valid access to MCP tools and data, including shadow infrastructure and cross-server behaviour that the authorization stack alone cannot distinguish from normal use.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Internet Archive breach — unsecured GitLab authentication tokens exposed 31M Internet Archive accounts.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Valid token, wrong behaviour is the central MCP governance problem. MCP authorization is not failing because tokens are absent. It is failing when valid grants are treated as sufficient evidence of trustworthy use, even after delegation, fan-out, or downstream reuse. That changes the governance question from authentication success to identity behaviour review. Practitioners should stop equating protocol validity with access legitimacy.

Consent screens no longer define enterprise authorization in MCP. EMA shifts the decision to the IdP, which is useful because enterprise policy belongs in the identity system, not in user-facing prompts. But that also means governance quality now depends on policy completeness, delegation context, and lifecycle revocation. The implication is that security teams must review whether consent has become an identity policy problem rather than a user experience problem.

Identity blast radius becomes the more useful concept than token validity. A valid access token can still have an excessively large behavioural blast radius when it survives the original user intent, crosses hops, or outlives the grant that produced it. This is the MCP analogue of standing privilege in machine identity, and it belongs in NHI governance reviews, not just OAuth engineering discussions.

Shadow MCP is an inventory failure before it is a protocol failure. The article correctly notes that some servers never touch an authorization server at all, which means they never appear in the normal identity telemetry path. That is a governance assumption collapse: if the enterprise cannot see the server, it cannot govern the grant, and if it cannot govern the grant, it cannot meaningfully scope access. Practitioners should treat unregistered MCP endpoints as unmanaged NHI assets.

Cross-hop provenance is the next control gap after consent. ID-JAG narrows delegation to a single audience, but the enterprise still loses context once an authorised action is forwarded across agents or tools. That means the industry needs to treat provenance as an identity attribute, not just an audit log concern. Security teams should re-evaluate whether their MCP control model can explain who initiated the action after the first hop.

From our research:

• 53% of MCP servers expose credentials through hard-coded values in configuration files, according to the State of MCP Server Security 2025.
• Our research on NHI exposure shows that 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, which confirms that configuration sprawl is still a live identity risk.
• For a broader governance lens, read Ultimate Guide to NHIs for how lifecycle, visibility, and offboarding controls apply to machine identities.

What this signals

Identity blast radius: MCP programmes now need to measure how far a valid grant can travel after issuance, not just whether issuance was successful. The control gap is visible wherever tokens survive beyond the original user intent or move across hops without provenance, and that maps cleanly to the behaviour-based identity graph problem discussed in Ultimate Guide to NHIs.

The operational signal is simple: if your MCP inventory cannot explain who issued, who approved, and where the token is used, your governance model is incomplete. Teams should expect more policy work to move into the IdP and more detection work to move into post-issuance behaviour analysis, aligned with the enterprise authorization patterns in the OWASP Non-Human Identity Top 10.

A second programme signal is the rise of unmanaged MCP endpoints that never pass through the normal authorization stack. That changes discovery and recertification from periodic exercises into continuous inventory discipline, because shadow identity assets do not self-report and do not appear in consent logs. Security teams should plan for MCP visibility to sit alongside their broader NHI inventory programme.

For practitioners

• Separate resource-server and authorization-server responsibilities Map every MCP endpoint to one identity role only. The server should validate tokens and enforce audience, while a distinct authorization server handles issuance and policy. This removes trust ambiguity and prevents the MCP server from becoming its own authority.
• Enforce audience binding on every MCP token Require the resource parameter, validate the audience claim, and reject tokens that were minted for any other server. That blocks cross-server replay and keeps grants tied to the resource that approved them.
• Move enterprise consent into the IdP Use IdP-managed policy decisions for MCP integrations instead of relying on browser prompts or app-local approval flows. Review which delegated grants are still explainable after the user session ends and the app continues to act.
• Inventory shadow MCP servers and unmanaged clients Search for stdio servers, local settings files, and developer-added endpoints that never hit an authorization server. Treat them as unmanaged identity assets until they are registered, governed, and visible in inventory.

Key takeaways

• MCP security is now an identity governance problem, because valid tokens can still drive invalid behaviour across clients, servers, and delegated agents.
• The strongest evidence in the article is that protocol-level correctness does not reveal post-issuance risk, token lifetime drift, or cross-hop provenance loss.
• Practitioners should separate resource-server enforcement, centralize consent in the IdP, and inventory shadow MCP endpoints before they become unmanaged access paths.

Key terms

• Enterprise-Managed Authorization: Enterprise-managed authorization is a policy model in which the identity provider decides what an agent may do and encodes that decision into the token or access flow. It helps organisations keep control logic centralized instead of spreading entitlement decisions across many servers.
• Resource Indicator: A resource indicator is a request-time signal in OAuth that tells the authorization server which resource server the token is meant for. In practice, it helps constrain the resulting token audience so access is tied to one API or logical service instead of being broadly reusable.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.

What's in the full article

SlashID's full article covers the operational detail this post intentionally leaves for the source:

• The full RFC-by-RFC authorization flow, including protected resource metadata, resource indicators, and client registration mechanics.
• The confused-deputy scenario and the consent-cookie failure path across stacked OAuth layers.
• The EMA and ID-JAG exchange details, including the exact delegation sequence and token lifetime behaviour.
• The mapped detection gaps, including identity graph traversal and post-issuance read-burst behaviour.

👉 SlashID's full post covers the RFC flow, EMA details, and the remaining detection gaps after July 28

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.