MCP authentication shows where AI agent identity breaks down

At a glance

What this is: This is a guide to MCP authentication and authorisation, and its key finding is that OAuth 2.1 standardisation helps, but MCP servers still inherit substantial identity and governance burden.

Why it matters: It matters because MCP can sit inside NHI, agentic AI, and enterprise IAM programmes at once, so the way authentication is implemented affects privilege scope, delegation, and control ownership across all three.

By the numbers:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.

👉 Read WorkOS's guide to MCP authentication and authorisation patterns

Context

Model Context Protocol, or MCP, standardises how AI systems connect to tools, APIs, and data sources. In practice, that means authentication and authorisation become part of the runtime control plane rather than a wrapper around a simple login flow, which is why MCP authentication has become a primary governance question for AI-native environments.

The problem for identity teams is that the protocol pushes traditional IAM ideas into a setting where models initiate actions, clients bridge sessions, and servers may handle sensitive data or high-impact operations. That creates a control gap when access is granted to a tool path but not consistently scoped, reviewed, or offboarded like other non-human identities.

For practitioners building MCP into production workflows, the relevant question is not whether the protocol is modern enough. It is whether the identity model behind it can support task-scoped access, delegated authority, and revocation without turning every server into a mini identity provider.

Key questions

Q: How should security teams handle trust assumptions when using MCP authentication?

A: Treat MCP as a delegated access model, not a simple login wrapper. The trust decision should cover the client, the server, the external identity provider, and the tool scope attached to the session. If any one of those layers is broad or implicit, the model can reach more than the task requires. Narrow scope and explicit ownership are the controls that keep the flow governable.

Q: Why do MCP servers create new identity governance challenges for IAM teams?

A: Because the server often becomes part of the authorisation path, not just the application path. That means the server may need to manage tokens, validate upstream identity, and enforce tool-level permissions while still behaving like a normal service. IAM teams should expect server-side token handling to be governed like other non-human identity infrastructure, not treated as a minor integration detail.

Q: When does API key authentication become too risky for MCP workloads?

A: API keys become risky when they are reused across tasks, shared across environments, or attached to servers that can reach sensitive systems. At that point, the key is no longer a narrow service credential. It becomes a standing privilege path that is difficult to scope, audit, and revoke cleanly. User-scoped OAuth patterns are usually safer where task identity matters.

Q: What should teams do when an MCP server must rely on a third-party identity provider?

A: Define the server’s role in the delegation chain before deployment. If the server still issues its own access token after upstream validation, that intermediate step needs logging, scope controls, and revocation handling. Teams should not assume the external provider removes the server’s governance burden, because the MCP server still remains an identity boundary.

Technical breakdown

OAuth 2.1 in MCP authentication

MCP’s authorisation model uses OAuth 2.1 to make delegated access more predictable across clients and servers. PKCE reduces interception risk, metadata discovery removes much of the manual endpoint wiring, and dynamic client registration lets new clients join without hardcoded setup. That combination is useful because MCP often sits between a model and multiple downstream services, where identity needs to travel with the request but remain scoped. The architectural shift is that the server no longer just answers a tool call. It becomes part of the trust boundary that establishes who can invoke which tool, under what session context, and with what external identity source.

Practical implication: Treat OAuth 2.1 metadata, client registration, and token scope as production controls, not setup details.

API keys and user-scoped access in MCP servers

MCP servers still use API keys in many deployments, especially for local or service-level access. In those cases, the key is both an identity token and a privilege carrier, which makes storage location and runtime injection part of the security design. The article also describes OAuth device flow for user-level access, where the server initiates a consented login and receives a token tied to the user. That creates a split between static service access and explicit user delegation, which is useful operationally but easy to confuse when teams reuse the same server pattern across both cases.

Practical implication: Separate static service credentials from user-consented tokens and scope each to a different trust model.

Why MCP servers become identity infrastructure

The article’s main operational tension is that MCP servers are asked to behave like lightweight tool endpoints while also carrying responsibilities normally associated with identity infrastructure. If a server must issue, store, validate, and potentially refresh tokens, it inherits compliance, logging, and session-management obligations. That burden is especially visible when the server relies on a third-party identity provider, because the MCP spec still expects the server to generate its own access token bound to the upstream session. In other words, the protocol distributes trust, but it does not eliminate the server’s role as an authorising intermediary.

Practical implication: Decide explicitly whether the MCP server is a tool endpoint, a delegated auth layer, or both.

Threat narrative

Attacker objective: The attacker seeks to turn a trusted AI tool connection into unauthorized access to data, actions, or downstream systems through over-scoped identity delegation.

1. Entry occurs when an MCP client or server is allowed to authenticate with broad or weakly scoped credentials, such as exposed API keys or an overly permissive OAuth client registration path.
2. Credential access or abuse follows when the token or key is reused beyond the intended task boundary, giving the model or client access to tools, APIs, or data it should not reach.
3. Impact occurs when a trusted MCP session can invoke high-value actions or sensitive data access through a server that lacks precise scoping, revocation discipline, or session-bound control.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

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

NHI Mgmt Group analysis

OAuth standardisation does not solve the governance problem if the server still becomes the identity choke point. MCP can make auth flows cleaner, but cleaner flows are not the same as lower governance burden. When the server must still issue its own scoped token, validate upstream sessions, and preserve auditability, the identity control plane shifts rather than disappears. The implication is that teams should treat MCP servers as governed access intermediaries, not as simple integration endpoints.

API keys in MCP are a familiar control pattern that becomes fragile the moment the tool chain is shared across users, tasks, and environments. A key that is acceptable for a local server may be inappropriate when the same pattern reaches customer data, internal tooling, or model-driven workflows. The article exposes a classic NHI problem: static credentials inherit privilege assumptions that do not survive context switching. Practitioners should interpret this as a scope-management problem, not a syntax problem.

Least privilege in MCP is only meaningful when tool scope, session scope, and identity scope are aligned. The article makes clear that authentication alone does not prevent overreach if the authorisation boundary is broad or optional. This is where NHI governance meets protocol design. If the server can access many tools but only some are needed for a task, the mismatch is not theoretical. Teams should read this as a privilege partitioning issue across the full MCP execution path.

Dynamic client registration improves usability, but it also broadens the attack surface for trust establishment. A registration model that scales well can also make it easier to provision clients faster than governance can keep up. That matters because many identity failures are not token failures, they are onboarding failures. Practitioners should see DCR as a lifecycle control surface that needs policy, review, and revocation discipline from day one.

MCP is creating an identity pattern that sits between human IAM and NHI governance, which is exactly why generic controls will be misapplied. Human sign-in habits do not cover service-level delegation, and classic machine identity handling does not fully address model-initiated actions. The category is converging on a runtime authorisation layer with its own assumptions about consent, scope, and session continuity. The practical conclusion is that identity teams must classify MCP workloads explicitly instead of folding them into generic application authentication.

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.
• Only 30.9% of organisations store long-term credentials directly in code, which shows that hardcoded secret exposure is not confined to AI-native protocols.
• MCP teams should pair protocol design with lifecycle discipline, and the Guide to the Secret Sprawl Challenge is the clearest next step for hardcoded secret exposure.

What this signals

Secret sprawl is the real MCP risk multiplier: when credentials sit in configuration files, rotation and offboarding cannot keep pace with tool growth. The NHI governance lesson is simple, access that is easy to provision is often harder to retire, and that gap is where MCP deployments drift from controlled delegation into standing privilege.

With 71% of NHIs not rotated within recommended time frames, the baseline problem is already broader than MCP alone. MCP simply makes the consequence more visible because the protocol binds tool access, session context, and external identity into one flow. Teams that already struggle with rotation should expect MCP to amplify that weakness unless lifecycle ownership is explicit.

For identity programmes that are standardising on OAuth-based delegation, this is the point to connect MCP work to broader NHI controls and the NIST Cybersecurity Framework 2.0. Authentication is only one part of the control story. The harder question is whether the organisation can prove who can act, for how long, and how quickly that access can be withdrawn.

For practitioners

• Classify each MCP server as an identity control point Document whether the server is acting as a tool endpoint, a delegated authorisation layer, or a mixed trust boundary. Tie ownership to IAM, platform, and application teams so token issuance, validation, and revocation are not left ambiguous.
• Separate API-key use from user-consented delegation Use static keys only for tightly bounded service-to-service access and reserve OAuth device flow or equivalent user-consented patterns for user-scoped actions. Enforce different scopes, different rotation rules, and different logging expectations for each model.
• Require explicit tool scoping for every MCP deployment Define which tools, data sources, and actions are available to each client or session, then review that mapping during change control. If the server can reach multiple systems, do not let every client inherit the full surface by default.

Key takeaways

• MCP authentication improves standardisation, but it does not remove the need for strict identity governance around clients, servers, and delegated tools.
• The biggest operational risk is not OAuth itself, but the tendency to let MCP servers become broad identity boundaries with weak tool scoping.
• Practitioners should separate static service access from user-consented delegation and treat MCP servers as governed non-human identity infrastructure.

Key terms

• Model Context Protocol: A standard way for AI systems to connect to tools, APIs, and data sources through a shared interface. In identity terms, MCP matters because it turns tool access into a governed delegation problem, where authentication, authorisation, and session scope must follow the model’s runtime behaviour.
• Dynamic Client Registration: A mechanism that lets a client register with a server without a manual setup step. For MCP, this improves scale but also creates a lifecycle control surface, because onboarding speed can outpace review, ownership assignment, and revocation discipline if the process is not governed.
• OAuth 2.1: An authorisation framework for delegated access that improves security over older OAuth patterns through stronger defaults such as PKCE. In MCP, it becomes the backbone for deciding who can act, but it still needs careful scope design and token handling when the server sits inside the trust boundary.
• Tool Scoping: The practice of limiting which tools, actions, or data sources a client can reach within a given session. In MCP environments, tool scoping is the difference between controlled delegation and broad standing privilege, especially when the same server can reach multiple systems.

Deepen your knowledge

MCP authentication and authorisation are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building delegated access controls for AI-native tools or service accounts, it is worth exploring.

This post draws on content published by WorkOS: Introduction to MCP authentication. Read the original.