TL;DR: MCP has moved from no authorization framework in November 2024 to a recognizable OAuth 2.1 and OpenID Connect profile by July 2026, according to NetFoundry, but token passthrough, risky client registration, and skipped audience checks still undermine real deployments. The standard is mature; the governance gap is whether teams enforce the audience-bound, least-privilege model in practice.
At a glance
What this is: MCP now follows a recognisable OAuth 2.1 and OpenID Connect pattern, but common deployments still weaken it through token passthrough, loose client registration, and weak audience checks.
Why it matters: IAM and platform teams need to treat MCP as an identity and trust boundary, because authentication alone does not stop agents from reaching the wrong tools or reusing tokens outside their intended audience.
Context
MCP has become the connection layer many AI agents use to reach tools and data sources, which makes its authorisation model a governance issue rather than a purely protocol-level detail. The core question is whether a server treats every request as an identity decision with scope, audience, and lifecycle, or as a convenient pipe for tokens.
The protocol’s evolution shows how quickly a new integration layer can move from ad hoc access to a recognisable enterprise pattern. The remaining risk is not the existence of OAuth style controls, but whether deployments actually apply them consistently across clients, servers, and upstream APIs.
Key questions
Q: What breaks when an MCP server passes client tokens to upstream APIs?
A: Token passthrough creates confused deputy risk because downstream services may accept a token that was issued for a different audience. That breaks authorization boundaries and can expose data or actions beyond the original MCP request. Each upstream dependency should receive its own token with its own audience and scope.
Q: Why do skipped audience checks increase risk in MCP deployments?
A: Skipped audience checks let a valid token be accepted by the wrong resource server, which turns a scoped credential into a reusable bearer token across boundaries it was never meant to cross. That is how mix-up and replay problems persist even when the authentication flow itself looks correct.
Q: How should teams govern MCP clients before production rollout?
A: Treat MCP clients as governed identities, not ad hoc integrations. Require stable client registration, clear ownership, and an explicit inventory of which callers may reach which servers. Without that inventory, security teams cannot tell whether the protocol is enforcing access or merely recording traffic.
Q: What is the relationship between MCP authentication and Zero Trust connectivity?
A: MCP authentication proves a request carries a valid token, while Zero Trust connectivity controls whether the caller should reach the server at all. Teams need both. One governs token validity and scope, the other governs network reachability and default exposure.
Technical breakdown
How MCP became an OAuth-style resource server
The current MCP model splits responsibilities the way enterprise identity teams expect. The MCP server behaves as a resource server, validates access tokens, and enforces permissions. A separate authorization server, usually the enterprise identity provider, authenticates the user and issues a token for that specific resource. Discovery metadata ties the two together so clients know where to request authorization. This architecture matters because it removes login logic from the tool endpoint and gives the server a clear trust boundary. It also makes scope, audience, and issuer checks explicit rather than implied. Read OAuth 2.0 and OpenID Connect Guide for Identity Teams.
Practical implication: Validate that each MCP deployment separates resource access from token issuance and enforces audience-bound tokens.
Why token passthrough creates a confused-deputy problem
Token passthrough happens when an MCP server forwards the client’s token to an upstream API instead of using its own downstream credential. That pattern breaks the intended audience model, because the upstream service receives a credential it never should have trusted. In practice, the MCP server becomes a deputy acting on behalf of the client with broader authority than it should possess. The protocol now forbids that behaviour, but older deployments still use it because the shortcut is convenient. The security failure is not just weak implementation, it is broken delegation semantics. See the MCP Security Guide.
Practical implication: Block downstream token forwarding and force each service hop to authenticate with its own bounded credential.
Why client registration and audience validation matter together
Dynamic Client Registration and skipped audience checks create a pairing that weakens trust at both ends. Anonymous registration can let an attacker present as a legitimate client, while poor audience validation can let a valid token be replayed against the wrong server. MCP’s newer revisions respond by deprecating dynamic registration in favour of client metadata documents and by requiring resource indicators and issuer validation. That combination closes the most common mix-up and replay paths, but only if implementers reject older defaults and validate the metadata flow end to end.
Practical implication: Require verified client identity and strict token audience checks before allowing any MCP client to connect.
Threat narrative
Attacker objective: The attacker wants to reuse a valid MCP-related credential to reach tools or upstream services that were never intended to trust that token.
- Initial access begins when an MCP client receives credentials or a token path that is valid for one service but not tightly bound to the specific server it should reach.
- Credential abuse follows when the server forwards that token upstream or accepts a token without checking issuer and audience correctly, creating a confused-deputy path.
- Impact occurs when the misbound credential reaches an unintended tool or data source and gives the agent access beyond the original trust boundary.
Breaches seen in the wild
- Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
MCP auth is now a governance problem, not an unstructured protocol problem. The July 2026 profile gives practitioners a recognisable OAuth 2.1 and OpenID Connect shape, but that only matters if deployment teams actually enforce issuer validation, audience binding, and server separation. The field issue is no longer the absence of a standard. It is the gap between a standardised trust model and the operational reality of mixed-version servers, legacy client behaviour, and permissive defaults. The implication is that identity teams now own MCP control quality, not just protocol adoption.
Token passthrough is a delegation failure, not a convenience feature. When an MCP server forwards a client token upstream, it creates a trust relationship the original token never authorised. That is a classic confused-deputy pattern, but in modern agent connectivity it becomes especially dangerous because the server is often the bridge between an autonomous workflow and sensitive tools. The practical conclusion is that delegation chains must be explicit, bounded, and separately authenticated at each hop.
Dynamic registration weakens the identity supply chain around MCP clients. Anonymous client onboarding makes impersonation and mix-up attacks easier because the server cannot rely on a stable identity posture for the caller. The protocol’s move toward client metadata documents is therefore a governance signal as much as a technical revision. Practitioners should read it as a demand for stronger pre-registration trust and tighter client inventory discipline.
Zero Trust complements MCP because application-layer auth does not answer reachability. A token can tell you that a request is valid, but it does not prove that the client should have been able to reach that server in the first place. That is why identity-verified connectivity remains necessary alongside OAuth-style controls. For practitioners, the lesson is to govern both the credential and the network path, not one in isolation.
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.
- Read next: MCP Security Guide
What this signals
Identity-aware reachability is the missing control layer for MCP. Access reviews and token scoping are necessary, but they do not stop an over-reachable server from being probed by any agent that can see it. The programme-level response is to align MCP exposure with identity-verified connectivity so that tool access and network access fail closed together.
Audience binding is the control that will separate mature MCP deployments from opportunistic ones. When tokens can be replayed across servers, the protocol is acting like a broad bearer channel rather than a constrained identity boundary. That is the practical test security teams should apply to every deployment before they allow agents to scale.
For practitioners
- Enforce audience-bound tokens Require every MCP server to validate issuer, audience, and resource indicators before accepting a request.
- Ban downstream token forwarding Reject any MCP deployment that passes client tokens to upstream APIs instead of using a server-owned credential.
- Deprecate anonymous client registration Move clients to verified metadata documents and maintain a controlled inventory of approved MCP callers.
- Pair MCP auth with network reachability controls Make MCP services reachable only through identity-verified connectivity so a stolen token cannot reach every backend by default.
Key takeaways
- MCP has matured into a recognisable OAuth-style model, but the security value depends on whether servers actually validate audience, issuer, and scope.
- The most damaging failure pattern is token passthrough, because it turns a scoped credential into a downstream trust bypass.
- Practitioners need both application-layer auth and Zero Trust reachability controls, or MCP deployments will remain easier to misuse than the standard suggests.
Related NHI Mgmt Group resources: MCP Security Guide · OAuth 2.0 and OpenID Connect Guide for Identity Teams · AI Agent Authorisation Guide · IAM and IGA Basics
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | MCP auth failures center on token validation, audience binding, and identity assurance for tool access. |
| NHI-05 — Overprivileged NHI | Token passthrough and weak scoping give MCP clients more reach than their task requires. | |
| Recommendation — Validate MCP identities with strong authentication and reject tokens that are not bound to the intended audience. Reduce MCP token scope and limit each client to the minimum server access it actually needs. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | Replayable or forwarded tokens create credential abuse paths that support movement across services. |
| Recommendation — Map token replay and passthrough risks to credential access and lateral movement tactics in detection planning. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about enforcing permissions and audience checks for MCP-bound access. |
| Recommendation — Apply entitlements and authorisation checks to every MCP server before allowing tool access. | ||
| NIST Zero Trust (SP 800-207) | Resource access — Resource access | Zero Trust connectivity is the second control plane the article says MCP deployments need. |
| Recommendation — Constrain MCP reachability so only verified identities can contact the resource in the first place. | ||
Key terms
- Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
- Token Passthrough: Token passthrough is the practice of forwarding an authentication token through intermediaries instead of validating it at each trust boundary. In MCP this is prohibited because it prevents the server from proving who is actually authorised to act. The result is weaker accountability and a larger attack surface for stolen or replayed credentials.
- Audience Binding: A control that limits a token to a specific downstream resource or service. It prevents credential replay across tools and keeps delegated access aligned to the exact action the system was allowed to perform.
- 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.
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 or NHI governance programme, it is worth exploring.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org