Transitive delegation is the widening risk that appears when one agent passes work to another and authority is carried forward, intentionally or not. Each hop can expand the effective permission set if scope is not narrowed. In practice, it is a control problem for delegation chains, not just for individual principals.
Expanded Definition
Transitive delegation describes the way authority can keep moving from one agent to another when work is handed off across a chain, especially in automated systems where service accounts, APIs, and AI agents exchange tasks. The risk is not the handoff itself but the absence of a boundary that narrows scope at each hop. In NHI security, this is closely related to delegated access design, token exchange, and trust propagation in workflows that cross systems or tenants.
Definitions vary across vendors because some teams treat transitive delegation as a protocol feature, while others treat it as an architectural anti-pattern. In practice, the distinction matters: a controlled delegation chain can support automation, but only if the receiving principal gets the minimum authority required and no inherited privilege beyond that need. NIST SP 800-53 Rev 5 Security and Privacy Controls is a useful reference for enforcing least privilege, access enforcement, and auditability in these flows.
The most common misapplication is assuming each hop is safe because the original delegator was authorized, which occurs when downstream scope, token audience, or impersonation rights are not explicitly constrained.
Examples and Use Cases
Implementing delegation rigorously often introduces workflow friction, requiring organisations to balance automation speed against tighter authorization checks, shorter token lifetimes, and more detailed logging.
- A build agent triggers a deployment bot, which then calls production APIs. If the bot inherits the build agent’s broad rights, the delegation chain becomes wider than intended and the production boundary weakens.
- An AI agent passes a customer support task to another agent with access to billing systems. Without scope narrowing, the second agent may receive privileges it never needed, creating avoidable exposure.
- A service account obtains a token and forwards work to a microservice tier. If the original token remains valid for downstream use, the chain can outlive the intended task and expand blast radius.
- A third-party workflow receives delegated access through an integration platform. This is especially risky when the enterprise cannot fully inventory its NHI surface, a problem highlighted in the Ultimate Guide to NHIs.
- OAuth-style delegation or token exchange can be appropriate, but only when audience restriction, consent boundaries, and revocation paths are enforced using controls described in NIST SP 800-53 Rev 5 Security and Privacy Controls.
Why It Matters in NHI Security
Transitive delegation becomes a governance issue because every additional hop can hide who actually had the power to act, which complicates accountability, incident response, and privilege review. In NHI environments, this matters for service accounts, workload identities, and agentic systems that can chain actions faster than human reviewers can track.
NHIMG research shows that 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, and 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs. Those conditions make delegation chains especially dangerous because inherited authority is often invisible until an audit or breach reveals it. A Zero Trust approach also depends on constraining trust at each hop, not only at the originating principal.
When transitive delegation is misunderstood, teams may believe revoking the first credential is enough, even though downstream tokens, cached permissions, or chained impersonation remain active. Organisations typically encounter unauthorized lateral movement only after a delegated workflow is abused, at which point transitive 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 CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 | Delegation chains can widen effective privilege beyond intended scope. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions must be managed to prevent inherited over-privilege. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust requires trust decisions at each transition, not just the origin. |
| NIST SP 800-63 | AAL2 | Assurance and binding strength influence whether delegated credentials are acceptable. |
| OWASP Agentic AI Top 10 | AGENT-03 | Agent handoffs can amplify authority if tool access is not bounded. |
Use strong credential binding and limit delegation to appropriately assured contexts.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
