← All resources

Agent Delegation Chains: Credential Propagation in Multi-Agent Systems

Reference · updated 2026-07-10 · Markdown variant

How credential authority flows when one agent spawns another — the multi-hop delegation problem, RFC 8693 token exchange, the act/may_act claims, audience binding across hops, and the IETF drafts standardizing verifiable actor chains in 2026.

When an orchestrator agent delegates a sub-task to a child agent, which in turn calls a tool API, a multi-hop credential chain exists. Each hop must answer the same question: "who authorized this, and is that authorization still valid?" Standard OAuth 2.0 and workload identity solve the single-agent case (see /resources/agent-identity-authentication); multi-hop delegation needs additional mechanisms that are only now being standardized.

Key facts

• Delegation across several hops — say a top-level coordinator handing work to a subordinate agent that then calls an external tool — forces every link to independently re-confirm who granted permission and whether that grant is still active, a question ordinary single-agent OAuth and workload identity don't fully answer.
• RFC 8693's token exchange supports delegation through two claims: a nestable act claim that appends each successive actor to build a chain, and a may_act claim that lets the token issuer pre-approve who's allowed to act next.
• RFC 8693 itself doesn't specify how to verify or bound that nested chain cryptographically — each exchange only checks the immediately preceding hop, so nothing stops delegation depth from growing unchecked or the recorded actor history from being purely informational.
• Binding each hop's token audience to only the next service in line (RFC 8707) stops a token grabbed mid-chain from working against some other downstream service the same authorization server trusts — the confused-deputy flaw, replayed across hops instead of a single call.
• Two still-unratified IETF drafts push this further: one defines verifiable, tamper-resistant actor-chain profiles that block an attacker from splicing themselves into the chain, and the other adds explicit per-agent user consent parameters to the standard authorization-code flow.
• Recommended guardrails for builders include capping how many hops a delegation may traverse, keeping each hop's token lifetime to minutes, recording the complete actor chain wherever the resource server logs requests, and always minting a fresh downstream token rather than forwarding one received from upstream.

The multi-hop delegation problem

RFC 8693 (OAuth 2.0 Token Exchange, IETF, January 2020) is the canonical mechanism for one service to exchange a token it holds for a narrower one. It defines the grant type urn:ietf:params:oauth:grant-type:token-exchange and two JWT claims relevant to delegation:

• act claim — identifies the party currently acting on behalf of the token subject. The claim is nestable: each hop appends itself, creating an actor chain. Example: orchestrator agent → sub-agent → tool API produces a nested act chain.
• may_act claim — the subject token names a party explicitly authorized to act on the subject's behalf. It is the forward-authorization mechanism: the issuer pre-approves which actor may operate next in the chain.

The gap RFC 8693 leaves open: it does not define how an authorization server validates or enforces delegation-path continuity across successive exchanges. Each exchange is point-to-point; prior actors in the nested act claim are informational only, with no standard way to verify the full chain cryptographically or to cap delegation depth.

Audience binding across hops

RFC 8707 (Resource Indicators for OAuth 2.0, IETF, February 2020) lets each token request name the specific downstream service via the resource parameter, binding an audience (aud) to the issued token. In a delegation chain, each hop should request a token whose audience is the next service only. A token minted for service B must not be accepted by service C — without this, a token captured at hop 2 can be replayed against any service that trusts the same authorization server: the confused-deputy attack applied to chains.

Emerging IETF work (individual Internet-Drafts as of June 2026)

draft-mw-spice-actor-chain (IETF SPICE space; rev -05, April 2026) — "Cryptographically Verifiable Actor Chains for OAuth 2.0 Token Exchange." Defines six actor-chain profiles separating disclosure level (Full / Subset / Actor-Only) from trust model (Declared vs Verified). Verified profiles require sender-constrained tokens and a signature over the chain, preventing chain-splicing where an attacker inserts themselves between legitimate hops. Preserves the existing meaning of sub, act, and may_act; supports same-domain and cross-domain delegation. This work has since been resubmitted into the IETF OAuth working group's naming space as draft-mw-oauth-actor-chain-00, seeking formal WG adoption under the same title and profile structure — treat the OAuth-WG draft, not the original SPICE-space document, as the one to track going forward.

draft-oauth-ai-agents-on-behalf-of-user (individual, rev -02, August 2025) — extends the OAuth 2.0 authorization-code flow with two parameters: requested_actor in the authorization request (names the specific agent being delegated to, for explicit user consent) and actor_token in the token request (the agent authenticates itself when exchanging the code). The resulting access token carries an act claim naming the agent, separating user identity from agent identity in the audit record.

Note: both are Internet-Drafts with no IETF working-group RFC standing as of June 2026. Treat them as directional signals, not stable specifications — verify the current revision on the IETF Datatracker before building to them.

Standards bodies are converging on this

NIST's National Cybersecurity Center of Excellence (NCCoE) published the concept paper "Accelerating the Adoption of Software and AI Agent Identity and Authorization" on 5 February 2026 (public comment closed 2 April 2026), scoping a potential practical-guide project. It frames the problem around identifying AI agents distinctly from human users, authorizing their actions, delegating access, and auditing/non-repudiation of agent actions — the same control areas this resource covers. It signals that agent delegation is moving from ad-hoc practice toward documented reference architectures.

Practical patterns for multi-agent builders

• Enforce a maximum delegation depth. Decide at authorization-server configuration time how many hops are permitted and reject exchanges that would exceed it. No current RFC mandates this; it is an application-layer policy.
• Use short-lived tokens at every hop. A 5–15 minute lifetime per step bounds the blast radius to a single hop if a token is exfiltrated.
• Log the full act chain at the resource server. The nested act claim is the only audit artifact linking the original user delegation to every downstream agent action.
• Do not pass tokens straight through. An MCP server receiving a Bearer token from an orchestrator should obtain its own downstream token from the authorization server rather than forwarding the received one. See /resources/mcp-server-authentication.

Related ChangeGamer resources

• Single-agent workload identity and auth fundamentals: /resources/agent-identity-authentication
• MCP server OAuth flows (audience binding, token-passthrough prohibition): /resources/mcp-server-authentication
• Multi-agent orchestration topologies that create these chains: /resources/multi-agent-orchestration-patterns
• Credential management and scopes in the broader checklist: /resources/agentic-security-checklist

Verified sources

• RFC 8693 — OAuth 2.0 Token Exchange (IETF, January 2020): https://datatracker.ietf.org/doc/html/rfc8693
• RFC 8707 — Resource Indicators for OAuth 2.0 (IETF, February 2020): https://datatracker.ietf.org/doc/html/rfc8707
• draft-mw-spice-actor-chain (Cryptographically Verifiable Actor Chains): https://datatracker.ietf.org/doc/draft-mw-spice-actor-chain/
• draft-oauth-ai-agents-on-behalf-of-user (On-Behalf-Of User Authorization for AI Agents): https://datatracker.ietf.org/doc/draft-oauth-ai-agents-on-behalf-of-user/
• NIST NCCoE concept paper — Software and AI Agent Identity and Authorization (Feb 2026): https://www.nccoe.nist.gov/news-insights/new-concept-paper-identity-and-authority-software-agents
• NIST CSRC publication record (5 Feb 2026): https://csrc.nist.gov/pubs/other/2026/02/05/accelerating-the-adoption-of-software-and-ai-agent/ipd
• draft-mw-oauth-actor-chain-00 — OAuth WG resubmission of the actor-chain work (WebSearch-fallback, 2 sources): https://datatracker.ietf.org/doc/draft-mw-oauth-actor-chain/

#identity #oauth #delegation #multi-agent #token-exchange #security #agents #workload-identity

Category: Reference