Academy · AI agent security

Agent-to-agent delegation. Whose access is it at the end of the chain?

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.

support-agentAnswers outside requestsEntry
data-agentCalled by support-agent
reporting roleHeld by data-agent, not by support-agent
customer dbReached with the second identityReached
KEY TAKEAWAYS
  • When agent A calls agent B, the only question that matters is whose identity B acts with.
  • The classic failure is confused deputy: B has more access than A, and A can make B use it.
  • Passing the original identity through is safer and harder. Passing nothing is easier and loses all attribution.
  • The chain multiplies reach. Each agent adds its own permissions to what the first caller can achieve.

Published Last reviewed

THE RISKS

Four things that go wrong in a chain.

All four are design decisions rather than bugs, which means they are decided once and then inherited by everything built afterwards.

01
The confused deputy, with agents

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.

02
Three ways to pass identity, all with costs

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.

03
Reach adds up along the chain

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.

04
The audit trail breaks at the first delegation

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.

PATTERNS

Four delegation patterns.

The second row is what most systems do by default, and it is the one that produces confused deputy behaviour.

PatternAttributionBlast radiusCost
Pass the caller identity throughFull: the log names the original requester.Limited to what the caller could do.Hardest to build, needs support end to end.
Act as the serviceNone: every caller looks the same.Everything the service can do, for anyone.Easiest, and the usual default.
Mint a scoped token per stepGood, with a correlation identifier.Scoped to the task.Needs a token service to run.
Human approval at the boundaryFull, with a decision on record.Limited to what was approved.Slow, only workable for rare actions.
PRACTICE

How to build one safely. Four steps.

Step one is the only one that is cheap now and expensive later.

01Decide the identity model before the first chain

This is a design decision that is almost impossible to retrofit, because every agent built afterwards assumes whatever the first one did.

02Give the downstream agent the narrower scope

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.

03Carry a correlation identifier even when you cannot carry identity

It costs little and it is the difference between an incident you can reconstruct and one you cannot.

04Put approval on the step that is hard to undo

Not on every delegation, which trains people to click through, but on the few actions where being wrong is expensive.

FAQ

Questions, answered.

Short answers on agent-to-agent delegation.

What is the confused deputy problem in agent chains?

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.

Should agents pass the original user identity through?

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.

How do you measure the reach of an agent chain?

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.

See what your agents can reach. Before someone else does.

Book a demo and we walk through the access paths in an environment like yours.