Notifications
Clear all
Topic starter
22/06/2026 4:59 pm
TL;DR: Multi-hop agent delegation requires preserving original-caller attribution, contracting scope at each hop, and enforcing chain depth limits, according to Scramble ID’s analysis of RFC 8693 token exchange. The architectural break is that legacy bearer-token assumptions collapse once agents delegate to other agents without losing policy context.
NHIMG editorial — based on content published by Scramble ID: Multi-Hop Agent Delegation Chains
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
What's in the full article
Scramble ID's full research covers the operational detail this post intentionally leaves at the architecture level:
- The exact RFC 8693 token exchange flow with subject_token, audience, and nested act claims.
- Concrete token payload examples for human-to-agent, agent-to-agent, and tool-to-resource hand-offs.
- Policy checks for scope_subset enforcement, chain-depth limits, and cross-tenant trust boundaries.
- Sender-constrained token patterns using mTLS and DPoP for delegated runtime protection.
👉 Read Scramble ID's analysis of multi-hop agent delegation chains →
Multi-hop delegation chains: what IAM teams need to fix next?
Explore further
22/06/2026 5:12 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Multi-hop agent delegation chains expose the next identity gap
