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

Why This Matters for Security Teams

Multi-hop delegation chains turn a single agent action into a sequence of trust transfers. That matters because every hop can widen scope, obscure accountability, and create a chance for privilege creep if the chain is treated like ordinary API traffic. Static RBAC is usually too blunt for this problem, because it cannot express who delegated what, for how long, and under which runtime conditions. Current guidance increasingly treats delegation as a policy problem, not just an authentication problem, as reflected in the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework.

NHIMG research shows how quickly credential exposure becomes operational risk: in the LLMjacking report, attackers attempted access to exposed AWS credentials within an average of 17 minutes. That pace is a reminder that delegation chains need short-lived, context-bound controls, not broad, reusable tokens. In practice, many security teams only discover chain-wide overreach after an agent has already chained tools and propagated access beyond the original intent.

How It Works in Practice

The safest model is to treat each hop as a separate, explicit authorisation event. The delegator should issue a narrowly scoped assertion that says what the downstream agent may do, for which resource class, and for how long. The receiving agent should not inherit open-ended rights; instead, it should exchange the delegated token for a new runtime-bound token at the next trust boundary. That exchange should preserve provenance, so the original delegator, scope, and expiry remain visible to policy enforcement and audit.

This is where workload identity matters. For autonomous systems, the identity primitive is the workload, not the human operator behind it. Standards such as SPIFFE and SPIRE are useful because they let teams bind identity to the runtime that is actually executing the hop, rather than to a generic service account. At the policy layer, teams should evaluate each hop with context-aware rules at request time, using policy-as-code where possible. The question is not simply “is this agent authenticated?” It is “is this specific delegated action still allowed in this runtime, for this resource, with this origin chain?”

A practical control pattern looks like this:

• Issue just-in-time, short-lived credentials per hop instead of sharing long-lived secrets.
• Bind tokens to the calling runtime and constrain audience, scope, and TTL.
• Record delegation provenance so each downstream call can be traced to the original authority.
• Revalidate at the resource boundary, especially before write, delete, transfer, or escalation actions.
• Revoke on completion or when the chain deviates from the declared task.

NHIMG’s OWASP NHI Top 10 and the Analysis of Claude Code Security both reinforce the operational point: agentic systems chain tools in ways humans do not always predict, so each hop must be individually constrained and observable. These controls tend to break down in highly distributed environments where multiple brokers, queues, and async workers strip away token provenance before the final resource call.

Common Variations and Edge Cases

Tighter delegation controls often increase latency and integration overhead, so organisations must balance stronger containment against developer friction and runtime complexity. That tradeoff is unavoidable when chains span multiple services, vendors, or asynchronous task runners. Best practice is evolving, but there is no universal standard for how much delegation metadata every system must preserve yet.

One common edge case is fan-out, where a single upstream agent delegates to several downstream workers. In that pattern, the original scope should not be copied wholesale into every branch. Each branch needs its own constrained token and its own revocation path. Another edge case is cross-domain delegation, where policy domains do not share the same identity plane. In those environments, teams should prefer explicit token exchange over implicit trust propagation and enforce the narrowest possible audience claim.

For regulated workflows, the audit requirement is often more stringent than the runtime requirement. The chain must be reconstructable after the fact, not just permitted in the moment. That is why guidance from the CSA MAESTRO agentic AI threat modeling framework is relevant: threat modelling should include delegation abuse, not only prompt injection or data leakage. In practice, multi-hop governance becomes hardest when ephemeral jobs, shared service identities, and legacy gateways all coexist in one path, because provenance is lost before policy can re-evaluate the final hop.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?
• How should security teams govern non-human identities in Salesforce?
• How should security teams govern non-human identities that have persistent access?