{
  "slug": "agent-delegation-chains",
  "title": "Agent Delegation Chains: Credential Propagation in Multi-Agent Systems",
  "description": "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",
  "tags": [
    "identity",
    "oauth",
    "delegation",
    "multi-agent",
    "token-exchange",
    "security",
    "agents",
    "workload-identity"
  ],
  "updated": "2026-07-10",
  "canonical": "https://changegamer.ai/resources/agent-delegation-chains",
  "markdown": "https://changegamer.ai/resources/agent-delegation-chains.md",
  "outline": [
    {
      "depth": 2,
      "text": "Key facts",
      "anchor": "key-facts"
    },
    {
      "depth": 2,
      "text": "The multi-hop delegation problem",
      "anchor": "the-multi-hop-delegation-problem"
    },
    {
      "depth": 2,
      "text": "Audience binding across hops",
      "anchor": "audience-binding-across-hops"
    },
    {
      "depth": 2,
      "text": "Emerging IETF work (individual Internet-Drafts as of June 2026)",
      "anchor": "emerging-ietf-work-individual-internet-drafts-as-of-june-2026"
    },
    {
      "depth": 2,
      "text": "Standards bodies are converging on this",
      "anchor": "standards-bodies-are-converging-on-this"
    },
    {
      "depth": 2,
      "text": "Practical patterns for multi-agent builders",
      "anchor": "practical-patterns-for-multi-agent-builders"
    },
    {
      "depth": 2,
      "text": "Related ChangeGamer resources",
      "anchor": "related-changegamer-resources"
    },
    {
      "depth": 2,
      "text": "Verified sources",
      "anchor": "verified-sources"
    }
  ],
  "related": [
    {
      "slug": "agent-identity-authentication",
      "title": "Agent Identity and Authentication",
      "description": "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.",
      "url": "https://changegamer.ai/resources/agent-identity-authentication"
    },
    {
      "slug": "mcp-server-authentication",
      "title": "MCP Server Authentication: OAuth 2.1 for Remote Servers",
      "description": "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.",
      "url": "https://changegamer.ai/resources/mcp-server-authentication"
    },
    {
      "slug": "ai-supply-chain-provenance",
      "title": "AI Supply Chain Provenance: SBOMs, SLSA, and Artifact Signing for Agents and MCP Servers",
      "description": "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.",
      "url": "https://changegamer.ai/resources/ai-supply-chain-provenance"
    },
    {
      "slug": "c2pa-content-credentials",
      "title": "C2PA Content Credentials: Verifying Media Provenance and AI-Generation Claims",
      "description": "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.",
      "url": "https://changegamer.ai/resources/c2pa-content-credentials"
    }
  ],
  "body": "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.\n\n## Key facts\n\n- 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.\n- 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.\n- 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.\n- 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.\n- 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.\n- 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.\n\n## The multi-hop delegation problem\n\nRFC 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:\n\n- **`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.\n- **`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.\n\nThe 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.\n\n## Audience binding across hops\n\nRFC 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.\n\n## Emerging IETF work (individual Internet-Drafts as of June 2026)\n\n**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.\n\n**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.\n\n**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.\n\n## Standards bodies are converging on this\n\nNIST'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.\n\n## Practical patterns for multi-agent builders\n\n| Pattern | Mechanism | Key property |\n|---|---|---|\n| Per-hop token exchange | RFC 8693 `grant-type:token-exchange` | Each hop holds the narrowest token it needs |\n| Audience binding | RFC 8707 `resource` parameter | A token replayed to the wrong service is rejected |\n| Chain auditability | Nested `act` claim | Full delegation path recorded in every token |\n| Forward authorization | `may_act` claim in the subject token | Issuer pre-approves the next actor |\n| Cryptographic chain integrity | draft-mw-spice-actor-chain Verified profiles | Prevents chain-splicing attacks |\n| Agent-specific consent | draft-oauth-ai-agents-on-behalf-of-user `requested_actor` | User explicitly authorizes a named agent |\n\n- **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.\n- **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.\n- **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.\n- **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.\n\n## Related ChangeGamer resources\n\n- Single-agent workload identity and auth fundamentals: /resources/agent-identity-authentication\n- MCP server OAuth flows (audience binding, token-passthrough prohibition): /resources/mcp-server-authentication\n- Multi-agent orchestration topologies that create these chains: /resources/multi-agent-orchestration-patterns\n- Credential management and scopes in the broader checklist: /resources/agentic-security-checklist\n\n## Verified sources\n\n- RFC 8693 — OAuth 2.0 Token Exchange (IETF, January 2020): https://datatracker.ietf.org/doc/html/rfc8693\n- RFC 8707 — Resource Indicators for OAuth 2.0 (IETF, February 2020): https://datatracker.ietf.org/doc/html/rfc8707\n- draft-mw-spice-actor-chain (Cryptographically Verifiable Actor Chains): https://datatracker.ietf.org/doc/draft-mw-spice-actor-chain/\n- 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/\n- 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\n- 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\n- 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/",
  "sources": [
    "https://datatracker.ietf.org/doc/html/rfc8693",
    "https://datatracker.ietf.org/doc/html/rfc8707",
    "https://datatracker.ietf.org/doc/draft-mw-spice-actor-chain/",
    "https://datatracker.ietf.org/doc/draft-oauth-ai-agents-on-behalf-of-user/",
    "https://www.nccoe.nist.gov/news-insights/new-concept-paper-identity-and-authority-software-agents",
    "https://csrc.nist.gov/pubs/other/2026/02/05/accelerating-the-adoption-of-software-and-ai-agent/ipd",
    "https://datatracker.ietf.org/doc/draft-mw-oauth-actor-chain/"
  ]
}