A delegated token flow is an authentication pattern where the token represents the human user and the application can enforce that user’s ceiling. In agent systems, this only works when the user’s identity remains visible to the resource server and the delegation chain is preserved end to end.
Expanded Definition
Delegated token flow is the pattern used when an application receives a token that still reflects the human user, rather than substituting the app’s own identity. That distinction matters in NHI systems because the resource server can apply user-specific ceilings, audit the real actor, and reject actions the user never authorised. In modern agentic systems, the term is often discussed alongside OAuth-based delegation, but no single standard governs this yet across every workflow, tool chain, and brokered agent design. The practical requirement is simple: the delegation chain must remain visible end to end, including any intermediary agent, gateway, or workflow service. Guidance from the NIST Cybersecurity Framework 2.0 reinforces that identity context must be preserved for access control, logging, and accountability. The most common misapplication is treating a delegated token as if it were a service token, which occurs when an intermediary strips user context and the resource server can no longer enforce the human’s ceiling.
Examples and Use Cases
Implementing delegated token flow rigorously often introduces protocol and governance overhead, requiring organisations to weigh traceable user authority against simpler service-to-service automation.
- An AI assistant calls a ticketing API on behalf of a helpdesk analyst, but the API only allows actions that the analyst’s role permits.
- A workflow service triggers a cloud action using a user-scoped token so that approval, attribution, and rollback all point back to the initiating employee.
- A customer support agent uses a delegated token to access a CRM record, while the system logs the named user rather than a shared application account.
- A brokered agent chain forwards the original user identity across multiple tools, preventing the final resource from seeing only the intermediary agent.
These patterns are closely related to the attack paths behind the Salesloft OAuth token breach, where token handling determined how far access could travel. For standards context, OAuth-style delegation is commonly anchored to RFC 6749, though agent implementations vary widely and often add custom token exchange layers.
Why It Matters in NHI Security
Delegated token flow is a control boundary, not just an integration detail. When it is implemented correctly, it helps prevent over-broad access, shared-account abuse, and silent privilege inflation in agent workflows. When it is implemented poorly, the token can become a hidden bearer of excess authority that outlives the user’s intent. NHIMG research shows that 44% of NHI tokens are exposed in the wild, often through collaboration platforms, tickets, and code commits, which means delegation failures frequently become exposure failures as well. The issue is amplified when teams confuse delegated access with standing service privilege, especially in systems that also suffer from the secret sprawl challenge. If a delegated chain breaks, auditors may see only the final call, not the human who approved it, which weakens investigations and compliance evidence. Organisations typically encounter the cost of this weakness only after a sensitive action is traced to an agent call they cannot attribute, at which point delegated token flow 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 address the attack and risk surface, while NIST CSF 2.0 and 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-05 | Covers token delegation, identity propagation, and over-privileged NHI access paths. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions should be enforced based on the originating user context and least privilege. |
| NIST Zero Trust (SP 800-207) | Policy Decision Point | Zero trust requires continuous policy decisions using identity and context on every access request. |
Preserve end-to-end user context and verify each delegated hop before granting resource access.
