Chains Without Anchors
Modern agentic architectures rarely involve a single agent acting alone. An orchestrator agent decomposes a user request, spawns sub-agents for specialized tasks, and those sub-agents may themselves spin up tools, call APIs, or delegate further. Each hop in that chain is a delegation event — a transfer of some portion of the original user's authorization to a downstream component.
The problem is that most frameworks — CrewAI, AutoGen, MetaGPT, LangGraph — treat delegation as a plumbing concern rather than a security one. When the orchestrator agent hands a task to a sub-agent, it typically passes along its own credentials or derives new ones with scope identical to its own. Scope narrows only if someone explicitly codes the narrowing. In practice, almost nobody does.
The result is scope amplification through delegation. A user who authorized "summarize my emails" may have their email credentials passed intact through a three-hop chain, with the final agent holding the same read/write/delete access that the orchestrator held — far more than the leaf-level task requires. Each hop is a new potential point of compromise. Each additional hop that passes broad credentials is a multiplier on blast radius.
Intent
Agent
Sub-Agent
Caller
Access
The Chain Splicing Vulnerability
RFC 8693 defines the token exchange mechanism for constructing delegation chains with provenance: each derived token carries an act claim identifying the acting agent and a may_act claim limiting who can further delegate. In theory, this creates an auditable chain of custody from user intent to final action.
In practice, the may_act constraint is almost never enforced at the resource server. Resource servers — the APIs and data stores that ultimately act on the token — are built to validate scope and signature. They were not built to validate delegation depth or to reject tokens that have been re-delegated more times than the original issuer permitted. An attacker who compromises a mid-chain agent can splice a new delegation path into the chain, substituting a malicious sub-agent for a legitimate one, without any of the upstream agents detecting the substitution.
The chain splicing attack works because downstream resource servers see a valid, well-formed token with legitimate scope — they have no mechanism to verify that the delegation path described in the token's act claims matches the actual chain of agents that processed the request. Provenance claims are assertions, not attestations.
# Legitimate RFC 8693 delegation token { "sub": "user:alice@org.com", # original user "act": { "sub": "agent:orchestrator-v1", # immediate actor "act": { "sub": "agent:research-sub" # delegated-to agent } }, "scope": "email:read calendar:read", "may_act": { "sub": "agent:research-sub" }, # rarely enforced "exp": 1747655700 } # After chain splice — resource server cannot detect substitution { "sub": "user:alice@org.com", "act": { "sub": "agent:orchestrator-v1", "act": { "sub": "agent:malicious-sub" # substituted — looks valid } }, "scope": "email:read calendar:read" }
Cascade Revocation and Why It Fails
The theoretical remedy for delegation chain compromise is cascade revocation: when the orchestrator token is revoked, all tokens derived from it are automatically invalidated. This is the correct design. In the real world, it almost never works as intended.
Cascade revocation requires that every resource server in the chain knows about the revocation in real time. Most resource servers use local token introspection or cached validation — they check that a token was valid when it was issued, not whether it has been revoked since. The RFC 7009 token revocation endpoint exists, but calling it does not guarantee immediate propagation across a distributed system. A revoked orchestrator token may continue to authorize actions at downstream services for minutes or hours, depending on token cache TTLs.
The cross-domain case is worse. In multi-organization agent pipelines — an enterprise orchestrator calling a third-party specialized agent which calls an external data API — there is no shared revocation protocol. The orchestrator's identity provider cannot reach the external API's introspection endpoint. The token lives for its full stated lifetime regardless of what happens upstream. There is currently no deployed standard for cross-domain cascade revocation in agentic systems.
In a reported 2025 incident at a financial services firm, an attacker compromised a third-party summarization sub-agent in a document processing pipeline. The sub-agent held a derived token from the orchestrator, scoped to document read. By injecting a prompt into a processed document, the attacker caused the sub-agent to request an additional token exchange, escalating to document write access. The orchestrator's token included a broad may_act claim covering all registered agents — it was never scoped to the specific sub-agent. The write-access token was valid, properly signed, and expired only after the attacker had exfiltrated and modified 340 documents across six client accounts.
The HDP Protocol: Binding Delegation to Human Provenance
Recent research from the IETF agent authorization working group has proposed the Human Delegation Provenance (HDP) protocol extension as an approach to making delegation chains verifiable beyond the act claim assertion model. Rather than recording which agent claimed to delegate to which, HDP binds each delegation event to a cryptographic proof that the delegation was sanctioned by the root human principal — either directly (explicit approval) or transitively (the human pre-authorized this class of delegation at system setup).
The key mechanism is a delegation receipt: a signed artifact created at each delegation event that records the delegating agent's identity, the delegated scope, the task context, and a timestamp. Delegation receipts form a Merkle chain that can be audited independently of the token itself. A resource server with HDP support can verify not just that the token is valid but that every delegation in the chain is cryptographically traceable to a human authorization event.
HDP is not yet standardized and faces real deployment challenges: it adds latency to every delegation event, requires all resource servers to be HDP-aware, and creates a receipt storage problem for long-running pipelines. But it addresses the fundamental gap in current delegation models: that provenance claims in tokens are self-asserted, with no way to distinguish a legitimate chain from one that has been partially fabricated or spliced.
Scope Narrowing as a Mandatory Invariant
The minimum viable fix for delegation chain security is enforcing scope narrowing as a non-negotiable invariant: every delegation step must produce a token with scope that is a strict subset of the delegating token's scope. No agent can delegate permissions it does not hold. No derived token can have broader scope than its parent.
This sounds obvious. It is not the current behavior of any major multi-agent framework. CrewAI, AutoGen, and MetaGPT all operate on credential-passing models where the framework itself does not intercept or validate scope at delegation boundaries. Scope narrowing has to be implemented explicitly by the application developer — who typically does not think about it at all when building their multi-agent pipeline.
# Correct delegation — scope narrows at each hop # Orchestrator token: broad orchestrator_token.scope = "email:read email:write calendar:read calendar:write docs:read docs:write" # Research sub-agent delegation — only what it needs research_token = token_exchange( parent=orchestrator_token, scope="email:read docs:read", # strict subset may_act="agent:research-sub-v2" # specific grantee only ) # Summary sub-agent delegation — narrower still summary_token = token_exchange( parent=research_token, scope="docs:read", # narrowed from parent may_act="agent:summary-sub-v1" )
Enforce scope narrowing at every delegation boundary — derived tokens must be strict scope subsets. Populate may_act with the specific downstream agent identity, never a wildcard. Set a maximum delegation depth (recommended: 3 hops) and reject token exchanges that would exceed it. Use short-lived derived tokens even within the chain — 5–10 minute lifetimes for leaf-level agents. Implement delegation receipt logging at the orchestrator layer so every chain event is auditable. Test revocation propagation by actually revoking orchestrator tokens in staging and measuring how long derived tokens remain valid at leaf services. For cross-domain pipelines, treat external agents as untrusted: re-derive minimal-scope tokens at domain boundaries rather than passing your organization's tokens across.
The Accountability Gap at Scale
The delegation chain problem is not merely a technical one — it is an accountability one. When a multi-agent pipeline takes an action that causes harm, the question of who authorized that action must have a traceable, defensible answer. "The orchestrator delegated to the sub-agent" is not an answer. "The user authorized the orchestrator to perform task X, the orchestrator issued a narrowly-scoped token to the sub-agent specifically for operation Y, and that token was the only credential used in the access event" is an answer.
Building that traceable accountability chain requires treating delegation as a security-critical operation at every hop, not just at the initial user authorization. The frameworks that treat credential passing as an implementation detail will be the source of the incidents that force this to become a compliance requirement. The organizations that build delegation chain auditing now will have the audit trails that Article 14 and similar regulations are beginning to demand.