# Agent Delegation Chains: Credential Propagation in Multi-Agent Systems

> 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.

Category: Reference · Updated: 2026-07-10 · Tags: identity, oauth, delegation, multi-agent, token-exchange, security, agents, workload-identity
Canonical: https://changegamer.ai/resources/agent-delegation-chains
Variants: [HTML](https://changegamer.ai/resources/agent-delegation-chains) · [JSON](https://changegamer.ai/api/resources/agent-delegation-chains.json)
License: https://changegamer.ai/license.xml · Access: free

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

| Pattern | Mechanism | Key property |
|---|---|---|
| Per-hop token exchange | RFC 8693 `grant-type:token-exchange` | Each hop holds the narrowest token it needs |
| Audience binding | RFC 8707 `resource` parameter | A token replayed to the wrong service is rejected |
| Chain auditability | Nested `act` claim | Full delegation path recorded in every token |
| Forward authorization | `may_act` claim in the subject token | Issuer pre-approves the next actor |
| Cryptographic chain integrity | draft-mw-spice-actor-chain Verified profiles | Prevents chain-splicing attacks |
| Agent-specific consent | draft-oauth-ai-agents-on-behalf-of-user `requested_actor` | User explicitly authorizes a named agent |

- **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/

---

## Related resources

- [Agent Identity and Authentication](https://changegamer.ai/resources/agent-identity-authentication.md): How autonomous agents prove who they are and get authorized to act: workload identity vs. delegated authority, SPIFFE/SPIRE, cloud workload federation, OAuth token exchange, audience binding, and emerging standards — with practical guidance and verified sources.
- [MCP Server Authentication: OAuth 2.1 for Remote Servers](https://changegamer.ai/resources/mcp-server-authentication.md): How OAuth 2.1 works for remote MCP servers: transport differences, Protected Resource Metadata discovery, PKCE, Resource Indicators, and token-audience security — with a step-by-step client flow and honest notes on what ChangeGamer's own /mcp endpoint does.
- [AI Supply Chain Provenance: SBOMs, SLSA, and Artifact Signing for Agents and MCP Servers](https://changegamer.ai/resources/ai-supply-chain-provenance.md): How CycloneDX AI/ML-BOM, SPDX AI profiles, SLSA build levels, and in-toto/Sigstore signing let an agent check what is actually inside a model, package, or MCP server — and how it was built — before trusting it.
- [C2PA Content Credentials: Verifying Media Provenance and AI-Generation Claims](https://changegamer.ai/resources/c2pa-content-credentials.md): How the C2PA standard cryptographically signs images, video, and audio with provenance manifests recording capture, edit, and AI-generation history — what a manifest contains, how a verifier checks one, and why a missing manifest proves nothing either way.

---

Index of all resources: https://changegamer.ai/llms.txt · Full corpus: https://changegamer.ai/llms-full.txt · Corpus data (NDJSON): https://changegamer.ai/api/corpus.jsonl · Offers: https://changegamer.ai/api/pricing.json