Multi-hop agent delegation chains expose the next identity gap

At a glance

What this is: This is an analysis of multi-hop agent delegation and the identity controls needed to preserve attribution and scope across chained agent, tool, and resource calls.

Why it matters: It matters because IAM and identity architects now have to govern delegation chains, not just individual principals, or they will lose policy context as AI agents and tools hand work off to one another.

Context

Multi-hop agent delegation is the problem of preserving identity and authorisation when one agent hands work to another agent, which then calls tools and resources downstream. In that model, the important control point is not only authentication at the first hop but the policy that survives each hop.

Traditional OAuth patterns were designed around a single delegation event, usually a human authorising one application. Once the chain becomes human to agent to agent to tool to resource, identity governance has to answer who authorised the action, how much scope remains valid, and whether the chain is still within policy at the last hop.

Key questions

Q: What breaks when agent delegation chains do not preserve the original caller?

A: The resource loses the ability to evaluate the request against the true authoriser, not just the last agent in the path. That breaks accountability, complicates incident reconstruction, and makes policy enforcement depend on incomplete context. In practice, provenance has to survive every hop or the chain is no longer governable.

Q: When does multi-hop delegation become a governance risk rather than a convenience?

A: It becomes a governance risk when each hop can widen scope, hide attribution, or cross trust boundaries without explicit policy. At that point the delegation path is no longer a controlled hand-off, it is an authority multiplier. Teams should treat depth, scope, and audience as bounded decisions, not implementation details.

Q: How do security teams know if agent authorization is actually working?

A: Authorization is working only if the agent can complete the intended task without gaining unnecessary reach. Good signals include short-lived credentials, task-scoped permissions, approval for sensitive changes, and clear logs linking each action to a user and an agent. If credentials are reused, privileges persist, or the agent can move between systems without reauthorization, the control is failing.

Q: What should IAM teams do when an agent chain crosses organisational boundaries?

A: They should require explicit federated trust, audience binding, and tenant-scoped policy before any external hop is accepted. Cross-organisation delegation is not a routine extension of internal access; it is a separate trust relationship that needs separate validation. Without that, a legitimate chain can become a cross-tenant escape path.

Technical breakdown

Why single-hop OAuth assumptions fail in agent chains

OAuth bearer-token patterns assume one principal, one delegated session, and one downstream resource decision. In a multi-hop agent chain, those assumptions collapse because each actor may need a different audience, a narrower scope, and preserved provenance from the original delegator. RFC 8693 token exchange is the relevant standard because it allows the subject token to carry the original identity while nested act claims record who acted at each hop. That is what makes the delegation chain tamper-evident rather than merely repeated. Practical implication: design for chain-aware token exchange, not token reuse.

Practical implication: use token exchange patterns that preserve provenance instead of reusing the original bearer token across every hop.

How scope contraction and chain depth control prevent delegation drift

Delegation drift happens when each hop adds or retains more authority than the prior hop intended. The article’s core control is scope contraction, which means every exchanged token must request a subset of the prior token’s authority and stay within a bounded chain depth. Without that, a chain can accidentally or maliciously accumulate broader access than the original delegator approved. Depth limits also matter because deeply nested chains complicate policy evaluation and forensic reconstruction. Practical implication: enforce subset-of-scope checks and maximum hop counts at issuance time, not after the fact.

Practical implication: enforce subset-of-scope checks and maximum hop limits at token issuance.

Why attribution is a policy control, not just an audit detail

In chained delegation, attribution is not a logging nicety. It is a control surface that determines whether the resource can evaluate the request against the correct original subject, the immediate actor, and the full sequence of intermediaries. If the chain overwrites that context, the resource can no longer distinguish legitimate delegated work from policy abuse hidden behind intermediate actors. That is why nested act claims and end-to-end chain preservation are central to the architecture. Practical implication: require every resource to receive and evaluate the full delegation history.

Practical implication: make full delegation history available to every protected resource that makes an authorisation decision.

Threat narrative

Attacker objective: The attacker’s objective is to turn a legitimate delegation chain into broader access than the original authorisation allowed while obscuring who really approved the action.

1. Entry occurs when a human or upstream agent authorises the first hop and the chain begins with a valid delegated token.
2. Escalation occurs if an intermediate agent expands scope, rewrites delegation context, or exceeds allowed chain depth during token exchange.
3. Impact occurs when the downstream resource cannot reconstruct the original delegator or enforce the intended scope contract, creating policy bypass and attribution loss.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Delegation chains are now the identity boundary, not the individual agent. The old mental model stops at authenticating a single workload or assistant, but production agent systems increasingly hand off authority across several actors before any resource is touched. That shifts governance from isolated principal checks to chain-aware policy evaluation. Practitioners should treat the chain itself as the governed unit.

Original-caller attribution is the control that keeps delegated AI explainable. If the resource only sees the latest agent, the programme has already lost the ability to prove who initiated the work and under what policy. Scramble ID’s RFC 8693 framing shows why nested act claims matter: they preserve the provenance needed for access review, incident reconstruction, and accountability across agent hand-offs. Teams should assume attribution loss is a governance failure, not a logging gap.

Scope explosion is the named failure mode that makes multi-hop delegation dangerous. Each hop was designed for a narrower delegated purpose, but that assumption breaks when one actor can widen or preserve authority beyond the prior hop’s intent. This is not a minor implementation flaw; it is the point where delegated access stops being bounded by the original decision. Identity teams should redesign review and policy models around scope contraction at every exchange.

Chain depth limits are a practical expression of identity blast-radius control. Deep delegation paths are not just harder to audit, they also create room for policy confusion, trust boundary drift, and cross-tenant escape. Limiting hop count is therefore a governance decision about how far authorisation may propagate before control is considered lost. The practitioner takeaway is that delegation depth must be policy-defined, not left to application convenience.

Standards-based delegation is becoming the only durable path for agent identity. Proprietary delegation primitives may work for a single platform, but they create rebuild risk as Agentic JWT, A2A token semantics, and identity chaining mature. The market is moving toward interoperable identity propagation, and teams that anchor on standards will preserve optionality across vendors, resources, and future agent frameworks. Practitioners should build for exchangeability, not one-off integration.

What this signals

Original-caller attribution is the missing governance primitive for chained agents. Once agents can hand work off to other agents, the programme needs a durable way to know who initiated the request and which actor changed the scope along the way. That makes delegation history a first-class identity object, not an incidental log line.

Identity blast radius now depends on how far a delegation chain can extend. If hop count is unlimited or scope can widen at exchange, a single trusted request can fan out into authority far beyond the original intent. Teams should align policy with the longest chain they will allow, not the shortest chain they hope to see.

Standards-based propagation is the safest planning assumption for agent identity programmes. Architectures that align to token exchange and chain-aware claims are easier to govern as ecosystems mature, while proprietary delegation schemes are more likely to create migration work later. The practical test is whether the design can survive new agent-to-agent patterns without replatforming.

For practitioners

• Define chain-aware token exchange policy Require every delegation hop to preserve the original subject, record the immediate actor, and validate requested scope against the prior token before issuing a new token.
• Set maximum delegation depth Establish a hard policy limit for how many agent, tool, or service hops a request may traverse before the chain is rejected or re-authorised.
• Enforce scope contraction at every hop Block any exchange request that asks for broader authority than the current token already carries, including indirect expansion through nested delegation.
• Preserve end-to-end delegation audit trails Capture the full signed chain at each resource boundary so responders can reconstruct who authorised the action, which actors intervened, and where policy changed.
• Make cross-tenant trust explicit Treat federation between agent domains as a deliberate trust relationship with tenant-scoped validation, audience checks, and separate policy for external actors.

Key takeaways

• Multi-hop delegation changes the identity problem from authenticating one agent to governing a chain of actors, scopes, and trust decisions.
• The central failure mode is loss of original-caller attribution and scope contraction across hops, which can turn legitimate delegation into unbounded authority.
• Practitioners should govern delegation depth, preserve provenance, and require standards-based token exchange so agent identity remains auditable as the ecosystem expands.

Key terms

• Chain-Aware Delegation: A delegation model that preserves the full identity path across multiple agent or service hops. Each hop carries provenance so downstream systems can judge what the original actor could legitimately delegate and where authority should stop.
• 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.
• Chain Depth Limit: A governance control that caps how many delegation hops a request may traverse before it must be denied or re-authorised. For autonomous and NHI workloads, depth limits reduce policy ambiguity, simplify audit reconstruction, and shrink the blast radius of misdelegation or compromise.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.