One agent calling another looks like a function call and behaves like a delegation of authority. The question nobody answers at design time is which identity the last call runs as, and that is the question the whole risk hangs on.
Published Last reviewed
All four are design decisions rather than bugs, which means they are decided once and then inherited by everything built afterwards.
A classic problem in a new place. A low-privilege agent asks a high-privilege agent to do something, and the second one performs it with its own authority because nothing told it to check who asked. The second agent is not compromised, it is being helpful.
Carry the original caller identity through the chain, which preserves attribution and is the hardest to build. Act as the service, which is simple and makes every caller look identical. Or mint a scoped token per step, which is the middle path and adds a token service to operate.
An agent chain reaches the union of every identity in it. A reach assessment that stops at the first agent understates the picture by exactly the permissions of everything downstream.
If the second agent acts as itself, its log shows itself. The connection back to the original request exists only if something carried a correlation identifier, and most frameworks do not by default.
The second row is what most systems do by default, and it is the one that produces confused deputy behaviour.
| Pattern | Attribution | Blast radius | Cost |
|---|---|---|---|
| Pass the caller identity through | Full: the log names the original requester. | Limited to what the caller could do. | Hardest to build, needs support end to end. |
| Act as the service | None: every caller looks the same. | Everything the service can do, for anyone. | Easiest, and the usual default. |
| Mint a scoped token per step | Good, with a correlation identifier. | Scoped to the task. | Needs a token service to run. |
| Human approval at the boundary | Full, with a decision on record. | Limited to what was approved. | Slow, only workable for rare actions. |
Step one is the only one that is cheap now and expensive later.
This is a design decision that is almost impossible to retrofit, because every agent built afterwards assumes whatever the first one did.
If one agent in the chain must be broad, make it the one that is called least and guarded most, not the one answering outside requests.
It costs little and it is the difference between an incident you can reconstruct and one you cannot.
Not on every delegation, which trains people to click through, but on the few actions where being wrong is expensive.
Short answers on agent-to-agent delegation.
A low-privilege agent asks a higher-privilege agent to perform an action, and the second agent carries it out with its own authority because nothing told it to check who was asking. No credential is stolen and nothing is exploited. The second agent is simply being useful with permissions the requester does not have.
Where the systems support it, yes. It preserves attribution and keeps the blast radius at what the original caller could do anyway. It is also the hardest pattern to build, because every system in the chain has to accept a delegated identity, which is why most implementations act as the service instead.
As the union of every identity in it, not the first one. If agent A can call agent B, A effectively reaches everything B reaches. A reach assessment that stops at the first agent understates the picture by exactly the permissions of everything downstream.
The pages that belong to the same picture.
Book a demo and we walk through the access paths in an environment like yours.