Multi-agent delegation

The hardest case, and the one auth51 was built for: a run that isn’t one agent but several, with a supervisor planning, workers executing, and each calling tools. This flow puts the other three together and shows how authority stays bounded as work is handed down a chain.

The shape of a multi-agent run

A supervisor agent receives the goal and produces a plan; it delegates steps to worker agents, each with its own identity and its own grant. A worker does the actual tool call (read a repo, open a PR), and it’s the worker, not the supervisor, that mints the intent token for that action. Every agent in the run is a distinct identity, registered separately, even though they share one client application.

Each hop mints against its own grant

This is what keeps a hand-off from manufacturing authority. A worker invoked by a supervisor mints against the worker’s grant, not the supervisor’s. If the worker’s grant doesn’t include the scope the action needs, the mint is denied. The supervisor can’t lend authority it has but the worker doesn’t. Authority flows down the chain and can only narrow, never widen.

The chain rides in the token

The token the worker gets carries the hashed delegation chain and step sequence. So the resource server on the far end doesn’t just see “a worker called”. It sees the ordered path that led here, and can detect a tampered or reordered chain itself, without calling back to the Authority. Who asked and who acted are both recorded, and neither can be forged after the fact.