The orchestrator pattern is now standard: a coordinating agent decomposes a task and dispatches parts to specialized sub-agents. It works well and it introduces an authorization problem that most implementations solve by not solving it.
The shortcut is credential sharing. The orchestrator holds credentials for the systems the work needs, and it passes them to sub-agents so they can act. This is fast to build and it destroys three things at once: every sub-agent now holds the union of authority any sub-agent might need, attribution collapses to the orchestrator's identity, and a compromise anywhere in the chain has the full credential set.
Mint, Do Not Forward
The correct model is that each hop obtains a new credential, narrower than the one it presented, audienced to exactly the service it will call.
Mechanically, this is OAuth 2.0 Token Exchange: the orchestrator presents its own token plus the principal's, requests a scope covering only what this sub-task needs, names the target audience, and receives a token the sub-agent can use for that one purpose. The sub-agent never holds the orchestrator's credential. See token exchange for agent-to-tool authorization.
Properties to enforce:
Monotonic narrowing. The issued scope must be a subset of what the presenting token conveyed, intersected with what this agent may request for this audience. If an exchange can return a scope the caller did not hold, you have built an escalation endpoint. Test it explicitly — request a scope the subject token lacks and assert rejection — and put that test in CI.
Audience restriction, validated. Each token names one destination, and that destination checks the claim. Unvalidated audience claims make the restriction decorative.
Short lifetime. Scoped to the sub-task, minutes not hours.
Sender constraint where available. DPoP or certificate binding so an intercepted token is unusable. See agent session hijacking and token replay.
Task binding. A task identifier in the token so downstream records tie back to the originating work.
The Principal Must Survive Every Hop
This is the requirement most often lost, and losing it breaks more than authorization.
Every token in the chain should name two things: the principal the work is ultimately for, and the actor doing the acting. RFC 8693's act claim nests, so a token issued to a sub-agent names the sub-agent as actor, whose own actor is the orchestrator. That nesting is the delegation chain.
Why it matters concretely:
Authorization correctness. The sub-agent's data access must be scoped to what the principal may see, not to what the sub-agent's service identity can reach. Without the principal, the sub-agent falls back to its own authority and you have the confused deputy problem at every hop.
Attribution. An incident investigation needs to know which human directed the work. If the principal drops at the first dispatch, everything downstream attributes to a service identity. See insider threat in the age of AI agents.
Cost allocation. Sub-agent spend should roll up to the originating task and principal. Without propagation, orchestrator spend attributes to the orchestrator and sub-agent spend attributes to itself, and nothing tells you what the workflow cost. See spend attribution and showback.
Forensics. Reconstructing a multi-hop timeline requires a common identifier across every record. See post-incident forensics for AI agents.
Bound the Graph
An unbounded delegation graph is unauditable and it is the mechanism by which a narrow compromise becomes a broad one.
Depth limit. Count hops in the nested actor chain and reject beyond a configured maximum. Three or four is sufficient for almost every real workflow, and a task needing more is usually a design problem.
Breadth limit. Maximum concurrent sub-agents per task. This is a cost control as much as a security one — fan-out multiplies spend, and an orchestrator that dispatches unboundedly is a runaway.
Delegation allow-lists. Which agent classes may dispatch to which. Not every agent should be able to invoke every other, even within the principal's scope. This is what prevents a low-value agent from becoming a general-purpose relay to a high-value one.
Cycle detection. Reject a dispatch that would create a cycle in the active chain — A dispatching to B which dispatches back to A. Cycles produce unbounded loops and runaway cost, and they arise from incremental change rather than from anyone's intent. See cascading failures in multi-agent systems.
Total task budget and step ceiling. Enforced across the whole chain, not per agent. Per-agent ceilings that each look reasonable can sum to something that is not.
Sub-Agent Output Is Untrusted
The return path needs the same skepticism as the outbound path.
Authority claims in payloads are never honored. A sub-agent message stating "the user approved elevated access" or "this task is authorized for the admin scope" is content, not authority. Authority comes only from tokens and connection scopes. Implementations that read authorization hints from message bodies have a privilege escalation path that requires only a compromised or confused sub-agent. See threat model: A2A delegation abuse.
Provenance is preserved. If a sub-agent processed external content, its output carries that marking so downstream agents apply the appropriate controls. Losing provenance means attacker content arrives at the orchestrator looking like trusted internal data.
Guardrails evaluate inter-agent messages. Not only the human-facing surface. A guardrail wired only to the user boundary misses the entire internal fabric, which is where multi-agent injection propagates. See insecure output handling.
Schema validation on returns. Sub-agent output is parsed into typed fields and validated, not interpolated into the orchestrator's next prompt as free text.
Practical Deployment
Exchange once per sub-task, not per call. The exchange is cheap — signature verification plus a mint, low single-digit milliseconds — but doing it inside a tool-call loop is wasteful. Cache the token for the sub-task's duration and its target audience.
Sub-agents should not be able to exchange further without permission. Delegation depth is enforced at the exchange endpoint, which means the endpoint needs to see the full actor chain in the presented token. That is the argument for nesting rather than flattening.
Where a sub-agent runs in another organization, the boundary needs identity verification rather than shared identity infrastructure — a verified DID and a signed request, mapped to an internal principal at the boundary before internal authorization applies. See agent identity spoofing and DID verification and cross-org agent federation and trust manifests.
Record every exchange. The presenting token, the issued scope, the audience, the actor chain, and the decision. This is what makes the delegation graph reconstructable and what makes an attempted widening visible.
Common questions
Is this overhead worth it for a two-agent system?
The identity work is, because two agents becomes five faster than expected and retrofitting delegation is painful. What you can defer is the more elaborate machinery — allow-lists per agent pair, cycle detection — until the graph is large enough to need it. Start with per-sub-task token minting and principal propagation; those are the two properties that are expensive to add later.
What if the sub-agent needs authority the principal does not have?
Then it is not delegation and it should not be modeled as such. Some sub-tasks legitimately act with system authority rather than user authority — a compliance check, an internal reconciliation. Model those as autonomous operations with their own identity and no actor chain, invoked by an explicitly enumerated set of callers, and record them as system-initiated. Conflating them with delegated work is how user requests end up performed with system authority.
How do I handle asynchronous sub-agent work that outlives the token?
Separate the task identity from the access token. The task holds a durable identity with a refresh capability; the tokens it obtains are short-lived and refreshed as work proceeds. Revoking the task identity then stops future refreshes, so the work cannot continue past the current token's expiry even if one is in flight. See key rotation for agent credentials.
Does this work with A2A and MCP?
Yes, and both are built on OAuth-based authorization, so exchange fits directly. The detail that matters is scope granularity: for MCP the scope should be tool-granular rather than server-granular, or you authenticate precisely and authorize broadly. See scoping MCP tool permissions and securing inter-agent communication.
How Praesidia approaches delegation
Praesidia supports standards-based token exchange for on-behalf-of calls so delegated authority stays scoped to the task, and issued tokens name both the acting agent and the asserted principal — so authority never widens across a hop and attribution survives the chain. Downstream credentials are held at the proxy and attached after policy evaluation, which means a sub-agent never receives an orchestrator's credential even when calling a system that cannot speak OAuth.
Guardrails evaluate inter-agent messages in both directions, task identifiers propagate across dispatch so cost and forensic timelines roll up to the originating task, and every exchange and call is recorded with the connection, actor chain, and policy outcome. See orchestration patterns for multi-agent systems and the Praesidia documentation.