← All posts

Scoped delegation: agent handoffs should narrow, not copy

Real agent systems are rarely a single agent. A planner breaks a goal into steps and hands one to a researcher; the researcher hands a narrower task to a tool-runner; that runner calls an external API. Work flows down a chain, and at every hop someone is acting on behalf of someone else.

The question that decides whether this is safe: what does each hop carry?

Copying a credential down the chain is the problem

The path of least resistance is to pass the same credential along. The planner has an API key, so it hands that key to the researcher, which hands it to the runner. Now three agents hold the same full-power secret, and the thing at the bottom of the chain — the one most exposed to untrusted input — has exactly as much authority as the one at the top.

That is privilege sprawl by construction. A prompt injection three hops deep inherits the planner's entire blast radius. And when something goes wrong, you can't revoke one agent's access without cutting off all of them, because they're all the same key.

Delegation should subtract, never add

The fix is to make each handoff a narrowing operation. When an agent delegates, it grants a subset of what it holds — never more — and that grant is its own thing, with its own lifetime, that can be pulled back independently.

In AgentTrust ID, a delegation has four properties that hold at every hop:

  • Scope narrows. The child receives a subset of the parent's permissions. If the planner can web:search, code:exec, and file:read, it might delegate only web:search and code:exec to the researcher, which delegates only web:search onward. Scope can shrink down the chain; it can never grow.
  • Its own TTL. Each grant expires on its own clock, independent of the parent. A short-lived handoff for one task doesn't linger.
  • Independently revocable. You can revoke one hop without touching the others. Cut the researcher's grant and the planner keeps working; the runner below loses access immediately.
  • Bounded depth, no self-delegation. Chains have a maximum depth, and an agent can't delegate to itself to escape its own limits.

The result is least privilege that actually survives contact with a multi-agent system. The agent most exposed to untrusted input ends up with the least authority, which is exactly backwards from the copy-the-key approach — and exactly right.

Why it matters at runtime

Static credentials have no concept of "a subset, for five minutes, revocable." So teams either over-share one powerful key or hand-build delegation plumbing for every handoff. Making delegation a first-class, scoped, revocable primitive means the safe path is also the easy one: an agent asks to pass on part of what it holds, the platform records the chain, and you can see — and sever — any link in it.

Handoffs are where authority quietly accumulates. Narrowing at every hop is how you keep it from piling up where you least want it.