Token delegation is an authentication pattern where an agent receives credentials that preserve both the human requester and the acting software identity. It allows the system to authorize actions on behalf of a user while still distinguishing who requested the work and which agent performed it for audit and policy enforcement.
Expanded Definition
Token delegation is a delegated authorization pattern used when an agent acts with limited authority while preserving traceability to the human requester and the acting software identity. In NHI security, that distinction matters because the token is not just proof of access, it is also an audit signal that ties a specific action to a specific intent and execution path. Definitions vary across vendors on whether token delegation should be implemented as true on-behalf-of delegation, token exchange, or constrained impersonation, so the important test is whether the resulting credential preserves provenance and enforces least privilege across the full request chain.
This pattern sits between direct user authentication and unmanaged service account use. It is especially relevant when an AI agent or workflow needs to call downstream APIs, create tickets, or trigger privileged operations without collapsing every action into a shared robot identity. Standards and implementation guidance are still evolving, so organisations should evaluate the delegation model against policy enforcement, token scope, revocation, and logging requirements rather than treating it as a generic session handoff. The most common misapplication is treating delegation as a reusable blanket credential, which occurs when teams let an agent carry user authority beyond the original task boundary.
Examples and Use Cases
Implementing token delegation rigorously often introduces orchestration and revocation overhead, requiring organisations to weigh stronger accountability against added system complexity.
- An AI support agent opens a CRM record on behalf of a user, but the delegated token preserves the user identity and the agent identity in logs.
- A workflow agent submits a cloud change request with a short-lived delegated token that is scoped only to that ticket and action.
- A developer assistant reads repository metadata through a user-granted delegation path without inheriting broad personal access to production systems.
- A platform team uses delegation for approvals so the approver remains identifiable even when the agent performs the API call.
For background on why token sprawl and exposed credentials become dangerous quickly, see the Guide to the Secret Sprawl Challenge and the NIST Cybersecurity Framework 2.0. Token delegation is often discussed alongside OAuth-style access patterns, which is why incidents such as the Salesloft OAuth token breach are useful reference points for understanding how delegated tokens can widen blast radius when scope and lifetime are not tightly controlled.
Why It Matters in NHI Security
Token delegation becomes a governance issue the moment an organisation allows software to act with user-aligned authority. Without clear separation between requester, agent, and downstream recipient, teams lose the ability to answer basic questions about who approved an action, who executed it, and whether the resulting access was still valid at the time of use. That creates audit gaps, makes incident response slower, and increases the chance that a compromised agent can reuse delegated access outside the intended task. In NHI environments, the risk is amplified because delegated tokens often sit inside automation, where humans do not see the credential being passed around.
NHIMG research shows that 44% of NHI tokens are exposed in the wild, being sent or stored across collaboration tools and code commits, which underscores how quickly delegated credentials can escape their intended boundaries if they are not short-lived and tightly scoped. Token delegation also matters when teams discover that an agent used a valid credential after the original requester has moved on, because revocation timing becomes as important as initial approval. Organisations typically encounter the operational need for token delegation only after an overprivileged agent action, at which point the model becomes 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, OWASP Agentic AI Top 10 and CSA MAESTRO 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-01 | Delegated tokens must preserve provenance, scope, and accountability for non-human identities. |
| OWASP Agentic AI Top 10 | AGENT-03 | Agentic systems need bounded tool authorization and traceable action chains. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions should be managed to enforce least privilege and traceable authorization. |
| NIST Zero Trust (SP 800-207) | Zero trust requires continuous verification of every access request, including delegated ones. | |
| CSA MAESTRO | TA-04 | Agent workflows must preserve policy, identity, and auditability across delegated actions. |
Issue short-lived delegated tokens with explicit actor attribution and revoke them when the task ends.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 1, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org