What breaks when request on behalf of workflows are not restricted to trusted approvers?

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.

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?