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.
How On-behalf-of Tokens Work
An on-behalf-of token sits in the middle of a delegation chain. One identity obtains it so a downstream service can act with authority derived from a different identity, rather than by reusing the original credential directly. That makes it useful for constrained delegation, but it also means the token only represents one step in a broader trust relationship.
In practice, the important question is not just whether the token is valid, but what it says about the original subject, the actor that requested it, and the service that accepted it. RFC 8693: OAuth 2.0 Token Exchange defines the standards-based exchange pattern behind this kind of delegation, including actor and subject separation.
That distinction matters because on-behalf-of flows are about delegated authority, not blanket impersonation. A system may be able to prove that one component was allowed to obtain a token for another, yet still need separate controls to show who initiated the action and which intermediate service transformed the request.
Why On-behalf-of Tokens Matter for Provenance
On-behalf-of tokens are valuable when services need to preserve a chain of accountability across tiers, APIs, and agents. They help security teams understand that an operation was performed under derived authority, which is especially important when one component brokers access for another. The trace is only as strong as the metadata carried forward, however, so provenance often depends on accompanying claims, logs, and correlation data.
This is why token exchange is often paired with explicit actor context. OAuth Token Exchange and Delegation Guide is the natural place to understand the relationship between subject tokens, actor tokens, act claims, and downscoping in delegated access chains.
For modern delegated systems, especially when AI agents or service layers are involved, provenance is not just a nice-to-have. It is what lets defenders answer whether a request came from the original user, a brokered service, or an automated intermediary acting within its own boundary of authority.
What On-behalf-of Tokens Do Not Solve
An on-behalf-of token does not by itself guarantee that the downstream service can fully trust the request context. It also does not eliminate the need to verify token audience, intended resource, issuer trust, or the boundaries of what the delegated token can actually do. If those checks are weak, the token can still be replayed, overextended, or accepted in the wrong place.
That is why the delegation model should be read together with sender-constraining and audience restriction. RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP) strengthens tokens against replay, while RFC 8707: Resource Indicators for OAuth 2.0 helps bind access tokens to the intended target resource.
Put simply, an on-behalf-of token is a delegation artifact, not a complete security story. It should be treated as one control point in a larger design that also covers authentication, audience restriction, and proof that the presenter is the rightful holder.
Where On-behalf-of Tokens Fit in Modern Security Design
On-behalf-of flows are most useful when service-to-service access must remain bounded, explainable, and auditable. They show up in API mediation, workload federation, federated platforms, and agentic systems where one component needs to act with borrowed authority but should not inherit unrestricted access. The design objective is narrow delegation, not credential reuse.
That makes the pattern especially relevant to brokered protocols and intermediary services. The Model Context Protocol: Authorization specification is a good example of how modern systems try to avoid token passthrough and instead require audience-bound access for the receiving service.
Used well, on-behalf-of tokens reduce blast radius and make authority easier to reason about. Used poorly, they can hide who truly initiated the action, create overbroad delegated access, or leave defenders with logs that show a token exchange but not the full trust chain behind it.
Risk and Threat Considerations
On-behalf-of tokens create a concentrated trust dependency: if delegation is too broad, if the broker is compromised, or if downstream services accept the token outside its intended scope, attackers can turn legitimate delegation into unauthorized access. The core risk is not the token itself, but the authority chain it represents.
Failure mechanism: An attacker abuses a compromised intermediary, mis-scoped token, or weak audience check to move laterally through delegated services while preserving the appearance of legitimate authority.
Impact: The result can be privilege escalation, unauthorized downstream actions, replay of delegated access, and incomplete incident reconstruction because the visible token trail does not capture the full chain of actors.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 provides the primary governance reference for this term.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Delegated tokens are identity-bearing material that must be issued, bounded, and revoked safely. |
| AC-6 — Least Privilege | On-behalf-of delegation should narrow authority to only the downstream action needed. | |
| AU-3 — Content of Audit Records | On-behalf-of flows require audit records that preserve actor and subject context. | |
| Recommendation — Manage delegated tokens with clear issuance, rotation, and revocation controls. Limit delegated access to the minimum permissions needed for the specific downstream request. Record the initiating actor, delegated subject, and service path in audit logs. | ||
Practitioner Guidance
Why practitioners should care: An on-behalf-of token is only safe when the delegation boundary is explicit. Treat the broker, the subject, and the downstream service as separate trust decisions, and make sure logs preserve enough context to reconstruct the full request path.
What to watch for: Be cautious when a delegated flow starts to resemble direct impersonation, when audience checks are loose, or when a service can exchange tokens more broadly than its business purpose requires. Those conditions usually mean the architecture is carrying more authority than it should.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 4, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org