What Is a Confused Deputy Attack? Agent Authority Misuse

The confused deputy is one of the oldest problems in computer security and AI agents have made it newly common, because an agent is precisely a privileged intermediary acting on instructions from parties with less authority. Understanding the shape of the problem is what leads to the right fix, which is architectural rather than defensive. This explainer covers it. It complements what is least privilege for ai agents and ai access control, and reflects FISTA Solutions' approach in AI agents delivery.

What is the underlying pattern?

A privileged component receives a request from a less privileged party and performs it using its own authority. The requester could not have done it directly; the deputy could, and did, without checking whether the requester should have been able to.

An agent with a service account that can read every customer record, taking instructions from any user, is exactly this shape. The interface suggests the user is limited to their own data; the implementation gives them the agent's reach.

Design	Authorisation evaluated against	Exposure
Agent service account	The agent	All users get agent's access
Per-user delegation	The requesting user	Correct
Agent with narrow scope	The agent	Bounded but still shared
Identity lost mid-chain	Service account downstream	Silent escalation

How does it differ from prompt injection?

Injection is a technique for changing what an agent decides; confused deputy is why that decision matters. An agent with no authority that is successfully injected produces bad text. An agent with broad authority that is injected performs privileged actions.

This distinction matters because it directs effort. Resisting injection is an arms race with no clean end; removing the agent's standing authority is an architectural change that holds regardless of which technique succeeds.

What is the correct model?

The agent acts on behalf of a specific authenticated user, and every authorisation decision evaluates that user's permissions. The agent holds no independent standing authority — it is a mechanism through which a user acts, not an actor with its own rights.

Under that model, an injected agent can only do what the user could already have done, which contains the consequence to something the system was already prepared to permit. See ai access control.

Why is identity propagation difficult?

Because it must survive every layer. The agent framework must carry it. Each tool invocation must pass it. Downstream services must honour it. Anything queued or deferred must preserve it.

The common failure is partial propagation: identity reaches the first tool and is lost afterwards, so later calls run with service credentials. That is invisible in testing, because a user with broad permissions sees correct behaviour either way.

Does least privilege solve it?

It bounds the damage. An agent restricted to a narrow set of operations is a less valuable deputy to confuse, and correct behaviour still requires per-user authorisation. A narrowly scoped agent acting on its own authority still gives every user the same access as every other.

Both are needed: narrow scope, and authorisation against the requester within it.

What should be logged?

The acting identity, not only the agent. A log recording that the agent read a record answers nothing; a log recording that the agent read it on behalf of a named user is auditable and makes misuse visible.

What should you do first?

Take one agent that reads data and check whether two different users would receive different results based on their own permissions. If they would not, the agent is a confused deputy today, and identity propagation is the fix rather than tighter input filtering.

What about agents acting without a user?

Scheduled and autonomous agents have no requesting user, which removes the delegation model and puts the weight entirely on scope. Such an agent should hold the narrowest permissions that let it do its specific job, with anything beyond that requiring a human to authorise at the moment it is needed.

The temptation is to give a scheduled agent broad access because its work varies. That is the configuration that makes an eventual compromise expensive, and the alternative — several narrowly scoped agents rather than one broad one — is usually available and rarely chosen.

How does this show up in multi-agent systems?

As delegation without attenuation. One agent calls another, and if the second acts on its own service identity the user's permissions have been dropped somewhere in the middle. Each hop is an opportunity to lose the identity, and the failure is silent.

The discipline that holds is passing the acting identity through every hop and evaluating authorisation at the point of action rather than at the entry point. An authorisation check performed only where the user first arrived tells you nothing about what happened three agents later.

How FISTA Solutions helps

FISTA Solutions builds agents that act on the authenticated user's identity with authorisation evaluated per request, propagates identity through every tool and downstream call, grants agents least privilege as a containment measure, and logs the acting identity alongside the agent, through AI agents, AI enablement, and forward deployed engineers. The record behind the approach is 150+ projects for 50+ companies with 99.9% uptime.

To stop your agents granting everyone their own permissions, message FISTA on WhatsApp, or read what is least privilege for ai agents.