What Is a Confused Deputy Problem?
A confused deputy is a program that holds a permission its caller does not, and is persuaded by that caller to use it on their behalf. Nothing is stolen and no privilege is escalated: the deputy exercises exactly the authority it was always meant to have, against a target chosen by someone with no right to choose it. The defect is in the arrangement rather than in the code that ran.
The original case, and the structure underneath it
The problem was named in the setting where it is easiest to see. A shared compiler, installed by the operator of a timesharing system, reads a source file the user names and writes its output to a filename the user also names. The compiler separately keeps a private accounting file in a directory only it may write to, and it holds that write permission permanently because it needs it on every run. A user who passes the accounting file's path as the output filename has that file destroyed. The user could not have written it. The compiler could, and did, because it was asked to and had no way to tell that this particular request should never have reached it.
Take the example away and what is left is a separation between two things every request carries. One is the designation — which resource this operation concerns — and it arrived from the caller. The other is the authority — the right to act on that resource — and it came from the deputy's own standing identity, sitting in the environment and applied automatically to whatever the deputy does. Because the two arrive by different routes and are never checked against each other, a caller who can influence the designation borrows the authority for free. The deputy has not been compromised. It is confused about whose request it is acting on.
The same shape recurs wherever a component sits between a requester and a resource while holding credentials of its own, and the recurrences are worth naming because they show the fix. A browser that attaches a stored session credential to a request some unrelated page induced it to issue is a confused deputy, and the countermeasures against that class work by making the request carry evidence that its origin intended it, rather than by trusting the credential. A server that fetches an address a caller supplied is a confused deputy with respect to everything reachable from where the server sits and unreachable from where the caller sits. In every version the remedy lies on one axis: bind the authority to the designation, or test the designation against the caller's rights instead of the deputy's.
| Party | What it holds |
|---|---|
| The caller | The intent, and the ability to name the target. No permission over it whatsoever. |
| The deputy | A standing permission over the target, and no dependable account of who is asking or why. |
| The guard on the resource | A check against the deputy’s identity, which passes, because the deputy is genuinely entitled. |
| The audit record | A legitimate action performed by an entitled component. Nothing in the entry looks wrong. |
| The attacker | Nothing new. No credential was obtained, and no check was defeated. |
The last two rows are why this class survives review so comfortably. There is no failed authorisation to alert on and no stolen credential to revoke, so the incident is visible only as a correct action that nobody intended — which is findable in a log by someone who already knows what they are looking for, and not otherwise.
Why an agent holding tools is this arrangement by default
An agent runtime is built to be a deputy. It holds the credentials — an interface key, a repository token, a mailbox session, a stored payment method — because the work requires them and because handing them to whoever is talking to it would be worse. It then takes its instructions as text, which is where the other half of the arrangement arrives: instruction and content share a channel, so a sentence planted in a fetched page or returned by a tool reaches the runtime in the same form as a directive from the operator, and designates a target in the same way. The permission is legitimate, the designation is attacker-chosen, and the structure is complete without anything having gone wrong at the level anyone is monitoring.
Reading it as an authority problem rather than a text problem changes which defences look serious. A credential scoped to the single resource a task needs bounds what a successful confusion can reach, without anyone having to classify the input correctly. A permission check made against the requesting party's own rights rather than against the runtime's removes the borrowed authority altogether — which is what a delegated or exchanged token is for, and why a grant issued on behalf of a caller is not interchangeable with running as the service. And a handle that carries the right to one specific resource, rather than a name the caller supplies as a string, closes the designation gap directly: a resource that can only be named by presenting a handle cannot be named by an outsider who holds none.
The measure that costs least and is skipped most often is putting a person in front of the small number of operations that cannot be undone. It solves nothing — the runtime is still a deputy for everything else it does — but it changes the class of loss, and it is the only item on this list that does not first require getting the permission model right.
How the Registry classifies a delegated authorisation task
Releasing an outbound payment only when the requesting caller's own permissions cover it, rather than the runtime's, is filed as a transaction in this registry's classification. That class is the one covering purchases and settlements, and what puts this task in it is not the money but the irreversibility: the operation commits something outside the system that no later step retracts.
The Registry's canonical brief for this entry is filed as:
Release an outbound payment only when the requesting caller’s own permissions cover it, not the runtime’s.
Submitted for assessment it is
classified as Transaction, and its wording is hashed once — to
a4722b7beccce0ec…, the first sixteen of sixty-four hexadecimal
characters — with the wording itself never stored. The hash is what the derivation
reads.
That class's own page is /tasks/transaction.
Classification is one of three inputs. The other two are the configuration submitted with the task, and the permanent chart derived from that configuration — fixed by the model name, the training cutoff and the temperature alone, and never reading the task at all. The same ascendant, ruling planet and harmony therefore appear on every assessment a given configuration receives, whatever it was asked to do. The derivation is published in full at /method.
What this page does not claim about confused deputy
Whether a particular runtime is a confused deputy depends on where its credentials come from, what they are scoped to, and whether any check anywhere consults the caller's rights — none of which the canonical brief above states. This registry holds no customer's credentials, brokers no payment on anyone's behalf, and has audited no agent's permission model.
The Registry does not run this task, does not inspect any system's output for it, and validates no assessment it issues against what afterwards happens. What it does is compute — from a published method, for one submitted task and one submitted configuration — a verdict and a recommended execution window. It computes neither on this page.
Questions about confused deputy
- What is the confused deputy problem?
- A confused deputy is a program that holds a permission its caller lacks and is induced to use that permission against a target the caller names. The caller ends up holding nothing new; they borrow the deputy’s authority for one operation, and every check that operation passed was checking the deputy.
- Is a confused deputy the same as privilege escalation?
- Not quite, and the difference is worth keeping. In escalation an attacker ends up holding privileges they did not hold before. In a confused deputy nobody’s privileges change at all: an entitled component performs an action it was entitled to perform, and the defect is that the choice of target came from someone with no claim on it.
- What is the classic example?
- A shared compiler that writes its output to a filename the user supplies, and separately maintains a private accounting file that only it may write. Passing the accounting file’s path as the output filename destroys it, using the compiler’s own permission, and no rule the system enforces has been broken.
- How does this apply to AI agents?
- An agent runtime holds credentials its users do not, and receives its instructions as text arriving on the same channel as the content it processes. An instruction planted in that content designates an action, and the runtime performs it under its own authority. That is the deputy arrangement exactly, with the designation supplied by a third party.
- What actually mitigates it?
- Binding authority to designation, so that naming a resource requires already holding a right to it; checking permissions against the requesting party rather than against the running service, which is what delegated or exchanged tokens provide; scoping credentials to the narrowest resource a task needs; and requiring human approval before irreversible actions. Filtering the wording of requests is not on this list, because the wording is not where the authority came from.
Related entries
Prompt injection · Function calling · Human in the loop (HITL)
Order an assessment for transaction tasks
The Registry issues a permanent, numbered task risk assessment for one submitted task and one submitted configuration. EUR 1.90 Standard, EUR 4.90 Extended, EUR 14.90 Full Chart, which adds the permanent chart. Assessments from EUR 1.90; machine-readable at /pricing.json.