How should security teams separate approval and execution in high-risk workflows?

Security teams should design workflows so no single identity can request, approve, and complete the same high-risk action. In practice, that means separate roles for initiation, authorisation, and execution, plus logging that proves each step happened independently. The control matters most where money, privileges, or sensitive data can move quickly.

Why This Matters for Security Teams

Separating approval from execution is one of the most reliable ways to stop a high-risk workflow from becoming a self-serve privilege escalation path. When the same identity can initiate, authorise, and complete an action, the control is mostly procedural, not real. That is especially dangerous in NHI-heavy environments where API keys, service principals, and Top 10 NHI Issues frequently show up in automation paths that move faster than human review. The issue is not just fraud prevention. It is also containment, traceability, and limiting blast radius when a workflow is abused.

NIST Cybersecurity Framework 2.0 reinforces the need for controlled authorisation, accountability, and auditable execution, but the hard part is operationalising that separation in systems that were built for convenience. In practice, security teams often discover that “approval” is only a UI checkpoint while the underlying automation still runs under the same standing credential. That is why NHIMG treats workflow separation as an identity control, not just a process control, and why the OWASP NHI Top 10 is increasingly relevant to approval chains that touch agents and other autonomous workloads.

In practice, many security teams encounter approval bypass only after a routine automation path has already moved money, changed privileges, or exported sensitive data.

How It Works in Practice

The control starts by splitting the workflow into distinct identities and trust boundaries. One identity can request the action, a separate approver identity must authorise it, and a different execution identity performs the task. That separation should be enforced in the backend, not just the interface. For high-risk actions, current guidance suggests using policy checks at request time, step-up approval thresholds, and immutable logging that records who requested, who approved, and which execution credential completed the action.

This is where NHI governance becomes practical. If the execution side relies on the same static secret used to request the change, the workflow is still effectively one identity. Instead, teams should prefer short-lived credentials, scoped tokens, or delegated execution identities with narrow permissions. The approval decision should be bound to context such as target system, data sensitivity, amount, environment, and time window. That aligns with the separation principles discussed in NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks, where over-privileged automation and weak rotation are recurring failure modes.

• Use one identity for initiation and a different one for execution.
• Bind approvals to request context, not just ticket status.
• Issue just-in-time access for the execution step and revoke it immediately after completion.
• Keep tamper-evident logs that prove the approval and execution identities were distinct.

For implementation, teams often combine workflow engines, PAM, and policy-as-code so the approval service cannot also act as the executor. Zero standing privilege helps, but only if the approval and execution identities are isolated and monitored independently. These controls tend to break down when legacy orchestration tools reuse one shared service account across multiple approval and execution paths because the audit trail becomes syntactic rather than trustworthy.

Common Variations and Edge Cases

Tighter separation often increases friction, so organisations have to balance stronger abuse prevention against slower operations and more complex incident response. That tradeoff is real in environments with emergency change windows, highly distributed microservices, or batch jobs that cannot tolerate long approval chains. Best practice is evolving here: there is no universal standard for how many approvers are enough, but the principle that no single identity should be able to request and execute the same high-risk action is broadly accepted.

Edge cases matter. In low-risk automation, a lightweight approval or pre-authorised policy may be sufficient. In regulated or high-impact workflows, the approval should come from a distinct human or governance service, while execution uses a separate workload identity with tightly bounded scope. Where agents are involved, this becomes even more important because an autonomous system can chain tools, retry actions, and move laterally in ways a human reviewer would not anticipate. For that reason, NHI separation should be paired with continuous monitoring and least-privilege design, not treated as a one-time control.

NHIMG’s research on The 2024 ESG Report: Managing Non-Human Identities shows why this discipline matters: compromised NHIs often lead to repeated incidents, not one-off events. In environments with shared service accounts, outsourced operations, or broad vendor access, approval and execution separation is often undermined by operational shortcuts long before a formal control review catches it.

Related resources from NHI Mgmt Group

• How should organizations separate approval and execution in accounts payable workflows?
• How should security teams handle authentication after login in high-risk workflows?
• How do security teams know whether identity governance is reducing risk?
• How should security teams use ISPM to reduce identity risk?