MCP permission models that prevent confused deputy failures

At a glance

What this is: This is an analysis of MCP security permissions, with the key finding that standardised agent connectivity creates delegated-authority risks unless per-client consent and request-level validation are enforced.

Why it matters: It matters because IAM and NHI teams must control agent-to-tool access with the same precision they apply to privileged human and machine identities, or they will overgrant access and widen blast radius.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.

👉 Read Aembit's analysis of MCP permission models and agent access controls

Context

Model Context Protocol is an integration standard, but in identity terms it is also a delegated access problem. When an AI agent calls APIs, databases, and sensitive resources on behalf of a user, the security question becomes who authorised which client, for which scope, under which conditions. MCP permissions fail when teams assume human-style authentication is enough for agent-driven access.

That is why the issue is not just access control in the abstract. MCP environments need server-side consent checks, token audience validation, direct token verification, exact redirect handling, and per-request validation. Without those controls, the environment invites confused deputy failures, token leakage through intermediaries, and overpermission that exceeds the actual task boundary.

Key questions

Q: What breaks when MCP permissions rely only on user login and roles?

A: User login and RBAC do not prove that a specific MCP client was approved for a specific action. That creates confused deputy risk, where one authorised client can be used to access resources intended for another. Security teams need server-side client consent and request-level validation, not just identity and role checks.

Q: Why do MCP environments increase the risk of token leakage and overpermission?

A: MCP agents move across tools and trust boundaries quickly, so forwarded tokens and broad roles can outlive the task they were meant to support. That widens blast radius and exposes secrets through intermediaries. Teams should treat token audience validation, direct server checks, and scoped delegation as baseline controls.

Q: How do security teams know if MCP access policies are too coarse?

A: If a single role or policy grants access to broad datasets or multiple tools when the task needs only one resource, the policy is too coarse. The signal is overpermission, not just denied requests. Good MCP governance should show client-specific consent, narrow scopes, and auditable request context.

Q: Who is accountable when an MCP agent accesses the wrong resource?

A: Accountability sits with the teams that defined consent, token handling, and policy review for the MCP deployment. If token passthrough, weak audience checks, or incomplete client approval allowed the request, that is a governance failure, not an agent anomaly. Frameworks such as NIST CSF and Zero Trust architecture expect explicit access validation.

Technical breakdown

Per-client consent and confused deputy risk in MCP

A confused deputy attack happens when a legitimate service applies valid authority to the wrong client or context. In MCP, that means a user may have authorised one application, but another application reuses the same trust relationship to reach the same data. RBAC alone cannot stop this because role membership does not prove that a specific client was approved by a specific user for a specific request. The control that matters is server-side consent validation tied to the client identity, not just the user identity.

Practical implication: enforce server-side per-client consent registries and reject any request that cannot be tied to a specific approved client.

Token audience validation and rejection of token passthrough

MCP security depends on tokens being validated for the exact server that receives them. Audience validation prevents a token issued for one service from being accepted by another, even if the token is signed and unexpired. Token passthrough is especially dangerous because it lets intermediaries handle bearer tokens that were never meant to leave the original trust boundary. The safer pattern is direct validation against the authorisation server and delegated token exchange when downstream services need their own authority.

Practical implication: require exact audience checks and block any architecture that forwards user tokens through proxies, middleware, or downstream services.

Why RBAC, ABAC, conditional access, and PBAC behave differently in MCP

These models solve different layers of the MCP problem. RBAC gives broad boundaries, ABAC adds contextual attributes such as time or location, conditional access evaluates the live request context, and PBAC centralises policy logic across services. The technical issue is that MCP requests are dynamic and agent-driven, so static permissions often overshoot actual need. The more dynamic the environment, the more important policy evaluation becomes, but central policy also raises governance demands because one bad rule can affect many access paths.

Practical implication: use RBAC for coarse boundaries, then add ABAC or PBAC where agent context and cross-service trust boundaries demand finer control.

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

MCP permission design fails when teams confuse user authentication with client authorisation. The article makes clear that a valid user session does not prove that any given agent or client should be allowed to act. That is a classic delegated-access mistake, and it is exactly where confused deputy failures emerge. The implication is that identity teams must stop treating user login as a sufficient authorisation event for agentic access.

Per-client consent is the named control gap that separates usable MCP deployments from unsafe ones. The security model only works when the server can prove that a specific client was approved for a specific scope by a specific user. This is not a generic least-privilege slogan. It is the concrete failure mode that prevents one authorised client from becoming a proxy for another and turning consent into ambient authority.

Token passthrough creates identity spillover across services. Once a bearer token is forwarded through intermediaries, the trust boundary expands beyond the original authorisation intent. That breaks the assumption that tokens remain tied to the service that received them, and it makes logging, proxies, and middleware part of the exposure path. Practitioners should treat forwarded tokens as a governance defect, not just a transport convenience.

MCP-specific permission scoping is the real governance concept here. MCP does not simply add another integration protocol, it forces identity teams to scope authority at the client, request, and resource level at runtime. That changes how IAM, PAM, and NHI teams think about delegation chains, because the same agent may need different rights across minutes, tools, and contexts. The conclusion is that static permissions are no longer enough for agent-driven access patterns.

Policy engines only help when their inputs are trustworthy and their decision boundaries are explicit. PBAC can unify RBAC, ABAC, and conditional rules, but it also concentrates failure if policy authorship and review are weak. The field should read this as a governance problem, not merely an architecture choice. Practitioners need clear ownership for policy logic, or a single misrule can scale across the entire MCP estate.

From our research:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to The State of MCP Server Security 2025.
• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone.
• For a broader identity baseline, see Ultimate Guide to NHIs , Key Challenges and Risks for how exposure, sprawl, and over-privilege compound across machine identities.

What this signals

MCP-specific permission scoping is becoming a practical design requirement, not an implementation detail. As agent-driven access expands, teams will need to treat consent, audience checks, and request validation as part of the identity plane rather than as application logic. The useful benchmark is not whether the agent can connect, but whether the connection can be proven to be client-specific and task-specific.

Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to The State of MCP Server Security 2025. That gap signals that most deployments are still assuming static trust where runtime delegation is actually happening. Identity programmes should expect audit findings around scope drift, token handling, and weak client approval.

Practitioners should align MCP controls with the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework where agentic behaviour crosses into decision and tool use. The governance question is no longer whether to allow agents into enterprise systems, but how to constrain their delegated authority so that one approved task does not become ambient access.

For practitioners

• Enforce server-side client consent mapping Maintain a consent registry that maps user identifiers to approved client identifiers and scopes, then reject any MCP request that lacks an exact server-side match.
• Block token passthrough between intermediaries Require direct token validation against the authorisation server and use delegation mechanisms such as token exchange when downstream services need their own credentials.
• Tighten audience and redirect validation Validate every token audience claim against the receiving MCP server and enforce exact redirect URI matching with no wildcards, partial matches, or query-string drift.
• Separate coarse roles from runtime policy decisions Use RBAC for baseline boundaries, then apply ABAC, conditional access, or PBAC only where the task, environment, and trust boundary justify the added complexity.

Key takeaways

• MCP turns agent connectivity into a delegated-authority problem, so permission design must move from static identity assumptions to request-level proof.
• Confused deputy failures, token passthrough, and overbroad roles are the core risk patterns, and they all widen blast radius across tools and services.
• Server-side consent, exact audience checks, and narrowly scoped delegation are the controls that determine whether MCP can be governed safely at scale.

Key terms

• Model Context Protocol: A protocol that standardises how AI agents connect to external tools and data sources. In identity terms, it creates a delegated access surface where each client, token, and request needs explicit proof of authority before a tool can act on a user’s behalf.
• Confused Deputy: A failure mode where a legitimate service applies valid authority for the wrong requester or context. In MCP, it appears when one approved client is allowed to borrow the trust granted to another, turning authentication into unintended authorisation.
• Per-Client Consent: A control pattern that records which specific client applications a user has approved, along with the exact scopes granted. It prevents one authenticated client from inheriting the user’s trust for another client or another task.
• Token Audience Validation: A validation step that checks whether an access token was issued for the exact service receiving it. In MCP, this prevents a token meant for one system from being replayed successfully against another service, even if it is otherwise valid.

Deepen your knowledge

MCP permission models and delegated authority are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for AI agents and tool-connected workloads, it is worth exploring.

This post draws on content published by Aembit: MCP permission models that prevent confused deputy failures. Read the original.