MCP auth turns least privilege into a runtime design problem

At a glance

What this is: This guide explains how MCP authentication and authorization should be built with OAuth 2.1, PKCE, discovery metadata, dynamic registration, JWT validation, and RBAC so AI clients can be scoped and revoked safely.

Why it matters: IAM and platform teams need to treat MCP as a runtime access-control problem because AI clients can perform consequential actions, and weak token handling turns delegated access into standing privilege.

Context

MCP authentication is not just about proving identity. It is about governing what an AI client can do, when it can do it, and how quickly that access can be withdrawn when the context changes. For IAM teams, that makes MCP a runtime authorisation problem rather than a one-time onboarding task.

The article focuses on AI clients that interact with MCP servers and can trigger external actions such as changing account state, approving refunds, or deploying builds. In that model, the security gap is not the protocol itself but the assumption that setup-time controls are enough for behaviour that unfolds during execution.

Key questions

Q: How should security teams handle secrets when connecting LLM clients to MCP servers?

A: Security teams should treat MCP credentials like any other privileged secret and keep them out of untrusted forms, shared dashboards, and long-lived server storage. The safer pattern is local injection through environment variables or other host-controlled secret stores, paired with least privilege and periodic review of which tools the agent can reach. That limits exposure if the server, client, or configuration path is compromised.

Q: Why does MCP turn least privilege into a runtime problem?

A: Because the AI client can request, receive, and use access during the same task, so the meaningful security decision happens when the request is made, not when the integration is set up. Tokens, scopes, and server checks have to align on every call, otherwise delegated access becomes broader and longer-lived than intended.

Q: What are the signs that an MCP authorization model is too loose?

A: Warning signs include token passthrough between components, broad token scopes, shared sessions for workloads, and redirect URI patterns that accept wildcards or partial matches. If the server cannot prove which client requested which operation, the authorization model is relying on inherited trust rather than explicit control.

Q: What should IAM teams review before allowing MCP in production?

A: IAM teams should review how the protocol establishes identity, how tool permissions are assigned, and whether the same policy is enforced consistently across clients. If the answer differs by implementation, the organisation has a governance gap that can produce uneven access and weak audit trails.

Technical breakdown

OAuth 2.1 and PKCE for public MCP clients

MCP clients are often public clients, which means they cannot safely hold a client secret. OAuth 2.1 with PKCE replaces embedded secrets with a verifier and challenge pair so the client can prove continuity without storing a reusable credential. That matters because an intercepted authorization code is useless without the original verifier. In MCP, this shifts trust away from static client secrets and toward ephemeral proof of possession plus server-side token validation. The practical effect is that authentication can survive open-network transport without turning the client into a secret container.

Practical implication: Use PKCE for all public MCP clients and treat embedded client secrets as an anti-pattern.

Protected Resource Metadata and Authorization Server Metadata

MCP relies on machine-readable discovery rather than hardcoded trust. Protected Resource Metadata tells a client which authorization servers, bearer methods, and signing key locations the MCP server accepts. Authorization Server Metadata tells the client how the issuer works, including token and registration endpoints, supported scopes, and grant types. This removes brittle per-environment configuration and makes trust relationships explicit at runtime. For identity teams, the key point is that discovery becomes part of the security model, not just an interoperability convenience.

Practical implication: Publish and validate well-known metadata endpoints so clients can discover trusted auth settings without manual configuration.

JWT validation and delegated scope enforcement

Once a client presents a token, the MCP server has to validate issuer, audience, expiry, signing key, and scope before any tool call executes. A JWT is not an access decision by itself; it is a signed assertion that still needs contextual checks against the server that receives it. That is especially important in MCP because the same token can otherwise be reused across tools or environments if audience and scope checks are weak. The architectural lesson is that authorization must live at the server boundary where action occurs.

Practical implication: Enforce issuer, audience, expiry, and scope checks before every MCP action and reject tokens that do not match the server boundary.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Least privilege in MCP is a runtime control, not a provisioning event. The article correctly shows that AI clients can move from authenticated access to real-world action inside the same execution path, which collapses the old assumption that access can be safely defined once and reviewed later. OAuth 2.1, PKCE, metadata discovery, and JWT validation only work as a control system when they are enforced at the moment of use. The practitioner takeaway is that MCP governance must be designed around request-time decisions, not onboarding checklists.

Public clients force identity teams to abandon secret-centric trust. PKCE exists because most MCP clients cannot protect a stored client secret, and that changes the security baseline for AI-facing integrations. The useful shift here is not just stronger login flow design, but recognition that static credentials are the wrong trust primitive for software that ships widely and operates in uncontrolled environments. Practitioners should treat public-client handling as a distinct identity pattern, not as a weaker version of server authentication.

Protected Resource Metadata makes trust discoverable, which is now a governance requirement. When an MCP server publishes its security configuration, the authorization model becomes observable and inspectable rather than hidden inside application code. That is important because token acceptance, issuer trust, and key discovery are all part of the effective control surface. The named concept here is runtime authorization discovery: the policy envelope must be readable by clients and enforceable by servers at the same time. Teams should regard undocumented trust paths as a design defect.

JWT validation is the point where delegated access becomes accountable or unsafe. The article’s emphasis on issuer, audience, expiry, and scopes shows that the token is only as safe as the server’s validation boundary. If those checks are incomplete, delegated access can outlive its intended purpose and cross into unintended tools or environments. For IAM architects, this means MCP belongs in the same control conversation as RBAC, token lifecycle, and auditable access decisions, not in a separate AI exception category.

From our research library:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems. Organisations failing to scope AI access properly are 4.5x more likely to experience a security incident, according to the 2026 Infrastructure Identity Survey.
• Read next: AI Agent Authorisation Guide

What this signals

Runtime authorization discovery: MCP security works best when trust relationships are published and validated at request time, not buried in application defaults. That makes discovery metadata, token verification, and scope enforcement part of the same control plane rather than separate tasks.

MCP adoption increases pressure on IAM teams to distinguish public clients from confidential ones and to remove any dependence on embedded secrets. OAuth 2.1 and PKCE are the practical baseline, but the bigger programme change is to treat delegated AI access as something that must be governed at the boundary where action is executed.

For practitioners

• Implement PKCE for all public MCP clients Treat every browser-mediated or distributed client as unable to safely store a secret. Require verifier and challenge handling, and reject authorization code exchanges that do not present the original verifier.
• Publish protected resource metadata Serve a well-known discovery document so clients can learn trusted authorization servers, supported bearer methods, and key locations before any tool call is attempted.
• Validate JWTs at the server boundary Check issuer, audience, expiry, signing keys, and required scopes before executing an MCP tool action. If the token does not match the server and action, fail closed.
• Map OAuth scopes to internal roles Translate token scopes into explicit roles and permissions so the MCP server enforces least privilege instead of inheriting broad access from the login flow.
• Design revocation as a runtime control Ensure client access can be disabled without waiting for app redeployments or manual cleanup, so access can be withdrawn as soon as the trust context changes.

Key takeaways

• MCP auth depends on runtime enforcement, because AI clients can act on delegated access during the same session in which the token is issued.
• Discovery metadata, PKCE, and JWT validation are the core controls that make MCP integrations auditable and revocable.
• IAM teams should validate the server boundary first, because weak scope checks and hardcoded secrets turn delegated AI access into standing privilege.

Key terms

• Protected Resource Metadata: Protected resource metadata is machine-readable discovery data published by a service so clients can find its authorization expectations. For agent registration, it tells the actor where to look for supported flows and how to discover the trust model without relying on ad hoc integration.
• 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.
• Public Client: A public client is an application that runs in an environment the operator does not fully control, such as a browser, phone, or desktop device. Because users can inspect its code and runtime, it cannot safely hold secrets that require custody, confidentiality, or reliable rotation.
• JWT Validation: JWT validation is the process of checking that a token is signed correctly and that its claims match what the application expects. For OIDC, that means verifying issuer, audience, and expiration, not just decoding the token and trusting its contents.

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 building or maturing an IAM programme, it is worth exploring.