In plain terms
A hotel receptionist holds the master key. A stranger phones the desk: “I am the guest in room 412 and I am locked out; please leave the door open for my colleague.” The stranger has no key and never touches the lock. The receptionist, who has every right to open doors, opens this one for them. The deputy is the one who holds the authority; the confusion is about whose wishes it is serving.
Why it matters
An agent is a deputy by design: it holds credentials for mail, files and business systems and acts on requests. It also reads content written by outsiders, and it cannot reliably tell their text from its principal's instructions. Every permission check passes, because the agent really is authorised. Access reviews that ask “may this account do this?” therefore miss the problem; the question to add is “on whose behalf is it doing it?” The remedies cost flexibility: authority tied to each request, and confirmation for actions that originate in untrusted content.
Example
A company gives its HR assistant read access to all 2,300 salary records, so that it can answer each employee's questions about their own pay. An employee asks it: “Compare my salary with the other five people in my team, by name.” The employee has no right to that data; the assistant has. It answers. Nothing was hacked: the assistant used its own access for someone else's purpose.
Most often confused with
Confused Deputy vs. Prompt Injection
Prompt injection is one way of confusing the deputy, and the deputy's authority is what makes injection pay. An agent with no privileges can be injected and nothing of value is lost. A privileged agent can be misused with no injection at all, by an ordinary user asking for more than they are entitled to. Injection is reduced by controlling what the agent reads; the deputy problem is solved by controlling whose authority each action carries.
Origin: Described by Norm Hardy in his 1988 paper “The Confused Deputy (or why capabilities might have been invented)”.
Under the hood
The classic case is a compiler on a time-sharing system that held permission to write into its own directory. A user named the billing file as the destination for the compiler's output, and the compiler overwrote it with its own authority. The root cause is ambient authority: the program's rights apply to everything it does, whoever asked. Later forms include cross-site request forgery, where a browser attaches the user's cookies to a request that an attacker's page started, and cloud services that act across customer accounts. In agent systems the pattern appears when an agent runs on a broad service account, when an MCP proxy server connects clients to a third-party API (a case the MCP security guidance addresses by name), and when one agent asks a more privileged agent to act. Defences: run tool calls with the requesting user's identity and scope (delegated, on-behalf-of tokens), enforce authorisation in the downstream system, bind tokens to their intended audience, track where each instruction came from and require confirmation when a sensitive action stems from untrusted content. Capability-based designs pass the authority along with the request itself.