MCP authorization defines what AI agents can reach through OAuth 2.1

At a glance

What this is: This is a technical explanation of how MCP authorization works and where OAuth 2.1 stops, with the key finding that token validation is not governance.

Why it matters: IAM, PAM, and NHI teams need to treat MCP-connected agents as governed identities because token validity alone does not control privilege scope, approval, or revocation.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.

👉 Read C1.ai's blog on MCP authorization and AI agent access control

Context

MCP authorization is the control layer that decides whether an AI agent can reach a tool or dataset through the Model Context Protocol, but it is not the same as governance. The primary issue is that many teams now have agents operating against production systems through OAuth-based flows while still relying on access models built for human users and static service accounts.

That gap matters because the MCP spec validates tokens, audiences, and refresh flow mechanics, but it does not decide whether a tool should be available, who owns the agent, or whether the grant still makes sense. In identity terms, this is where NHI governance takes over from protocol compliance. The article's starting position is typical: enterprises are adopting agent access faster than they are defining the controls around it.

Key questions

Q: How should security teams govern AI agents that use service accounts and MCP tools?

A: Start with ownership, then add runtime attribution and containment. Security teams should know which human deployed the agent, which identity the agent uses, what tools it can invoke, and when to revoke access. If the agent can chain tool calls or spawn sub-agents, governance must cover those paths as well, not just the initial login.

Q: Why do OAuth misconfigurations create NHI governance risk?

A: OAuth misconfigurations create NHI governance risk because tokens, proxies, and linked accounts act like non-human identities with delegated access. If their scope, storage, or identity binding is weak, one bad decision can expand access across multiple applications and automation paths.

Q: What breaks when teams rely on MCP authorization instead of identity governance?

A: Approval, ownership, and recertification break first. MCP authorization can validate a request to a server, but it cannot tell you whether the agent was sanctioned, whether the scope is still appropriate, or whether the entitlement should be removed when the project ends.

Q: How do organisations reduce shadow MCP server risk?

A: By inventorying every MCP server, including local and developer-run instances, and tying each one to a known owner and approved identity source. If a server can be created outside central governance, it should be treated as an unmanaged NHI path until proven otherwise.

Technical breakdown

How MCP authorization uses OAuth 2.1 for tool access

MCP authorization is built on OAuth 2.1, which gives the protocol a familiar pattern for token issuance and validation. The MCP client, often an AI agent or AI application, acts as an OAuth client. The MCP server behaves as a resource server, and the authorization server is usually the enterprise identity provider. Discovery uses WWW-Authenticate headers and protected resource metadata, while dynamic client registration lets new clients register at runtime. PKCE is mandatory for public clients, and refresh tokens support long-running sessions without forcing repeated logins.

Practical implication: security teams should map every remote MCP server to a known authorization server and confirm audience validation is enforced.

Why token validation is not the same as access governance

The spec answers a narrow question: is this token valid for this server? It does not answer whether the agent should have the tool, whether the access was approved, or whether the entitlement is still appropriate. That boundary is important because OAuth can authenticate a call without expressing business ownership or lifecycle state. In practice, this means an agent can have a technically valid token while still representing a governance failure if the scope is stale, over-broad, or disconnected from an accountable owner.

Practical implication: teams need separate policy for approval, ownership, recertification, and revocation instead of assuming OAuth solves those controls.

Why shadow MCP servers and orphaned agents create NHI risk

When sanctioned access is awkward, teams create local or unsanctioned MCP servers and attach personal API keys or other environment credentials. That turns governance into a shadow inventory problem. Orphaned agent identities are another risk: dynamic registrations and refresh tokens do not revoke themselves when an engineer leaves or a project ends. Over time, the environment accumulates access paths that are technically functional but no longer accountable, which is a classic NHI failure mode even when the protocol is working as designed.

Practical implication: inventory remote and local MCP servers, bind each agent to a named owner, and revoke registrations when the operational need ends.

NHI Mgmt Group analysis

OAuth validation is a transport control, not an identity governance decision. The MCP authorization layer proves that a token is valid for a server, but it does not decide whether the agent should still have access or whether the access was ever properly owned. That distinction matters because many programmes conflate protocol security with lifecycle governance. Practitioners should treat MCP as the pipe and governance as the policy layer that decides who may use it.

Shadow MCP servers are an NHI inventory failure before they become a security failure. The article correctly notes that teams will route around friction by standing up their own servers with personal keys or other local credentials. That is not just an access shortcut, it is the creation of unmanaged non-human identities outside the approval and review process. The implication is that visibility and ownership need to cover every server, not just the sanctioned ones.

Ephemeral agent access creates an identity blast radius that human-centric reviews cannot see in time. Agents can request, refresh, and reuse access at machine speed, while review cycles still operate on human cadence. That mismatch means stale grants can persist long after the operational need has changed. For practitioners, the governing question is no longer whether the token is valid, but whether the access path remains legitimate across the agent's lifecycle.

Named concept: agent access governance gap. This article exposes the gap between a standards-based authentication flow and the harder question of who owns, approves, and revokes agent access. OAuth 2.1 can authenticate the transaction, but it cannot certify intent or business need. Security teams should recognise this as a governance boundary, not a tooling deficiency.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to the Ultimate Guide to NHIs.
• 79% of organisations have experienced secrets leaks, and 77% of those incidents resulted in tangible damage, according to the Ultimate Guide to NHIs.
• For a broader governance baseline, see Top 10 NHI Issues for the recurring control failures teams keep underestimating.

What this signals

Agent access governance gap: MCP will keep expanding as the default integration layer for AI agents, which means identity teams need to separate protocol trust from entitlement trust. The practical shift is toward lifecycle ownership, revocation, and approval logic that can operate at machine speed, not human queue speed.

The operational risk is not just valid tokens, but accumulated access paths that nobody actively owns. As agents proliferate, teams should expect more local MCP deployments, more shadow registrations, and more stale grants unless governance is built into the agent lifecycle from the start.

MCP adoption also reinforces a wider NHI pattern: when the access path is easy, accountability drifts. That makes inventory, ownership, and instant revocation the controls to prioritise before agent sprawl turns into durable privilege.

For practitioners

• Define ownership for every MCP-connected agent Assign a named human owner and an accountable business purpose to each agent, then require that ownership to exist before any token or registration is approved.
• Separate token validity from access approval Use OAuth 2.1 for authentication and token validation, but keep tool approval, least privilege, and recertification in your identity governance process.
• Inventory remote and local MCP servers Track both internet-facing and STDIO-based servers, because local deployments can bypass the OAuth flow and still consume environment credentials.
• Revoke stale agent registrations and refresh paths Tie dynamic client registrations, refresh tokens, and upstream entitlements to lifecycle events so decommissioned agents lose access without waiting for a manual cleanup.

Key takeaways

• MCP authorization secures the token exchange, but it does not decide whether an AI agent should still have access.
• The main governance risk is stale, orphaned, or shadow agent access that OAuth can validate but never meaningfully approve.
• Identity teams should manage MCP-connected agents as NHIs with named owners, lifecycle controls, and fast revocation paths.

Key terms

• MCP authorization: MCP authorization is the control layer that decides whether an agent or client may use a specific tool in a specific context. In secure deployments, it must go beyond token claims and incorporate user identity, resource ownership, and policy at request time.
• Dynamic Client Registration: Dynamic client registration is a protocol pattern that allows a software client to register itself with an authorization system automatically. For AI agents, it can reduce manual setup, but it also creates new identities at speed, which makes ownership, policy checks, and revocation essential.
• Audience Validation: Audience validation checks that a token was issued for the exact service receiving it. In MCP, this prevents a valid token for one server from being reused elsewhere, which is critical because agent-driven workflows often move across multiple tools and trust domains.
• Shadow MCP Server: An MCP server that exists in an environment without being fully visible, approved, or governed by the teams responsible for identity and access. In practice, it becomes a hidden trust path for tools, data, and credentials, especially when developers install it directly into agent workflows.

What's in the full article

C1.ai's full blog covers the operational detail this post intentionally leaves for the source:

• Step-by-step MCP discovery, registration, and token exchange flow for remote servers
• The role of WWW-Authenticate headers, PKCE, refresh tokens, and audience validation in the protocol
• Practical examples of how the spec differs for HTTP transport versus local STDIO servers
• C1.ai's framing of agent ownership, just-in-time approval, and speed of access decisions

👉 C1.ai's full post covers the OAuth 2.1 flow, local transport boundary, and governance gaps in more detail.

Deepen your knowledge

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