A token or session pattern where one identity acts for another while preserving evidence of delegation. For agents, the value is not just access propagation. It is the ability to show that the action was performed under a specific authority and within a specific scope.
Expanded Definition
On-Behalf-Of Flow is a delegation pattern used when one identity, often an agent, service, or middleware component, requests a token that represents a downstream action performed for a user or another principal. The key distinction is not merely passing access along, but preserving proof of who authorised the action, what scope was granted, and where the delegation chain ends.
In NHI governance, this pattern matters because it creates an auditable bridge between human intent and machine execution. It is closely related to delegated authorization, token exchange, and constrained impersonation, but definitions vary across vendors and platforms. No single standard governs this yet, so practitioners should treat the implementation as a control design choice rather than a universal protocol guarantee. For the broader identity and trust model, NIST Cybersecurity Framework 2.0 provides useful language for access control and traceability, while the identity lifecycle risks described in the Ultimate Guide to NHIs show why delegation cannot be separated from governance.
The most common misapplication is treating on-behalf-of tokens as if they were ordinary service credentials, which occurs when teams ignore delegation scope and reuse the token beyond the intended actor-chain.
Examples and Use Cases
Implementing on-behalf-of flow rigorously often introduces token exchange complexity and stricter claim validation, requiring organisations to weigh traceability against integration overhead.
- An AI agent updates a ticketing record on behalf of a user, with the downstream API receiving a token that captures the user’s authority and the agent’s limited action scope.
- A workflow engine calls a payment service after a human approver signs off, preserving who approved the request while ensuring the engine cannot exceed the approved operation.
- A support portal uses delegated access so a case-management integration can read customer data only for the specific case and only for the duration of the session.
- A security automation tool rotates a secret on behalf of an operator, with the action chain recorded for later review and incident reconstruction.
- Teams designing service-to-service delegation often compare the pattern with broader identity guidance in the Ultimate Guide to NHIs and access-control concepts in NIST Cybersecurity Framework 2.0.
Why It Matters in NHI Security
On-behalf-of flow becomes critical whenever an NHI must act with borrowed authority, because auditability, scope limitation, and revocation all depend on the delegation chain being preserved. Without that chain, an agent can look operationally correct while still creating governance blind spots, especially during incident response, privilege review, or post-incident forensics.
This matters in practice because NHIs already outnumber human identities by 25x to 50x in modern enterprises, and only 20% of organisations have formal processes for offboarding and revoking API keys, according to NHI Mgmt Group in the Ultimate Guide to NHIs. When delegation is poorly designed, revocation may stop the wrong actor or fail to stop the real one. The NIST view of access control in NIST Cybersecurity Framework 2.0 reinforces the need for traceable, least-privilege authorization paths.
Organisations typically encounter the consequence only after a delegated action is questioned during an incident, at which point on-behalf-of flow becomes operationally unavoidable to verify.
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-03 | Delegation chains and token scope are central to NHI authorization and misuse prevention. |
| NIST CSF 2.0 | PR.AA-04 | Identity proofing and access control support traceable delegated actions across systems. |
| NIST Zero Trust (SP 800-207) | PA-4 | Zero Trust requires continuous evaluation of every authorization, including delegated machine actions. |
Limit delegated tokens to explicit scope, then log the actor chain for every downstream NHI action.
Related resources from NHI Mgmt Group
- What is the difference between access control and data-flow control for agents?
- How should security teams authorize API requests made by applications on behalf of users?
- Who is accountable when an AI agent runs a query on behalf of a user?
- How should security teams choose between PKCE and device flow for CLIs?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
