Auth-ready MCP servers expose the real identity control gap

At a glance

What this is: This is a build guide for an auth-ready MCP server that shows why token issuance, discovery, and claim checks are the real control layer for AI tool access.

Why it matters: It matters because IAM and NHI teams need to treat MCP access as governed identity, not just API plumbing, or they will leave tool invocation decisions outside policy control.

Context

MCP servers create a control problem that looks familiar on the surface but is different in practice: the server is not just exposing endpoints, it is delegating tool use through identity and token claims. In this model, authentication, authorisation, discovery, and token verification become part of the runtime path for every tool call.

Descope’s walkthrough is a build example, but the governance issue is broader than one implementation. If teams treat MCP access like ordinary application access, they miss the fact that the assistant is invoking tools on behalf of a user, and that the request must be bounded by the same permission model that governs the human or non-human identity behind it.

The practical question for IAM is whether the server can prove who is calling, what they are allowed to do, and whether those permissions are carried in a verifiable identity token rather than in the code path or a shared secret.

Key questions

Q: What breaks when an MCP server does not verify identity claims on each tool call?

A: The server loses the ability to distinguish a permitted request from a reused or forged one. Tool access becomes detached from the identity that should govern it, which weakens least privilege, revocation, and auditability. In practice, the assistant may still work, but the organisation no longer knows whether the caller was authorised to use the tool.

Q: Why do MCP servers need OAuth and OIDC instead of a shared API key?

A: OAuth and OIDC let the server issue and validate identity-bound tokens, while a shared API key collapses every caller into the same credential. That difference matters because MCP tools are called on behalf of users or delegated actors. With shared keys, access control and attribution both degrade, and policy enforcement becomes far harder to trust.

Q: How should security teams govern MCP tool access in enterprise environments?

A: Security teams should bind MCP tool access to enterprise identities, entitlements, and lifecycle state before a request reaches production tools. A gateway can enforce policy at the edge, but governance only exists when the identity system knows who is calling, what they are allowed to do, and whether approval or offboarding has already occurred.

Q: When is an MCP integration too risky to run with long-lived credentials?

A: It becomes too risky when the tool can change state, reach third-party systems, or expose sensitive data and the credential cannot be tied back to a specific identity decision. Long-lived secrets make revocation slow and attribution weak, so they are a poor fit for delegated AI tool access.

Technical breakdown

Why OAuth becomes the MCP control plane

An MCP server is effectively an identity-gated tool broker. The client asks for tools, but the server must decide whether the caller is entitled to use them, which is why OAuth and OIDC discovery sit on the critical path. Token issuance, JWKS publishing, and claim encoding are not optional plumbing here. They are the mechanism that turns a conversational tool call into an authorisable request. Once the server accepts that model, the enforcement point moves from the assistant to the server-side handler, where scopes, roles, or custom claims can be checked before any downstream action occurs.

Practical implication: Treat MCP auth as a control plane requirement, not a wrapper around tools.

How JWT claims turn identity into tool permissions

JWT claims carry the permission data that tool handlers consume. Scope claims express coarse entitlement, role claims express policy grouping, and other claims such as email or subject tie the request to a user context. The server verifies the token against a trusted issuer and local JWKS, then checks the claims in each handler. That split matters because the identity system decides what a user gets, while the MCP server decides whether a particular tool requires that entitlement. Without that separation, teams end up hard-coding access logic into the tool itself, which makes governance brittle and difficult to audit.

Practical implication: Map each tool to a claim type and enforce it server-side on every request.

Why local token verification is part of the trust boundary

Token verification at the server matters because it prevents the tool layer from trusting the client or a shared session. The server validates signature, issuer, and audience locally, which means it can reject unauthorised calls without round-tripping to the identity provider. That is a standard security pattern, but in MCP it becomes central because the assistant can be conversational while the permission decision must remain deterministic. The moment teams rely on static API keys or shared service accounts, the identity of the human or delegated actor disappears and the audit trail collapses into one opaque credential.

Practical implication: Verify bearer tokens locally and avoid shared credentials for MCP tool execution.

Threat narrative

Attacker objective: The objective is to invoke MCP tools under borrowed or stale authority and gain actions, data, or downstream API access that the caller should not have.

1. Entry occurs when an MCP client connects through OAuth and receives a bearer token that will be presented to the server on tool calls.
2. Escalation happens if the server accepts a token without verifying issuer, audience, or the claim set that binds the user to specific permissions.
3. Impact follows when a shared credential or stale token lets the wrong caller invoke tools they should not be able to use, collapsing accountability and access control.

Breaches seen in the wild

• Moltbook AI agent keys breach: Moltbook breach exposed 1.5M AI agent keys.
• DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.

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

NHI Mgmt Group analysis

MCP auth is a governed identity problem, not a developer convenience problem. The article makes clear that the real control gap is proving who may call a tool, not wiring the tool itself. OAuth issuance, discovery, and claim validation are the mechanisms that bind conversation to authority. For IAM teams, the lesson is that MCP should be treated as delegated access with policy enforcement at the server, not as a lightweight integration pattern.

Tool access in MCP depends on claims, so claims become the policy surface. Scope, role, and subject claims are the points where entitlement is translated into runtime access. That means the identity team owns the grant, while the MCP server owns the check, and those two functions must remain separate. Practitioners should read this as a reminder that authorization design, not just authentication, determines whether AI-assisted tools are governable.

Shared credentials break the accountability model that auth-ready MCP depends on. The article contrasts bearer-token enforcement with static API keys and shared service accounts, and that contrast is the real governance lesson. When the same credential can be reused across callers, the request no longer carries a durable identity context. The practical implication is that auditability, revocation, and least privilege all weaken at the same time.

Claim-bound tool gating is the missing control pattern for auth-aware AI integrations. This is the named concept that best captures the article’s core finding: tool access becomes governable only when every request is bound to verifiable identity claims. That pattern aligns with OWASP-NHI thinking around non-human access and with Zero Trust principles for request-level verification. Practitioners should use it to frame MCP as an identity boundary, not a code boundary.

Auth-ready MCP exposes how quickly identity architecture becomes a runtime dependency. Once token issuance, discovery, and JWKS rotation sit on the path, operational ownership shifts from the app team alone to IAM, platform, and security engineering together. That is not a product issue, it is a governance model issue. Teams should expect MCP adoption to force clearer lines between entitlement design, server enforcement, and audit logging.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
• Read next: AI Agent Authorisation Guide

What this signals

Claim-bound tool access is the right mental model for MCP governance. If an MCP request is not tied to verifiable identity claims, then the server is effectively trusting a conversation, not a principal. That shifts control from policy to implementation detail and makes revocation, review, and attribution much harder to sustain.

The practical signal for IAM and platform teams is that discovery, issuance, and enforcement now have to be owned as one access path. MCP servers that keep auth logic implicit will create the same kind of sprawl identity teams have spent years removing from application and service-account estates.

For practitioners

• Define MCP as a governed access path Document each MCP server as an access-controlled identity endpoint, with named issuer, audience, and policy owner before production use.
• Separate issuance from enforcement Let the identity provider issue tokens and keep tool handlers focused on verifying claims and denying requests that lack the required scope or role.
• Bind every tool to a claim type Map each sensitive tool to an explicit scope, role, or user attribute so the authorisation rule is visible in code and reviewable in change control.
• Avoid shared credentials in MCP flows Replace static service keys and shared API tokens with per-user or per-session bearer tokens so requests retain a traceable identity context.
• Log claim data at the enforcement point Record scopes, roles, subject, and audience at the MCP handler so denied or permitted calls can be traced back to the identity decision that produced them.

Key takeaways

• MCP servers create an identity decision point at every tool call, so auth design is part of the runtime path, not a wrapper around it.
• The core governance risk is not tool creation but permission binding, because scopes, roles, and claims determine who can act on behalf of the user.
• Static keys and shared credentials erase attribution and weaken least privilege, which is why claim-based enforcement is the practical control boundary.

Key terms

• Auth-ready Mpc Server: An auth-ready MCP server is an MCP endpoint that verifies who can call its tools before any action is executed. It uses an external identity system for token issuance and then enforces scopes, roles, or claims inside the server so delegated tool use stays governed and attributable.
• Claim-based enforcement: Claim-based enforcement is the practice of making authorisation decisions from token contents such as scope, role, subject, or audience. In MCP environments, it keeps the policy decision close to the tool handler while preserving a separate identity source for issuance and authentication.
• Oidc discovery: OIDC discovery is the mechanism that lets a server locate the issuer metadata and public keys it needs to validate tokens. For MCP, it removes hard-coded trust assumptions and allows the server to verify bearer tokens against a known authority and current key set.
• Delegated tool privilege: Delegated tool privilege is the effective authority an AI agent inherits from the systems it can call, even when it is not the owner of those systems. It is the practical blast radius created by connectors, credentials, and runtime permissions. This is often the real control boundary in agentic environments.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.