What Is the Confused Deputy Problem in AI Agents?

Quick answer
A confused deputy is a program with authority that is tricked into using it for someone without that authority.
For an agent, the deputy is the agent and the trick is instruction-shaped content it reads: a web page, a ticket, a file, a tool description.
The classic combination is private data access, untrusted content, and a way to send data out — the lethal trifecta.
The fix is not better instructions to the agent; it is separating the authority from the content.
Practical controls are least privilege, per-tool approval, and preventing untrusted content from being in the same session as powerful tools.

What is the confused deputy problem?

The term comes from operating systems: a privileged program is asked to perform an operation on behalf of an unprivileged caller and does so without checking whether the caller should have that access. The deputy has the authority; the caller supplies the request.

In an agent, the authority is the agent’s credentials and tools, and the caller is whatever content it reads. The agent cannot reliably tell an instruction from data, so text in a document can function as a command.

Why is this the core agent security problem?

Because it does not require a bug. The agent is designed to follow instructions, and it has access in order to be useful. Combine those two facts with a channel that carries untrusted text and you have the attack, independent of the model’s quality.

It also survives prompt-injection mitigations. Even a model that is good at ignoring injected instructions can be wrong once, and one successful redirect with write access is enough. That is why the controls are about authority, not about persuasion.

What does the lethal trifecta mean here?

Access to private data, exposure to untrusted content, and a way to communicate externally. Any two are manageable; all three in one session mean content the agent reads can move data the agent can reach to a destination the attacker controls.

The practical rule is to break one leg. Remove the external channel, isolate the untrusted content from the private data, or run the task without the data access it does not need for that step.

How do you design against it?

Separate the steps. Fetch and summarise untrusted content in a session with no write tools and no private data. Then act in a session with authority but no untrusted input. The model never holds both at once.

Add approval for authority-shaped actions: sending email, pushing code, calling an external API, changing permissions. A human confirming the destination is the cheapest control that survives a novel injection, because it does not depend on detecting the attack.

Where this bites vibecoders
The tempting setup is one agent with repository write access that also reads issues, pull request comments, and web pages. That is the trifecta in a single session. Split the reading and the writing, or accept that a comment can become a commit.

Where AI coding assistants get this wrong

Giving one session both untrusted input and write authority.
Relying on the system prompt to resist injected instructions.
Letting the agent send data to any URL it chooses.
Assuming read-only data access is harmless when the data is private.
Approving tool calls without checking the destination.
Auditing the model instead of the permissions.

Checklist

List the private data the agent can read.
List the untrusted content it can read.
List the channels it can send through.
Break at least one leg of the trifecta.
Require approval for external actions.
Keep the write session free of untrusted input.

FAQ

Is this the same as prompt injection?

Prompt injection is the delivery mechanism. Confused deputy is why it matters: the agent has authority the content should not be able to exercise. You can reduce injection with filtering, but you remove the impact by reducing what the deputy can do.

Can a model be trained to resist it?

Resistance improves but does not become a guarantee, because the model cannot reliably distinguish data from instructions in every format. Treat model-level defence as one layer and design the authority boundary as the control that must hold.

What is the smallest useful mitigation?

A human confirmation before any action that leaves the session: a push, a message, an external request, a permission change. It is cheap, it does not depend on detecting the attack, and it catches the case where the agent was convinced.

Does sandboxing solve it?

Partially. A sandbox limits what the agent can reach, which breaks the private-data or the external-channel leg. It does not help if the sandbox still contains the secret and the channel, which is common when the sandbox is built for convenience.