# What is an Agent Delegation Chain? An agent delegation chain is the ordered record of every agent hop, carrying identity, scope, budget, and audit at each link. The primitive behind A2A. # What Is an Agent Delegation Chain? An **agent delegation chain** is the ordered record of every agent hop from the human who initiated a task down to the agent currently acting. Each link in the chain carries the agent's identity, its narrowed scope, its remaining budget, and the tools it's permitted to use. The chain lets every downstream system answer two questions every request should already be answering: *who originally asked for this, and under what authority is this agent acting on their behalf right now?*

A delegation chain: originSub persists; scopes narrow at each hop; budget propagates but never increases; every link is audited.

--- ## The Short Version In a single-agent system, identity is easy: a human authenticates, their JWT rides every request, and the backend verifies it. Simple. In a multi-agent system, identity is hard. The human starts the run; then agent A delegates to agent B; then agent B calls agent C; then agent C makes a tool call. By the time the tool call reaches a real backend system, *four* parties are involved — but typically only one identity is attached: a shared service account or API key. A delegation chain fixes this. It's a data structure that carries: - **originSub** — the human at the root. Never changes through any hop. - **A list of links** — one per agent, in order. Each link records: agent name, effective scopes, effective tools, remaining budget, timestamp. - **Invariants** — scopes can only narrow (never widen), budgets can only decrease, cycles are forbidden, and every hop is audited. With a delegation chain, a downstream system always knows who ultimately asked, which agent is currently acting, and whether the current agent has authority to do the specific thing it's trying to do. --- ## Why Delegation Chains Exist The need for delegation chains emerged from practical pain in production multi-agent systems. Three specific problems drove the design: **1. Over-privileged delegation.** When agent A delegates to agent B via a shared API key, agent B has the same access as agent A. If agent A could write to Salesforce, so can agent B — even if agent B was only supposed to send a Slack message. Without scope narrowing at each hop, delegation silently expands privilege. **2. Identity loss across hops.** Audit logs in multi-agent systems routinely say "the AI did it" with no attribution to the human who initiated the work. That's fine until regulation, a security incident, or a customer complaint demands "who specifically authorized this particular action." With no delegation chain, the answer is unknowable. **3. Cycles and unbounded delegation.** Without structural limits, an agent can delegate to another agent that delegates to another agent that delegates back to the first. Budgets don't propagate. Quotas don't decrement. Stacks get deep and costs spiral. Delegation chains bound these failure modes. The concept isn't new in spirit — it's an extension of OAuth's on-behalf-of flow, SPIFFE's workload identity, and Kerberos-style delegation tickets. What's new is the need for it in AI agent contexts, where delegation happens at high frequency, often between autonomous agents with different scope requirements, and often across organizational boundaries. --- ## How a Delegation Chain Works Concretely, a delegation chain is a linked list of **delegation links**. The chain starts with a human (the `originSub`) and extends by one link each time an agent delegates to another agent. Here's a simplified view of the data structure: ```ts interface DelegationChain { originSub: string; // the human at the root — never changes originClaims: Record; links: DelegationLink[]; // [0] = first agent; [last] = current agent depth: number; } interface DelegationLink { agentProfileId: string; // the type of agent (what it is) agentRunId: string; // this specific run (unique per invocation) agentName: string; effectiveScopes: string[]; // narrowed via scope intersection effectiveTools: string[]; // narrowed via tool intersection remainingBudgetCents: number; // propagated from parent, never increased delegatedAt: string; // ISO 8601 timestamp parentAgentRunId?: string; // explicit parent link } ``` Two invariants always hold: 1. **`originSub` never changes.** No matter how deep the chain goes, the human at the root is always recorded. You can always trace any action back to the person who started the run. 2. **Scopes only narrow; budgets only decrease; cycles are forbidden.** Each delegation link's scopes are the intersection of the parent's scopes and the child's requested scopes. Budgets propagate but never increase. Cycles are detected and rejected at delegation time.

Effective scopes are always the intersection. A child can only receive permissions the parent already has — monotonically narrowing down the chain.

See [Agent-to-Agent Governance](/agent-to-agent) for the full product view, and the [ADCS open specification](/spec/delegation-chain) for the normative rules (RFC 2119 conformance language, JSON Schema, and conformance test vectors). --- ## Six Normative Rules (from the ADCS spec) The **Agent Delegation Chain Specification (ADCS)** is Agentic Control Plane's open specification for delegation chains. It's free, MIT/CC BY 4.0, and has a reference implementation in production. ADCS defines six normative rules every delegation chain must satisfy: 1. **Origin invariant** — `originSub` is set at chain creation and never modified. 2. **Scope intersection** — each child link's effective scopes are a subset of the parent link's effective scopes. 3. **Budget propagation** — child budget ≤ parent's remaining budget; child consumption decrements the parent. 4. **Cycle prevention** — an agent cannot appear twice in the same chain (within configured depth). 5. **Type vs runtime identity** — `agentProfileId` identifies what kind of agent; `agentRunId` identifies this specific invocation. Both matter. 6. **Audit emission** — every delegation event emits an audit record with full chain state. The spec is implementable on top of any transport — MCP, HTTP, gRPC, A2A. You bring the plumbing; ADCS tells you what to carry.

Cycles are detected when a new delegation would cause any agent to appear twice in the chain. The request is rejected before execution.

--- ## When You Need a Delegation Chain You need a delegation chain any time agent A invokes agent B on behalf of a human user. In practice, that's the moment you have: - A **supervisor/worker pattern** (common in LangGraph, CrewAI, OpenAI Agents SDK handoffs) - **Sub-agents** (Claude Agent SDK Skills invoking sub-Skills; Claude Code subagents) - **Tool servers that call other tool servers** (MCP server A proxying to MCP server B) - **Cross-organizational agent invocation** (your agent calling a partner's agent) If you have any of these patterns and you're using a shared service account or API key, you have a delegation problem waiting to produce an incident. [Agentic Control Plane](/what-is-an-agentic-control-plane) implements delegation chains directly; see the [reference architecture](/reference-architecture). --- ## Delegation Chains in the Wild The terminology "agent delegation chain" is crystallizing across industry and research: - **Academic grounding:** arXiv paper [*Authenticated Delegation and Authorized AI Agents*](https://arxiv.org/abs/2501.09674) (MIT/Harvard, Jan 2025) formalizes the authorization delegation problem for AI agents. A second paper — [*SentinelAgent*](https://arxiv.org/abs/2604.02767) — studies delegation-chain integrity attacks. - **Standards activity:** IETF draft `draft-klrc-aiagent-auth-01` proposes authentication primitives for AI agents. - **Vendor commentary:** Okta, Cloud Security Alliance, Kiteworks, and Scalekit have all published pieces using the exact phrase "delegation chain." - **Open specification:** [ADCS (Agent Delegation Chain Specification)](/spec/delegation-chain) from Agentic Control Plane is the first open spec specifically targeting this problem, with a reference implementation. The field is still early, but the abstraction has clearly clicked for the industry. --- ## Related Concepts **Delegation chain vs OAuth on-behalf-of (OBO):** OAuth OBO is a single-hop delegation primitive. Delegation chains extend that to arbitrary depth, with scope/budget propagation at each hop and structural cycle prevention. **Delegation chain vs SPIFFE workload identity:** SPIFFE solves workload identity (who is this service?). It doesn't answer "on whose behalf is this workload acting right now?" Delegation chains layer on top of SPIFFE-like workload identity. **Delegation chain vs trace context:** OpenTelemetry trace context propagates request IDs for observability. Delegation chains propagate *authorization state*. Both are chain-shaped; they serve different audiences (dev vs compliance) and shouldn't be conflated. **Delegation chain vs handoff:** A "handoff" (in OpenAI Agents SDK, CrewAI, LangGraph) is a transport-level event. A delegation chain is the authorization shape that should accompany every handoff. --- ## FAQ **Is a delegation chain the same as an audit log?** No. An audit log records what happened. A delegation chain records the *authorization context* that existed at each hop when it happened. The audit log is a readable output; the chain is the data structure enforced in real time. **Can delegation chains work across organizations?** Yes, with the right trust model. ADCS supports cross-organizational chains where each party signs its own links. Practical interop requires a trust-establishment protocol (mutual TLS, federated identity, or a purpose-built handshake). **Does every agent call need a chain?** Every agent call that runs *on behalf of a human user* needs a chain. Autonomous agents with no human delegation (e.g., scheduled background jobs that don't represent a user) operate under a service-account model, not a chain. **How deep can a chain go?** ACP caps delegation depth per plan — typically 4-8 hops for most workflows. Cycles are forbidden regardless of depth. If you're hitting chain-depth limits, that's usually a sign the agent topology is too deep and should be flattened. **What happens when a chain fails validation?** The governance layer denies the action and writes an audit entry explaining which invariant failed (cycle detected, scope widening attempted, budget exceeded, unknown parent link, etc.). The downstream system never sees the request. **Are delegation chains related to Forrester's Agent Control Plane market?** Yes. Forrester's announced market evaluation of the Agent Control Plane category identifies delegation-chain governance as a core capability. ACP's ADCS spec is one industry attempt to standardize how the data structure should look. --- ## Further Reading - [ADCS — The Open Spec](/spec/delegation-chain) — normative rules, JSON Schema, conformance vectors - [Agent-to-Agent Governance](/agent-to-agent) — the product view - [What Is an Agentic Control Plane?](/what-is-an-agentic-control-plane) — where delegation chains fit - [Agent Identity](/agent-identity) — the identity primitives delegation chains depend on - [Three-Axis Governance](/three-axis-governance) — tool / agent / user policy at every link - Blog: [EU AI Act Article 14 and AI Agent Delegation Chains](/blog/eu-ai-act-article-14-ai-agent-delegation-chains) - Academic: [Authenticated Delegation and Authorized AI Agents](https://arxiv.org/abs/2501.09674) (arXiv 2501.09674) - Academic: [SentinelAgent](https://arxiv.org/abs/2604.02767) (arXiv 2604.02767)