Confused deputy problem

The confused deputy problem is a classic security flaw where a program with legitimate authority to perform an action is tricked by a less-privileged caller into misusing that authority on the caller’s behalf — the “deputy” (the privileged program) is confused about whose request it’s actually acting on. In MCP and other agent-tool systems, this shows up when a gateway or server simply passes through a token it received, rather than checking that the token was actually intended for it (the token’s “audience”); a malicious client can then route a token meant for one service through to another, tricking the receiving service into granting access it never should have. The Model Context Protocol’s own authorization specification names this failure mode directly and requires an MCP server to validate that a token’s audience actually names it before acting on that token, the same audience-binding principle RFC 6749’s OAuth 2.0 framework relies on, whose document record is tracked at the IETF Datatracker. The fix is validating token audience and scope at every hop, not forwarding credentials blindly between services. The pattern is not unique to agents: AWS’s IAM documentation describes the same problem for cloud permissions and recommends condition keys such as aws:SourceArn and aws:SourceAccount so a resource policy can check on whose behalf a service is acting.

Where the confused deputy problem shows up in MCP:

• A gateway accepts a token issued for a different service and forwards it downstream unchanged.
• The downstream service wrongly trusts the forwarded token as if it had validated it itself.
• The fix: validate the token’s audience and scope at every hop — never pass a token through blindly.

AdminKit groups confused deputy problem under its AI agents & MCP cluster — browse the AdminKit glossary index for other related terms.