Request on behalf of is a delegated access workflow that lets an approved user submit a request for someone else. It is useful for managers, resource owners, and emergency situations, but it also creates abuse risk if poorly controlled. Strong implementations limit who can submit, who can approve, and what is recorded.
Expanded Definition
Request On Behalf Of, often shortened to ROBO, is a delegated access pattern in which an authorised user submits an access, workflow, or entitlement request for another identity. It is common in joiner-mover-leaver processes, manager approvals, and emergency access scenarios, but it is not the same as direct delegation of authority, nor is it a substitute for standing privilege. In NHI governance, ROBO matters because the requester, approver, and eventual recipient can all be different actors, which means auditability and policy enforcement must be explicit.
Definitions vary across vendors on whether ROBO includes only submission, or also approval chaining and temporary entitlement assignment. NHI Management Group treats the term as a control pattern that should align with least privilege, traceable sponsorship, and clear separation of duties. That makes it closely related to access request workflows described in the NIST Cybersecurity Framework 2.0, especially where identity governance and approval integrity are in scope. The most common misapplication is treating ROBO as proof of authorisation, which occurs when a requester is allowed to act for another identity without policy-based limits on scope, duration, and recorded justification.
Examples and Use Cases
Implementing ROBO rigorously often introduces approval overhead and stronger audit requirements, requiring organisations to weigh faster operations against tighter control of delegated requests.
- A manager submits a temporary access request for a new hire’s service account so onboarding can proceed before the employee receives direct portal access.
- An incident commander requests emergency credentials on behalf of an application owner during an outage, with time-bound approval and post-event review.
- A platform engineer requests a short-lived API key for a deployment pipeline on behalf of a team that lacks direct provisioning rights.
- An identity governance team uses ROBO to centralise requests, while preserving evidence of who initiated, reviewed, and fulfilled the action.
These patterns should be documented against broader NHI lifecycle controls described in the Ultimate Guide to NHIs, especially where service accounts, keys, and approvals intersect. ROBO also becomes more trustworthy when it is constrained by standards-based identity assurance logic such as the NIST Cybersecurity Framework 2.0 and mapped to ticketing, approval, and provisioning evidence.
Why It Matters in NHI Security
ROBO is a governance control point, not a convenience feature. When it is loosely implemented, it can let a well-meaning employee sponsor excessive access, obscure who really initiated a privileged change, or create a shadow delegation path that bypasses review. That is especially dangerous for NHIs because service accounts, API keys, and automation principals often outlive the human who requested them. NHI Mgmt Group reports that 97% of NHIs carry excessive privileges, and only 5.7% of organisations have full visibility into their service accounts, which makes delegated request pathways a prime place for hidden privilege expansion. The Ultimate Guide to NHIs also shows that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
Practitioners should treat ROBO as a high-risk workflow that needs role scoping, strong logging, approval provenance, and periodic review. Without those controls, the request path itself becomes an attack path. Organisations typically encounter the operational cost of weak ROBO only after a misuse investigation or access incident, at which point the delegated request trail becomes operationally unavoidable to reconstruct.
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 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63 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-06 | ROBO can mask unauthorized privilege grants when delegated requests are not tightly governed. |
| NIST CSF 2.0 | PR.AA-05 | Identity governance and access approval integrity apply directly to delegated request workflows. |
| NIST SP 800-63 | Identity proofing and authenticator assurance influence who can act on behalf of another identity. | |
| NIST Zero Trust (SP 800-207) | AC-6 | Zero trust requires least privilege and explicit authorization for any delegated access action. |
| OWASP Agentic AI Top 10 | A2 | Autonomous or assisted agents can misuse delegated request paths if authority is unclear. |
Require requester, approver, and beneficiary controls with complete audit trails for every delegated request.
Related resources from NHI Mgmt Group
- What is the difference between network trust and request-level identity trust?
- Why do access-request workflows matter for NHI governance?
- How should organisations use AI in access request approval without weakening control?
- What is the difference between access request automation and access governance?
