Why do MCP implementations create confused deputy risk?

Why This Matters for Security Teams

MCP risk is not just a protocol problem. It is an authorisation design problem that becomes dangerous when an AI agent, connector, or downstream service is allowed to act under a user’s umbrella of trust. The confused deputy pattern appears when the server checks, “is this a valid user?” but fails to ask, “is this specific client, task, and action authorised?” That gap is especially serious in agentic systems because the workload is autonomous, goal-driven, and capable of chaining tools in ways that are hard to anticipate. NHI governance guidance in the OWASP NHI Top 10 and the OWASP Agentic AI Top 10 both point toward the same operational lesson: identity alone is not enough if the workload can improvise its next step. In practice, many security teams discover this only after a benign integration has already been reused to perform a higher-privilege action than the user intended.

How It Works in Practice

The failure mode usually starts with a broad trust boundary. A user signs in, the client obtains a token, and the MCP server treats that token as proof that any connected component may invoke tools on the user’s behalf. If the server does not bind the token to a specific workload identity, session, or intended action, a second component can inherit the same privilege. That is how a deputy becomes “confused”: it is technically acting for a legitimate principal, but not for the legitimate purpose. A safer implementation uses layered checks rather than one coarse grant. Current guidance suggests combining:

• workload identity for the agent or connector, so the server knows what is calling it;
• intent-based or context-aware authorisation, so the server knows what the caller is trying to do right now;
• JIT credential provisioning and short-lived secrets, so even approved access expires quickly;
• real-time policy evaluation, so requests are judged at execution time rather than by a static role mapping.

That approach aligns with NIST Cybersecurity Framework 2.0 expectations around least privilege and continuous governance, and with the emerging direction in agentic controls described by the OWASP Top 10 for Agentic Applications 2026. It also fits the broader risk picture documented in SailPoint research, where AI Agents: The New Attack Surface report found that 80% of organisations saw agents act beyond intended scope. These controls tend to break down when legacy middleware can only validate user sessions, not agent-level intent, because the protocol then inherits human IAM assumptions that do not match autonomous execution.

Common Variations and Edge Cases

Tighter delegation controls often increase integration overhead, requiring organisations to balance safety against developer friction and latency. That tradeoff is real, especially in environments where MCP servers support multiple clients, multiple tenants, or long-running tool chains. One common edge case is an assistant that can request one permission set at login and then reuse it for unrelated follow-on actions. Another is a server that accepts a valid token from any caller, even if the token was minted for a different application or session. Best practice is evolving here, but the consensus is moving toward binding authorisation to the specific workload, not just the end user. In agentic environments, that usually means per-task approval, token audience restrictions, and revocation when the task ends. A second edge case is secret sprawl. The Top 10 NHI Issues and Ultimate Guide to NHIs — Key Challenges and Risks both reinforce that long-lived secrets make confused deputy failures harder to contain, because stolen or over-scoped credentials let one component impersonate another. The safer pattern is ephemeral secrets plus workload identity, with policy evaluated at request time, not at deployment time. For governance, that lines up with NIST Cybersecurity Framework 2.0 and the accountability expectations in Ultimate Guide to NHIs — Why NHI Security Matters Now. Where this guidance breaks down most often is in flat trust networks where every connector can reach the same tool endpoint, because the server has no reliable way to distinguish an intended delegation from an opportunistic reuse of trust.

Related resources from NHI Mgmt Group

• Why do AI agents create new risk in non-human identity management?
• When does AI agent access create more risk than it reduces?
• When do AI agent credentials create more risk than they reduce?
• Why do AI agents create more risk when they reuse existing credentials?