MCP permission models that prevent confused deputy failures

At a glance

What this is: This analysis explains why MCP permission models fail when delegated authority is too broad, showing that confused deputy risk, token passthrough and weak consent binding are the core security problem.

Why it matters: IAM and security teams need to treat MCP as an authorization design problem because agent-driven access changes how consent, token validation and privilege scope must be enforced across NHI and autonomous workflows.

Context

MCP authorization is a permissions problem, not just a protocol problem. In Model Context Protocol deployments, AI agents act on behalf of users across APIs, databases and other sensitive services, so the central governance issue is whether delegated authority is bound tightly enough to the specific client, user, token and request.

Traditional access models assume relatively stable identities and predictable resource use. MCP breaks that assumption because agents can change context at runtime, invoke multiple tools in rapid succession and need narrow, task-scoped access that still remains auditable and enforceable.

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 audience-bound tokens matter for MCP authorization?

A: MCP clients can move across multiple resource servers in a single session, so generic tokens create replay risk and scope ambiguity. Audience-bound tokens reduce that risk by tying each token to one resource URI. This gives teams a clearer boundary for authorization, logging, and incident response when agents or integrations are active.

Q: How do security teams decide whether an MCP agent has too much access?

A: A useful test is whether the agent can read data, trigger actions, and move across systems with one broad entitlement. If those capabilities are bundled, the access is too wide. Teams should separate those functions, then confirm that each permission is necessary, traceable, and removable without breaking unrelated workflows.

Q: Should organisations use RBAC, ABAC or PBAC for MCP deployments?

A: Use them in layers, not as substitutes for the MCP baseline controls. RBAC is useful for broad boundaries, ABAC adds context, and PBAC centralizes decisions for complex environments, but none of them replaces per-client consent or audience validation. The right choice depends on how dynamic the agent’s access pattern is.

Technical breakdown

Why confused deputy failures happen in MCP

A confused deputy failure occurs when a legitimate server or client applies valid authority to the wrong requester. In MCP, the risk appears when user authentication is treated as blanket authorization for any client that can present a token. The server then acts as a deputy that has real privileges but no reliable way to distinguish which application was actually approved for which scope. Per-client consent closes that gap by binding user consent to a specific client identity and scope on the server side. That is why RBAC alone is insufficient: roles describe broad entitlement, not who is allowed to exercise that entitlement in a given request path.

Practical implication: Enforce server-side per-client consent so authorization follows the approved client, not just the authenticated user.

Token audience, token exchange and passthrough controls

MCP requires each request to be validated against the intended audience and prohibits forwarding a user token through intermediaries. That matters because a token can be correctly signed and still be wrong for the receiving service, and passthrough creates exposure at every proxy, log or middleware hop. Where an MCP server needs downstream access, it should obtain its own scoped credential through delegation such as OAuth token exchange rather than reusing the user’s original token. This is a control boundary, not a convenience choice. The model is designed to preserve attribution, limit replay value and keep each service accountable for its own authorization decision.

Practical implication: Validate audience claims and replace token passthrough with service-issued delegated tokens.

How RBAC, ABAC and policy engines layer on top of MCP rules

RBAC, ABAC, conditional access and PBAC can improve MCP authorization, but they sit on top of mandatory protocol controls rather than replacing them. RBAC gives broad role boundaries, ABAC adds attributes such as location or resource sensitivity, and conditional access evaluates live context at request time. PBAC centralizes those decisions in one policy engine so cross-boundary agents do not accumulate inconsistent rules across services. The trade-off is operational complexity: the more dynamic the policy, the more important observability, policy review and testability become. In MCP, the right model is often layered authorization, not a single catch-all approach.

Practical implication: Use layered access control only after the MCP baseline controls are in place, and govern policy sprawl deliberately.

Threat narrative

Attacker objective: The objective is to use legitimate authorization plumbing to access data or actions that were never intended for the attacking client.

1. Entry occurs when a user authorizes one client, but another client reuses the same trust path to reach an MCP server without a fresh, client-specific consent check.
2. Credential abuse follows when the server accepts a token for the wrong audience or allows token passthrough through intermediaries that should never see the original credential.
3. Escalation occurs when broad role or attribute rules let the requesting client access more data or functions than the specific task required.
4. Impact is unauthorized retrieval or manipulation of sensitive resources under a legitimate-looking authorization flow, with the confused deputy masking the true requester.

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.
• Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.

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

NHI Mgmt Group analysis

Confused deputy risk is the core MCP authorization failure mode. MCP does not fail because agents are dynamic. It fails when delegated authority is treated as portable across clients, users and tools without an explicit consent binding. That breaks the basic access-control premise that the requester and the approved client are the same thing. The practical conclusion is that MCP governance has to start with per-client authorization, not with generic role design.

Token audience validation is a security boundary, not a token hygiene detail. A signed, unexpired token can still be wrong if it was meant for another service, and passthrough makes that mistake travel across intermediaries. This is why the MCP specification’s prohibition on token forwarding matters: it prevents authorization from becoming a transport problem. Practitioners should treat audience and delegation checks as the minimum condition for trust in MCP flows.

RBAC alone is too coarse for task-scoped agent access. A role can describe that an agent belongs to customer service or analytics, but it cannot prove that a specific client was authorized by a specific user for a specific request. That leaves blast radius too wide when the agent is compromised or simply overtasked. The implication is that RBAC may define outer boundaries, but it cannot be the control that answers MCP’s central authorization question.

Policy centralization helps, but only after the baseline is correct. PBAC and conditional access can express runtime context, but they also concentrate failure if the underlying consent and audience checks are weak. The governance lesson is not to overfit on policy sophistication before the protocol-level controls are sound. For practitioners, the priority is clear: make the MCP request trustworthy first, then make the policy expressive.

Task-specific access is the named concept that should anchor MCP governance. Agentic access is not just least privilege with a different label. In MCP, the permission scope changes with the task, the client and the downstream service, so the control plane has to be built around request-time context and explicit delegation. Teams should design for task-specific access as the operating model, not as an exception case.

From our research library:

• 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
• Read next: AI Agent Authorisation Guide

What this signals

Task-specific access: MCP governance has to move away from static permission thinking because agents change context at runtime and use different tools inside the same workflow. That makes consent, audience validation and delegation scope the decisive control points, not the role name attached to the agent.

As agent use expands, overpermission becomes the default failure mode. One current survey found that 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey. That is the wrong starting point for MCP, because agentic access needs tighter scope, not broader trust.

For practitioners

• Implement server-side per-client consent Bind each user approval to a specific client identifier and granted scope, and reject any request that lacks a consent record for that exact client-user pair.
• Enforce token audience validation Check that every incoming token is intended for the MCP server that receives it, and reject tokens whose audience matches a different service even if the signature is valid.
• Eliminate token passthrough in the MCP path Require downstream services to obtain their own delegated credentials through token exchange or an equivalent server-side delegation flow instead of forwarding the original user token.
• Layer RBAC with contextual policy controls Use roles for broad access boundaries, then add ABAC or conditional access for task, environment and resource sensitivity so that agent requests stay scoped to the immediate use case.
• Audit policy sprawl before scaling agent access Review whether policy logic is still testable, observable and reviewable as you add more tools, clients and runtime conditions across the MCP deployment.

Key takeaways

• MCP authorization fails when user consent is not bound to a specific client, because that turns legitimate authority into a confused deputy risk.
• Token audience validation and delegation boundaries matter because a valid token can still be meant for the wrong service or exposed in transit.
• RBAC, ABAC and PBAC can support MCP, but only if they sit on top of server-side consent and non-passthrough token handling.

Key terms

• Confused Deputy: A confused deputy is a privileged system that is tricked into performing an action on behalf of an untrusted requester. In agentic AI, the agent may misread malicious input as legitimate intent and then use its own authority to act, which turns a logic problem into a security incident.
• 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.
• Policy-Based Access Control: Policy-based access control grants or denies access using rules that evaluate context, signals, and identity state at decision time. It is more adaptive than static role assignment, but only if the policy engine receives accurate runtime inputs and can enforce them across systems.

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.