Without tight restriction, request on behalf of workflows can become a privilege escalation path. An employee could request access for another user without proper authority, bypassing normal accountability and weakening approval integrity. Safe implementation requires role-based limits, clear ownership, and an auditable record of who initiated the request and why.
Why This Matters for Security Teams
Request on behalf of workflows are meant to preserve usability, but when anyone can invoke them, they become an approval bypass with real privilege-escalation potential. The risk is not just bad formality. It is broken accountability, where access is granted under someone else’s name while the initiator remains hidden from review. That undermines segregation of duties, incident attribution, and access governance.
For security teams, the failure mode is familiar: a trusted-looking workflow is used to approve or submit a request that the initiator should never have been able to make. This is especially dangerous when the request touches secrets, privileged roles, or service access. NHI Mgmt Group has repeatedly shown how weak identity governance amplifies damage, including in cases like the Schneider Electric credentials breach, where identity and credential controls were central to exposure. In practice, many security teams encounter this only after an access review or audit has already failed to explain who truly initiated the request.
How It Works in Practice
The secure pattern is to treat request on behalf of as a delegated action, not a general-purpose submission path. That means the workflow must verify both the requester and the approver, then enforce policy at the moment of request. Current guidance from the NIST Cybersecurity Framework 2.0 aligns with this by emphasizing accountable access control, auditability, and risk-based governance.
Operationally, that usually means:
- Restricting who can submit on behalf of others through RBAC or scoped delegation rules.
- Binding each request to a named owner, requester, and approver with immutable audit logs.
- Requiring the approver to have explicit authority over the target identity, system, or data domain.
- Adding step-up verification for high-risk requests, especially those involving admin roles or secret access.
- Separating workflow convenience from approval authority so the UI cannot imply permission that the backend does not enforce.
This becomes even more important where workflows touch CI/CD, APIs, or automation tokens. The GitHub Action tj-actions Supply Chain Attack is a reminder that request paths and automation paths often intersect, and one weak approval edge can expose many downstream systems. The right control objective is not merely to log a request, but to prove that the delegate was authorised to act for that specific person, at that specific time, for that specific purpose. These controls tend to break down when approval rights are inherited too broadly across shared service desks or cross-functional queues because the system can no longer distinguish convenience from authority.
Common Variations and Edge Cases
Tighter delegation controls often increase workflow friction, requiring organisations to balance approval speed against misuse resistance. That tradeoff is real, especially in large enterprises where managers, project leads, and service desk teams all need some form of proxy action.
Best practice is evolving, but current guidance suggests using narrowly scoped delegation with time bounds, explicit purpose codes, and post-action review for sensitive requests. A permanent “request for anyone” feature is almost always too broad. Temporary delegation is safer, but only if it expires automatically and is separately auditable.
There is no universal standard for this yet, so implementation should follow the risk of the underlying entitlement. A request for a low-risk application role may justify lighter controls. A request involving privileged access, secrets, or production systems should require stronger approval integrity and stricter ownership checks. The core test is simple: if the approver cannot explain why the requester was allowed to act on behalf of another identity, the workflow is already too permissive.
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 CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF 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-04 | Delegated requests can become privilege escalation if ownership and authority are not enforced. |
| CSA MAESTRO | A3 | Approval integrity is a core agentic access control concern for delegated workflows. |
| NIST CSF 2.0 | PR.AC-4 | Access authorisation must stay limited to approved, attributable use cases. |
| NIST AI RMF | GOVERN | Trusted-approver logic needs governance, accountability, and traceable decision ownership. |
| NIST Zero Trust (SP 800-207) | 4.1 | Zero trust requires explicit verification of request authority, not assumed trust in workflows. |
Require explicit delegation scope, expiry, and audit evidence before any on-behalf-of action is allowed.
Related resources from NHI Mgmt Group
- What breaks when signing workflows depend on certificate-based admin access alone?
- How should security teams design access request workflows for complex resource environments?
- What breaks when executive impersonation is trusted inside normal workflows?
- What breaks when fork pull request workflows can influence deployment context?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
