The last two posts were about agents you do not control. This one is about your own agents, and a risk that comes from how they hand work to each other.
Every time an orchestrator delegates, by calling a sub-agent as a tool, or transferring control to one, it passes something down: context, and often authority. Delegate carelessly and a specialist ends up holding more power than its narrow task ever needed, which is the oldest privilege mistake there is, in a new setting.
The confused deputy, restated for agents
The classic confused-deputy problem is a program with more privilege than a request should carry, tricked by that request into using its privilege on the requester's behalf. The program is not malicious. It is confused: it acts with its own authority on someone else's instruction.
A sub-agent is a perfect confused deputy. The orchestrator has broad access, the tools, the context, the standing to act. It delegates a task to a specialist. If the specialist inherits that broad access to do a narrow job, then anyone who can steer the specialist, through untrusted input in the task, a poisoned document it reads, can direct the orchestrator's authority without ever holding it themselves.
The specialist does the damage, with power it was handed, on instruction it should not have trusted.
Two ways delegation over-shares
The multi-agent patterns pass authority down in two forms, and both over-share by default.
Transfer inherits the whole conversation. When a router transfers to a specialist, the specialist inherits the full conversation history. That inheritance is what makes hand-over smooth, and it means the specialist now sees everything: other users' details that came up, sensitive context from earlier, instructions meant for a different part of the task. A billing specialist transferred a support conversation may be holding data it has no business seeing, and acting with the context of the whole exchange rather than the slice its job needs.
Agent-as-tool passes broad tools. A sub-agent invoked to summarise research does not need the ability to send email or run code. If it is built on the same broad tool set as the orchestrator, it holds those anyway. A summarisation task steered by a poisoned source can then reach for a tool the task never required, because the deputy was armed for far more than its job.
A specialist handed the full conversation and broad tools becomes a confused deputy, acting with power its task never needed.
Why "they are all our agents" is the trap
The comforting thought is that these are your own agents, so the trust is fine. That misreads where the risk is. The problem is not that a specialist is malicious. It is that a specialist is steerable, by the untrusted input flowing through the system, and the more authority it inherited, the more an attacker who steers it can do.
Internal trust between agents is exactly what an attacker exploits. Get a poisoned instruction into a document the research specialist reads, and if that specialist inherited the orchestrator's tools and context, the instruction now runs with the orchestrator's reach. The trust you extended between your own agents became the attacker's privilege escalation path.
Least privilege, applied to delegation
The fix is least privilege, pointed at what gets passed down the chain. A sub-agent should receive the minimum context and the minimum tools its task requires, and nothing more.
| Control | What it changes |
|---|---|
| Pass a scoped task, not the whole conversation | The specialist gets what it needs to do the job, not everyone's history |
| Give each specialist its own minimal tool set | A summariser holds no email or code tool it will never legitimately use |
| Scope authority to the delegated task | The sub-agent can act on this task, not with the orchestrator's full standing |
| Keep the irreversible tools at one gated level | Sub-agents propose; a single controlled point performs the irreversible action |
| Isolate context between specialists | A billing agent does not inherit a support conversation's sensitive detail |
| Log which agent acted with what authority | A misused delegation is traceable to the hand-off that granted it |
Pass a scoped task and a minimal tool set, and keep the irreversible actions at one gated level.
The fourth row is the anchor and it echoes every irreversible-action post in this series. However many agents are in the tree, the tools that do something you cannot undo should live at one controlled point, not be inherited freely down the chain. Sub-agents can recommend an irreversible action; a single gated level, with a human or a hard check, is what actually performs it. Then no amount of delegation spreads the power to do real harm, because that power was never delegated.
What this touches
For the frameworks, this maps to T14 Human Attacks on Multi-Agent Systems, which the pack defines as exploiting inter-agent delegation, trust relationships and workflow dependencies to escalate privileges, the confused-deputy path exactly. The over-broad grant itself is T3 Privilege Compromise, which the pack ties to dynamic role inheritance and over-permissioning, which is what "inherits the full conversation and tools" describes. In the OWASP Agentic Top 10 the anchors are ASI10 and ASI03.
On the regulatory side, framed as scope rather than a citation: least privilege, segregation of duties and data segregation are foundational obligations across GCC rulebooks, and a delegation model where a narrow specialist inherits broad authority and other users' data is a least-privilege and segregation failure those rules already govern, even though they pictured roles in an access-control matrix rather than agents in a tree. Which obligations apply depends on your regulator and architecture, and that mapping is an advisory estimate until someone checks it properly.
The part worth keeping
Delegation is what makes multi-agent systems work. A router that hands off to specialists, an orchestrator that calls experts, these are good designs, and the isolation that made agent-as-tool scale is genuinely valuable. Nothing here says flatten everything into one agent.
The point is that delegating a task should not mean delegating your authority. Pass down the slice of context and the set of tools the task needs, keep the irreversible actions at one gated level, and no sub-agent, however it is steered, holds more power than its job. Build the tree; just do not let authority flow down it unchecked.