Multi-hop agent delegation chains expose the next identity gap

At a glance

What this is: This is a standards-based analysis of multi-hop agent delegation chains and the identity controls needed to preserve attribution, scope contraction, and auditability across agent, tool, and resource hops.

Why it matters: It matters because IAM, NHI, and emerging agentic AI programmes all need a delegation model that does not lose caller identity or overextend privilege as work crosses multiple runtime hops.

By the numbers:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
• Only 5.7% of organisations have full visibility into their service accounts.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.

👉 Read Scramble ID's analysis of multi-hop agent delegation chains

Context

Multi-hop agent delegation is the problem of keeping identity and authorisation intact as work passes from a human to one agent, from that agent to another, then into tools and downstream resources. The core issue is not whether a single agent can authenticate, but whether the original caller, the allowed scope, and the policy context survive every hop without widening.

For IAM and NHI teams, this is where bearer-token thinking becomes fragile. A resource that only sees the last caller cannot safely reason about who originally authorised the action, how deep the delegation chain went, or whether the chain stayed inside policy as it crossed tools, services, and tenant boundaries. Standards-based token exchange is the cleaner path because it keeps the chain legible rather than inventing a parallel control plane.

Key questions

Q: How should security teams govern multi-hop agent delegation chains?

A: Security teams should govern multi-hop delegation as a chain of explicit authorisations, not as a series of disconnected API calls. Every hop should preserve the original delegator, contract scope, and bind the token to the runtime that uses it. The strongest control is policy at token exchange, then revalidation at the resource boundary.

Q: Why do multi-hop delegation chains increase identity risk?

A: They increase risk because each hop creates a new place where scope can widen, attribution can disappear, or trust boundaries can blur. If the resource sees only the last caller, the organisation loses the ability to prove who authorised the action and whether the chain stayed within policy.

Q: What breaks when original-caller attribution is not preserved?

A: When attribution is not preserved, downstream resources cannot distinguish legitimate delegation from a hijacked or overextended chain. That breaks auditability, weakens policy decisions, and makes incident response far harder because investigators cannot reconstruct who originally authorised the action.

Q: How do organisations control scope explosion in delegated agent workflows?

A: They control scope explosion by enforcing subset-only scope at each hop, bounding chain depth, and rejecting any exchange that crosses an unapproved trust boundary. If a later actor needs more access than the original authoriser granted, the workflow should stop and reauthorise rather than expand silently.

Technical breakdown

Why bearer tokens break down in multi-hop delegation

Traditional OAuth bearer tokens assume a mostly direct relationship between the authorising subject and the resource consuming the token. Multi-hop delegation changes that model because each agent, tool, and backend service can become both a consumer and a delegator. If the same token is reused everywhere, scope stays too broad and attribution becomes ambiguous. If each hop mints a fresh identity without preserving the chain, the original delegator disappears from the audit trail. RFC 8693 token exchange addresses this by separating subject, actor, audience, and scope so the chain remains cryptographically visible.

Practical implication: Use delegation-aware token exchange instead of bearer-token reuse for any chain that crosses more than one runtime hop.

How original-caller attribution survives nested act claims

The key mechanism is chain-preserving token exchange. The subject token identifies the original delegator, while nested act claims identify the agents or services that performed each intermediate step. That structure lets a resource see both who authorised the request and which actors handled it on the way down the chain. Without this, policy engines can only make decisions on the immediate caller and lose the context needed for customer-only access, tenant scoping, or delegated task boundaries. In practice, attribution is not a logging feature. It is part of the authorisation record.

Practical implication: Require nested actor claims at each hop so downstream resources can enforce policy on the full delegation history.

Where scope contraction and chain depth controls matter most

Multi-hop systems fail when delegation becomes additive instead of restrictive. Each hop should receive a subset of the previous hop's scope, not a broader replacement, and policy should cap how deep the chain can grow before it becomes operationally unsafe. This is how the architecture resists scope explosion and chain-depth abuse. Sender-constrained tokens, audience binding, and explicit cross-tenant trust boundaries add further guardrails, but the main control is simple: no hop should be able to enlarge what the original delegator authorised.

Practical implication: Enforce subset scope rules and hard chain-depth limits at token issuance, then recheck both at the resource boundary.

Threat narrative

Attacker objective: The attacker wants to turn legitimate delegation into broader, less attributable access that crosses policy boundaries without being clearly tied back to the original authoriser.

1. Entry occurs when a human delegates work to Agent A, which then passes part of the task to Agent B, creating a multi-hop chain that must be authorised hop by hop.
2. Escalation occurs if an intermediate actor requests broader scope than it received, reuses an unstated bearer token, or hides the original caller through weak token semantics.
3. Impact occurs when the downstream resource cannot determine original authorisation, allowing scope explosion, attribution loss, cross-tenant escape, or chained misuse of legitimate access.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Multi-hop delegation is an NHI governance problem, not just an AI architecture problem. The hardest issue is preserving identity semantics as authority moves across agents, tools, and services. That is the same governance challenge identity teams already face with service accounts and third-party access, but now the chain is dynamic and runtime-driven. The practitioner conclusion is that delegation must be governed as a chain, not as isolated credentials.

Original-caller attribution is the control that keeps delegated access auditable. If the resource cannot see who originally authorised the action, it cannot distinguish approved delegation from hijacked delegation. Nested act claims and preserved subject tokens make attribution part of the policy record rather than a forensic afterthought. The practitioner conclusion is that auditability must survive every hop, not only the first issuance.

Scope explosion is the named failure mode this pattern exposes. Multi-hop systems were not designed for additive privilege growth, so each extra exchange creates pressure to widen access unless policy forces contraction. That is why subset enforcement at each hop is not optional. The practitioner conclusion is to treat any delegation design that cannot prove scope contraction as structurally unsafe.

Cross-tenant escape becomes a trust-boundary failure when delegation crosses organisations. A token chain that moves between tenants without explicit audience binding and tenant-scoped policy turns federation into accidental overreach. This is where zero trust and NHI governance meet, because trust must be explicit at every boundary. The practitioner conclusion is to define cross-tenant delegation as an exception, not a default.

Standards-based delegation is the only sustainable direction for agent identity. Architectures built on RFC 8693 can absorb emerging agentic token patterns without a rebuild, while proprietary delegation primitives create long-term fragmentation. The field is moving toward chain-aware identity, and teams that ignore that direction will have to replace their control plane later. The practitioner conclusion is to align now with standards that preserve caller identity across hops.

From our research:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
• Only 91.6% of secrets remain valid five days after the targeted organisation is notified, which shows how slowly remediation can lag behind exposure.
• For the broader NHI context behind this delegation problem, see 52 NHI Breaches Analysis for recurring compromise patterns across machine identities.

What this signals

Delegation chains will force IAM teams to treat authorisation history as first-class data. Once agents routinely hand off work to other agents and tools, the programme needs an explicit record of subject, actor, audience, and scope at every hop. That is why chain-aware controls will matter as much as token issuance itself, especially where OAuth 2.0 Token Exchange becomes the interoperability layer.

Original-caller provenance is the named concept teams should start using internally. It describes the ability to prove who first authorised a delegated action even after multiple runtime hops. Without that provenance, incident response becomes reconstruction by guesswork, and privileged access decisions become harder to defend across both the Ultimate Guide to NHIs and emerging agentic workflows.

With 92% of organisations exposing NHIs to third parties, the delegation problem is not confined to internal agents. It now spans supplier access, federated trust, and cross-tenant paths, so programme owners should expect more pressure to prove that every trust boundary is deliberate rather than incidental.

For practitioners

• Map delegation chains end to end Document every hop from human delegate to agent, tool, and resource, including which identity is present at each step and where attribution is lost. Use that map to find any place where the resource sees only the immediate caller instead of the original delegator.
• Enforce scope contraction at each exchange Require every token exchange to request a subset of the previous hop's scope and reject any request that widens access. Make this a policy check at issuance and a runtime check at the resource boundary, especially for cross-tenant or customer-data paths.
• Bind tokens to the runtime that uses them Use sender-constrained tokens such as mTLS or DPoP so a stolen intermediate token cannot be replayed outside the intended agent runtime. Pair that with short TTLs and immediate revocation paths for delegated credentials.
• Set hard limits on chain depth Define a maximum delegation depth for sensitive resources and reject any chain that exceeds it. Deep chains should be treated as a policy exception because they make policy reasoning and incident reconstruction harder.
• Preserve signed audit trails for every hop Store the full token-exchange history, including subject, actor, audience, and scope, so investigators can reconstruct the chain after an incident. Make the audit trail tamper-evident and searchable by original delegator.

Key takeaways

• Multi-hop delegation changes identity from a single-token problem into a chain-of-authorisation problem.
• Scope contraction, attribution preservation, and chain-depth limits are the controls that stop delegated access from becoming silent privilege expansion.
• Teams that build on standards such as RFC 8693 will be better positioned than those that invent private delegation primitives.

Key terms

• Delegation Chain: A delegation chain is the full sequence of identities and services that pass authorisation from one actor to another before a resource is reached. In multi-hop systems, the chain must preserve who originally authorised the action, which actors handled it, and how scope changed at each step.
• Original-caller Attribution: Original-caller attribution is the ability to prove which subject first authorised a delegated action, even after the request has passed through multiple agents or services. It is essential for auditability, policy enforcement, and incident reconstruction when runtime behaviour is distributed across a chain.
• Scope Contraction: Scope contraction is the requirement that each delegated hop receives less or equal authority than the previous hop, never more. In agent and NHI workflows, this prevents privilege growth as work moves through tools, services, and nested actors.
• Nested Act Claim: A nested act claim records each intermediate actor in a delegated identity chain, showing who acted on behalf of whom. It turns delegation history into signed token data that downstream services can inspect when deciding whether a request is allowed.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Scramble ID: Multi-Hop Agent Delegation Chains. Read the original.