An on-behalf-of token is a delegation mechanism that lets one identity call downstream services with authority derived from another identity. It is useful for tracing provenance, but it is not enough on its own because audit records still need the full human, agent, and tool chain.
Expanded Definition
An on-behalf-of token is a delegation artifact used when one NHI, service, or agent must act with authority derived from another identity. In practice, it sits between direct authentication and downstream access, helping systems preserve a traceable chain of delegated action rather than using a shared credential.
In NHI and IAM programs, the term is often discussed alongside OAuth delegation, token exchange, and service-to-service authorization, but usage in the industry is still evolving. No single standard governs this yet across every platform, so the exact claims, lifetimes, and audit fields vary. The key distinction is that an on-behalf-of token represents delegated authority, not original identity, which means it should be treated as a narrow execution grant with explicit scoping and short validity. That distinction matters because provenance can be preserved without granting broad standing privilege.
For a standards-oriented view of governance outcomes, practitioners often map this pattern to NIST Cybersecurity Framework 2.0 outcomes for access control and logging. The most common misapplication is treating the token as proof of full end-user intent, which occurs when downstream systems fail to retain the original caller, intermediary agent, and tool context.
Examples and Use Cases
Implementing on-behalf-of flows rigorously often introduces more token plumbing and audit overhead, requiring organisations to weigh traceability and least privilege against integration complexity.
- An agent opens a ticket, then exchanges its own access for an on-behalf-of token to read a customer record in a downstream CRM, preserving the originating operator context.
- A workflow service uses delegated authority to retrieve secrets from a vault only for the duration of one transaction, instead of reusing a shared API key.
- A support tool calls a billing API on behalf of a human analyst, with the original identity and tool chain retained in logs to support review and incident reconstruction.
- In a breach analysis, investigators compare delegated token issuance to patterns seen in the Salesloft OAuth token breach and the JetBrains GitHub plugin token exposure to understand how authority was propagated.
- Platform teams compare delegation semantics with guidance from OAuth and identity standards, then validate behavior against RFC 8693 Token Exchange when the implementation supports it.
NHIMG research shows how quickly exposed credentials become operational risk: in Guide to the Secret Sprawl Challenge, 64% of valid secrets leaked in 2022 were still valid and exploitable today. That is why delegated tokens must be narrowly scoped, rapidly expired, and revocable when their parent identity changes.
Why It Matters in NHI Security
On-behalf-of tokens are valuable because they let organisations preserve delegation without collapsing every action into a single shared identity. But when they are poorly governed, they create false confidence: teams may see a legitimate token and assume the action was safe, even when the real problem is an overprivileged agent, an untracked tool hop, or a stale credential chain. That is a direct NHI governance issue, not just an application design detail.
This becomes more serious when delegated tokens are duplicated, stored outside approved vaults, or left active after role changes. NHIMG research in the State of Secrets Sprawl 2026 and the 2025 State of NHIs and Secrets in Cybersecurity shows how often token handling fails in real environments, including widespread token exposure and long-lived validity after lifecycle events. The practical control objective is to keep delegation observable, bounded, and independently revocable, while retaining the original identity path for investigation and policy enforcement.
Organisations typically encounter the danger only after a delegated action is abused, at which point on-behalf-of token review 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-02 | Delegated tokens are secret-like artifacts that must be scoped, stored, and rotated safely. |
| NIST CSF 2.0 | PR.AA-01 | Access is based on verified identity and authorization context, including delegation chains. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous verification of each access step, not trust in the token alone. |
Preserve original caller context and enforce least-privilege authorization for each delegated request.
