MCP auth turns least privilege into a runtime design problem

At a glance

What this is: This guide explains how to secure MCP servers with OAuth 2.1, PKCE, metadata discovery, dynamic client registration, JWT validation, and RBAC.

Why it matters: It matters because MCP turns AI clients into active requesters of privileged actions, forcing IAM, NHI, and autonomous governance teams to verify identity, scope, and revocation at execution time.

👉 Read WorkOS's guide to securing MCP authentication with OAuth 2.1

Context

Model Context Protocol is an application layer for AI systems that lets a client call a server to fetch data or trigger actions. In practice, that means the security boundary is no longer a passive API consumer but an active identity that can initiate changes, which is why MCP auth now sits inside IAM and NHI governance rather than beside it.

The article’s core point is that static keys are too blunt for production MCP use. Once a client can create issues, approve refunds, move money, or deploy builds, teams need discoverable authorization, scoped tokens, revocation, and auditable enforcement that map to the same control expectations used for other non-human identities.

Key questions

Q: How should security teams authenticate MCP clients in production?

A: Use OAuth 2.1 for production MCP access, with short-lived scoped tokens and server-side revocation. Treat API keys as temporary only, because they are hard to rotate, difficult to audit, and usually grant too much by default. For public clients, require PKCE so intercepted authorization codes cannot be exchanged into usable tokens.

Q: Why do static API keys create so much risk in MCP environments?

A: Static API keys create risk because they behave like permanent bearer credentials. Anyone who obtains the key can call every permitted function, rotation is disruptive, and the server cannot easily distinguish one client or user from another. That makes incident response and accountability much weaker than with scoped, expiring OAuth tokens.

Q: What breaks when JWT validation is too loose on an MCP server?

A: Loose JWT validation lets the server accept tokens it should reject, which can turn a limited client into an over-privileged one. If issuer, audience, expiry, or scope checks are skipped, the server may execute tool calls for the wrong identity or beyond the intended permission set. That is a server-side trust failure, not a client-side inconvenience.

Q: How do you know whether MCP authorization is actually enforcing least privilege?

A: You know it is working when a token issued for one task cannot access unrelated tools, and when denied requests are blocked before any downstream action occurs. Test the server with intentionally overbroad scopes, expired tokens, and mismatched issuers. If those requests still execute, least privilege is not being enforced.

Technical breakdown

OAuth 2.1 and PKCE for public MCP clients

MCP clients are often public clients, meaning they cannot safely store a client secret. OAuth 2.1 paired with PKCE solves that by binding the authorization code exchange to a one-time verifier instead of a baked-in secret. That removes the main interception risk in browser-based or desktop-based flows and makes delegated access time-limited, scoped, and revocable. In IAM terms, this is the difference between handing out a durable bearer credential and issuing a constrained session that can be invalidated when trust changes. For MCP, that distinction is the foundation of usable least privilege.

Practical implication: require PKCE for all public MCP clients and reject any design that depends on embedded secrets.

Protected resource metadata and authorization server metadata

MCP relies on well-known metadata endpoints so clients can discover how a server expects to be called and which authorization servers it trusts. Protected Resource Metadata tells the client what the resource is, how bearer tokens are accepted, and where signing keys live. Authorization Server Metadata describes token endpoints, grant types, scopes, and PKCE support. This replaces hand-built configuration with machine-readable trust discovery, which reduces setup drift but also creates an enforcement obligation: the server must only advertise what it is prepared to validate. Discovery is not authorization by itself; it is the map that lets authorization happen consistently.

Practical implication: publish accurate metadata, validate every advertised trust relationship, and treat discovery failures as configuration defects.

JWT validation, scopes, and RBAC enforcement at the server

After token issuance, the MCP server still has to prove the token is valid before any tool call runs. That means checking signature, issuer, audience, expiry, and required scopes against the server’s policy. JWTs make authorization portable, but they also make mistakes highly consequential if the server trusts claims it does not verify. RBAC then turns scope into operational control by mapping permissions to roles and enforcing them on the server side. In an MCP context, this is what keeps a client that can request many tools from automatically inheriting all of them. The server, not the client, must decide what the token really allows.

Practical implication: validate JWT claims server-side and enforce scope-to-role mappings before any downstream action executes.

Threat narrative

Attacker objective: The attacker wants to turn a weak or overbroad MCP identity into authenticated access that can trigger privileged actions through connected AI workflows.

1. Entry occurs when an attacker intercepts or reuses a weak MCP credential such as a static API key or an improperly protected authorization code.
2. Credential access happens when the attacker obtains a bearer token that is accepted by the MCP server without sufficient validation or scope restriction.
3. Escalation follows when the token grants broader tool access than intended, allowing actions such as account changes, refunds, or build execution.
4. Impact is achieved when the compromised client identity is used to perform real-world operations on connected systems with little or no effective revocation path.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

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 really an NHI governance problem disguised as a protocol guide. The article describes authentication, metadata, token validation, and RBAC, but the underlying issue is who or what is allowed to act inside a delegated machine identity chain. Once an AI client can initiate state-changing actions, the server-side controls become identity controls rather than application plumbing. Practitioners should treat MCP as part of workload and agent access governance, not just API hardening.

Static credentials fail because they erase the boundary between identification and authorization. API keys give every holder the same durable power, no matter which user, device, or workload is behind the request. That model breaks audibility, revocation, and scope separation, which is why OAuth 2.1 and PKCE matter in MCP. The practical conclusion is that durable keys do not scale to agent-mediated action chains.

Least privilege in MCP depends on server-enforced scope, not client intent. A client can be well-meaning and still overreach if the server accepts broad tokens or trusts claims without verification. This is where NHI governance and ZT principles converge: the identity that asks for access is not the identity that gets to define it. Practitioners should align server policy with verified token claims, not with the client’s declared purpose.

Protected Resource Metadata creates discoverability, but discoverability is not trust. The article shows how metadata can automate configuration across many clients and servers, which is useful at scale. But the same automation also means any error in advertised issuers, scopes, or key locations can propagate quickly. The field should read this as a governance pattern for machine identities, where consistency must be paired with validation.

Named concept: runtime authorization boundary. MCP moves the authorization decision to the point of execution, where an AI client is about to trigger a real action. That boundary is different from traditional login flows because the meaningful control is not who signed in, but what the server permits at tool-call time. Practitioners should treat every MCP server as a policy enforcement point for non-human identity behavior.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• From our research: The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• From our research: Read our Ultimate Guide to NHIs for the governance patterns that matter when a machine identity, not a person, is making the request.

What this signals

Runtime authorization is becoming the control plane for machine identity. As MCP-style integrations spread, teams will need to decide whether their IAM model can validate identity at the moment of action rather than at login. That shift lines up with the NHI security gap we keep seeing in the market: confidence in machine identity controls still trails human IAM by a wide margin, which is why server-side policy enforcement now matters as much as authentication.

Discovery will reduce setup friction, but it will also expose weak governance faster. When metadata endpoints and dynamic registration are used well, they make scaling easier across many clients and servers. When they are used badly, they spread misconfiguration across the environment just as quickly. That is why teams should pair protocol adoption with explicit review of issuer trust, token audience rules, and revocation paths, not treat automation as control maturity.

Policy drift is the real danger in AI client ecosystems. The more an MCP server is used by different hosts and clients, the easier it becomes for scope definitions to expand beyond the original use case. That makes runtime checks, role mapping, and logging essential for any programme that expects to govern AI-driven access in the same way it governs human sign-in flows.

For practitioners

• Replace static keys with scoped OAuth flows Use OAuth 2.1 for production MCP access and reserve API keys for temporary local setups only. Require time-limited tokens, narrow scopes, and explicit revocation paths so the client cannot carry durable privilege across unrelated tasks.
• Enforce PKCE for every public client Reject any MCP client registration or token exchange that does not use PKCE when the client cannot protect a secret. This blocks intercepted authorization codes from being exchanged into usable tokens.
• Validate JWT claims before tool execution Check signature, issuer, audience, expiry, and scope on the server side before any request reaches a tool or downstream API. If any claim is missing or unexpected, deny the call and log the decision.
• Publish and review well-known metadata endpoints Serve Protected Resource Metadata and Authorization Server Metadata only for trust relationships you actively support. Review those documents as part of change management because discovery errors can silently expand the client’s effective trust surface.
• Map scopes to roles with server-side RBAC Translate token scopes into internal permissions on the MCP server and do not rely on the client to self-limit. Keep role definitions narrow so a token issued for one task cannot implicitly authorize another.

Key takeaways

• MCP authentication is an identity governance problem because the client can trigger real-world actions, not just API reads.
• OAuth 2.1, PKCE, metadata discovery, and server-side JWT validation are the controls that keep MCP least-privilege instead of default-permissive.
• If the server does not enforce scope, issuer, audience, and expiry at execution time, the client identity can become over-privileged even when the login flow looks correct.

Key terms

• Model Context Protocol: Model Context Protocol is a standard that lets AI applications connect to external tools and data sources through defined client and server roles. In identity terms, it creates a request path that must be authenticated, authorised, and logged because the caller can trigger meaningful downstream actions.
• Public Client: A public client is an application that cannot safely store a long-term secret, such as a desktop app or browser-based workflow. For MCP, that means the client must rely on proof-of-possession style protections like PKCE rather than embedded credentials that can be extracted and reused.
• Protected Resource Metadata: Protected Resource Metadata is a machine-readable document that tells a client how a resource expects to be called and which authorization servers it trusts. It reduces manual configuration, but it only improves security when the server publishes accurate trust data and validates it consistently.
• Runtime Authorization Boundary: The runtime authorization boundary is the point where a server decides whether a specific tool call is allowed after a token is presented. For AI and non-human identities, this boundary matters because identity is not just about logging in. It is about whether the next action is permitted right now.

Deepen your knowledge

MCP auth, OAuth 2.1, and PKCE are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building governance for AI clients that can trigger production actions, it is worth exploring.

This post draws on content published by WorkOS: The developer’s guide to MCP auth. Read the original.