MCP server authentication gaps are now an IAM problem

At a glance

What this is: This is a practitioner analysis of how XMCP and AuthKit are used to add OAuth2 authentication to MCP servers, with the key finding that MCP server security now depends on identity-bound access control rather than tool exposure alone.

Why it matters: It matters because IAM teams must govern MCP access as part of NHI and AI tool identity, not treat it as a developer convenience layer that sits outside policy, lifecycle, and audit controls.

By the numbers:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
• 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 WorkOS's XMCP and AuthKit guide for securing MCP servers

Context

MCP security is no longer just a tooling concern. Once MCP servers expose callable tools to LLMs and other agents, the core question becomes who or what is allowed to invoke those tools, under which identity, and with what scopes.

For IAM and NHI teams, that means the server boundary has to move from "can the tool be reached" to "can the request be authenticated, scoped, and tied back to a governed identity." In practice, that brings OAuth, claim handling, session context, and lifecycle controls into the MCP deployment model.

The article's example is a typical starting point for teams trying to secure AI tool access quickly, which makes it useful as a baseline for understanding where lightweight developer ergonomics collide with enterprise access governance.

Key questions

Q: How should security teams govern access to MCP servers in production?

A: Security teams should treat MCP servers as protected resources and require identity-bound access at the protocol boundary. That means validating tokens, enforcing narrow scopes, and tying every tool call to a known caller context. If the server cannot prove who invoked the tool and under what authority, the request should fail closed.

Q: Why do MCP servers create new IAM and NHI governance risks?

A: MCP servers expose tools in a way that can bypass the access assumptions many teams built for human-operated applications. They make protocol-level invocation, delegated access, and client registration part of the trust boundary. That creates risk when permissions are broad, identities are weakly scoped, or lifecycle ownership is unclear.

Q: What do teams get wrong about securing AI tools with OAuth?

A: Teams often assume OAuth alone solves the problem, but OAuth only works when scopes, issuer trust, and token validation are enforced correctly inside the server. If the MCP tool accepts broad tokens or ignores request context, authentication exists in name only. Governance has to extend to each tool call, not stop at sign-in.

Q: How can organisations tell if an MCP server is actually governed?

A: An MCP server is governed when every client is registered, every request is authenticated, and every tool invocation can be traced back to a specific identity and scope. If access cannot be reviewed, revoked, or audited with confidence, the server may be running, but it is not yet under control.

Technical breakdown

OAuth resource servers and MCP tool access

The June 2025 MCP specification updates are central here because they position MCP servers as OAuth resource servers, not authorization servers. That distinction matters: the server consumes identity and access tokens, it does not become the policy authority itself. In practice, the MCP server must validate bearer tokens, inspect claims, and enforce its own access boundary against the scopes and identity attributes carried in the request. This is a classic NHI control pattern, but applied to AI-callable tools where the requester may be an application, user, or agentic workflow.

Practical implication: treat MCP servers as protected resources that must validate identity before every tool invocation.

Dynamic client registration and discovery

Dynamic client registration is what makes MCP auto-discovery workable, because the client can register itself and obtain the metadata needed to talk to the server. That convenience also changes the governance problem. Discovery reduces friction, but it can also widen the number of clients that can appear legitimate unless registration, redirect handling, and issuer trust are tightly controlled. In an identity programme, the important detail is not that registration exists, but that it becomes part of the trust boundary for every agent, app, or user consuming the server.

Practical implication: govern registration, redirects, and issuer trust as production controls, not setup steps.

JWT verification and tool-level context propagation

When a tool receives an Authorization header and verifies the JWT against a remote JWKS, the server is turning token validation into an executable trust decision. The claims inside the token become the basis for context propagation, which can include user identity, organisation membership, or MFA state. That is useful, but it also means the token becomes the governance anchor for downstream decisions. If token validation is weak, stale, or overly broad, every tool call inherits that weakness. For MCP, authentication and authorisation are inseparable from tool design.

Practical implication: bind tool execution to verified token claims and reject any request that cannot be tied to a governed identity.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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

NHI Mgmt Group analysis

Authentication is now the control plane for MCP, not a wrapper around it. Once tools are callable by LLMs through protocol rather than hardcoded integration, access control shifts from application plumbing to identity governance. The article shows that a secure MCP server depends on token validation, scope enforcement, and user context propagation. That is an NHI problem first and a developer-experience problem second. Practitioners should treat MCP exposure as an access surface that requires the same governance discipline as any other machine-facing resource.

Scoped identity is the missing boundary in most MCP deployments. A callable tool is not safe because it is structured or self-describing. It is safe only when the server can distinguish who is calling, what they are allowed to do, and which scopes apply to each invocation. Without that boundary, MCP becomes a thin transport layer over over-broad access. Teams should re-evaluate whether their current tool permission model is tied to real identity attributes or merely to deployment convenience.

Identity context must travel with the request or governance fails downstream. The post's JWT example matters because it turns user and organisational context into an enforceable signal inside the tool. That aligns with Zero Trust thinking: trust should be derived at request time, not assumed from network location or application membership. For IAM teams, the practical lesson is that MCP security cannot be bolted on after integration. It must be built around authenticated context from the start.

MCP tool security is becoming a new NHI lifecycle problem. Tools, registrations, client credentials, and issuer relationships all have to be owned, reviewed, and retired. As MCP spreads, organisations will need to answer who approved a client, how its access was scoped, and when that access should be removed. The governance question is no longer whether the tool works, but whether its identity and access state is continuously defensible.

Ephemeral tool access changes the shape of least privilege for AI systems. MCP invites short-lived, task-specific interactions, but short-lived does not automatically mean least privileged. The server still has to prove that each request sits inside an approved identity boundary. Practitioners should expect MCP to expose where policy is still defined for applications, not for tool calls made on behalf of people or automated workflows.

From our research:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
• Only 33% of organisations report their AI agents have accessed inappropriate or sensitive data beyond their intended scope, which shows the control problem is already operational rather than theoretical.
• For a broader control lens, see OWASP Agentic Applications Top 10 for how tool misuse and privilege abuse are framed in agentic systems.

What this signals

Scoped identity debt: MCP adoption will expose where teams have treated tool access as a developer integration issue instead of an identity governance issue. The next control gap will be auditability, because every unscoped client registration expands the number of identities that must be owned, reviewed, and retired.

As MCP moves into production workflows, the practical decision is no longer whether to add authentication, but how to bind request context to policy without breaking tool usability. That is why authentication, scopes, and lifecycle ownership need to be designed together, not layered on later.

With 53% of MCP servers exposing credentials through hard-coded values in configuration files, the security baseline is already weak in many deployments. Teams that cannot account for secrets, client registrations, and tool scopes in the same inventory will struggle to prove governance when these servers start handling sensitive data.

For practitioners

• Classify every MCP server as a governed resource Assign an owner, sensitivity tier, and access policy to each MCP endpoint before it is exposed to users, internal agents, or external clients. Map the server to an explicit identity boundary so that tool invocation is not treated as a developer-only concern.
• Enforce token validation at the tool boundary Require every request to present a valid bearer token, verify the issuer against the configured AuthKit domain or equivalent IdP, and reject calls that cannot be tied to a trusted JWKS. Do not rely on network controls to compensate for missing request authentication.
• Scope tools by identity attributes and task context Use claims such as organisation membership, role, and authentication strength to limit what a caller can do inside the tool. Keep scopes narrow and task-specific so that a shared MCP server does not become a blanket entry point for unrelated workflows.
• Review client registration as part of lifecycle governance Track which clients are registered, who approved them, which redirect URIs they use, and when those registrations should be revoked or revalidated. Treat registration records as lifecycle assets, not one-time setup artifacts.
• Log identity context with every tool invocation Persist the caller identity, scopes, and relevant claims alongside tool execution logs so that investigations can reconstruct who accessed what, under which conditions, and with which authorisation state. Without that data, MCP activity becomes difficult to audit after the fact.

Key takeaways

• MCP servers turn AI tool access into an identity governance problem because requests must be authenticated, scoped, and auditable at the protocol boundary.
• The real exposure is not tool discovery alone, but the combination of broad scopes, weak client registration controls, and token validation that does not reach the tool layer.
• Practitioners should govern MCP servers like any other privileged resource: assign ownership, verify identity on every call, and tie access to lifecycle review.

Key terms

• Mcp Resource Server: An MCP resource server exposes tools and data in a way that clients and agents can call through the protocol. In identity terms, it is a protected resource that must authenticate callers, evaluate scopes, and make authorisation decisions on each request.
• Dynamic Client Registration: Dynamic client registration lets an MCP client register itself so it can discover and use the server. In practice, it is a trust boundary, because the registration process determines which clients exist, which redirect URIs they use, and whether they remain valid over time.
• Token Bound Tool Invocation: Token bound tool invocation means the server only executes a tool when the presented access token is verified and linked to the request. This makes the token a governance artefact, not just an authentication artefact, because its claims drive the tool's trust decision.

Deepen your knowledge

MCP server authentication and scoped access are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are trying to bring tool access, secrets, and lifecycle control into one governance model, it is worth exploring.

This post draws on content published by WorkOS: XMCP + AuthKit for securing MCP tools and servers. Read the original.