A delegation pattern where one agent spawns another agent, which may then delegate again before acting on a resource. In practice, authority becomes distributed across several runtime decisions, so the security model must preserve scope, lineage, and accountability at every hop.
Expanded Definition
Multi-hop delegation is a runtime pattern in which an NIST Cybersecurity Framework 2.0 aligned control chain passes authority from one agent to another, then potentially onward again, before any action touches a resource. In NHI and agentic AI systems, that chain may include workload identities, service accounts, ephemeral tokens, and tool-specific permissions. The security challenge is not just proving that an agent was allowed to act, but preserving the full delegation lineage so every hop can be evaluated for scope, time, purpose, and revocation.
Definitions vary across vendors because some describe only token forwarding, while others include delegated tool calls, impersonation, and chained consent. For governance purposes, the useful boundary is whether each hop creates a new authority decision that must be independently constrained and logged. That makes multi-hop delegation closely related to least privilege, JIT access, ZSP, and auditability, but it is not the same as simple role inheritance. The most common misapplication is treating every downstream agent as if it inherited the original trust intact, which occurs when scope narrowing and hop-by-hop verification are skipped.
Examples and Use Cases
Implementing multi-hop delegation rigorously often introduces latency and policy complexity, requiring organisations to weigh operational flexibility against tighter lineage checks and shorter-lived authority.
- An orchestration agent receives a limited ticket, spawns a planning agent, and that second agent calls a database tool only after a fresh authorization step.
- A support agent delegates a remediation task to a specialist agent, but the specialist is restricted to one system and one time window to avoid authority creep.
- A CI/CD agent requests a secrets rotation workflow, then a vault agent performs the change while preserving an auditable chain back to the original pipeline event.
- A customer-facing assistant routes a billing exception to a back-office agent, but the downstream agent cannot expand scope beyond the original case context.
- In a federated workflow, one service account delegates to another runtime identity, and the system records each hop to support incident review and rollback.
For broader NHI context, the Ultimate Guide to NHIs is useful because multi-hop delegation sits inside the same lifecycle problems that govern visibility, rotation, and offboarding. It also aligns with agentic security guidance from the NIST Cybersecurity Framework 2.0, especially where identity events must be traceable across systems rather than treated as isolated requests.
Why It Matters in NHI Security
Multi-hop delegation becomes dangerous when teams can no longer answer basic questions: who originated the action, which hop widened scope, and which identity should be revoked if something goes wrong. Without lineage, a compromised upstream agent can fan out access through downstream agents, making incident containment far harder than with a single actor. That is why NHI governance needs hop-aware controls for token scope, step-up checks, and tamper-evident logging. The Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, which makes delegated chains especially risky when permissions are not continuously narrowed. In practice, multi-hop delegation should be evaluated alongside secrets handling and zero trust controls, not as an isolated workflow feature. It also belongs in the same governance conversation as NIST Cybersecurity Framework 2.0 implementation because access decisions, verification, and recovery all depend on clear identity boundaries. Organisations typically encounter this consequence only after a downstream agent misuses inherited authority or an incident review cannot reconstruct the delegation trail, at which point multi-hop delegation becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Delegated chains amplify secret and privilege exposure across NHI hops. |
| OWASP Agentic AI Top 10 | AGENT-03 | Agent handoffs and tool calls require hop-by-hop authorization and tracing. |
| NIST Zero Trust (SP 800-207) | PA-10 | Zero trust requires continuous verification across every delegated action. |
Constrain each hop with least privilege, short-lived credentials, and explicit audit logs.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
