Who is accountable when a single user can both approve and execute a sensitive action?

Why This Matters for Security Teams

When one user can approve and execute a sensitive action, the issue is not merely a workflow mistake. It is a control-design failure that removes meaningful separation of duties, weakens detective oversight, and makes later attribution unreliable. That matters because auditors, incident responders, and business owners need to know whether the organisation prevented the conflict, detected it, or simply accepted it.

For identity-heavy environments, the same pattern often appears with service accounts, API keys, and privileged automation. NHI Mgmt Group research shows that 97% of NHIs carry excessive privileges, which helps explain how a single identity can accumulate approval and execution power over time. Guidance from NIST Cybersecurity Framework 2.0 and incidents discussed in the Schneider Electric credentials breach both reinforce the same lesson: accountability must be designed into the control plane, not assigned after the fact.

In practice, many security teams encounter this only after a transaction has already cleared both gates and the evidence trail shows the same identity on both sides of the approval.

How It Works in Practice

The practical fix is to separate authority, not just job titles. Approval should be performed by an identity that is cryptographically distinct from the identity that executes the action, with policy enforcing that separation at request time. In mature environments, that usually means RBAC defines who may review or recommend, while a different control layer prevents the same principal from completing the action. For high-risk operations, PAM, JIT access, and short-lived credentials reduce the chance that approval rights and execution rights persist together.

Where NHI is involved, the strongest pattern is workload identity plus intent-based authorisation. The system should evaluate what the actor is trying to do, which resource is being touched, and whether the request is within policy boundaries at that moment. That is more resilient than static access lists, because static lists assume predictable behaviour. For autonomous workloads, that assumption often fails. NIST guidance on identity and risk management supports this runtime approach, and current practice increasingly aligns with NIST Cybersecurity Framework 2.0 and emerging workload-identity patterns such as SPIFFE.

• Use separate identities for approver and executor, even if both belong to the same human owner.
• Issue JIT credentials with short TTLs, then revoke them automatically after the task completes.
• Log approval, execution, and policy-evaluation events separately so the control decision is auditable.
• Require secondary review when one identity has administrative reach across both stages.

That model also helps explain why NHI breaches like the Schneider Electric credentials breach matter beyond credential theft: once an identity can both bless and carry out the action, the organisation has lost a meaningful control boundary. These controls tend to break down when approval engines and execution systems share the same backend identity because the policy check and the action path collapse into one trust domain.

Common Variations and Edge Cases

Tighter separation often increases operational overhead, requiring organisations to balance speed against assurance. That tradeoff is real, especially in incident response, small teams, and emergency change windows where a second approver may not be immediately available. Current guidance suggests that exceptions should be explicit, time-bound, and heavily monitored rather than informal or permanent.

There is also no universal standard for exactly how to separate accountability in AI-assisted or semi-autonomous workflows. In some environments, the human approves the goal while an AI agent executes the steps; in others, the agent recommends the action and a human signs off. For these cases, the key question is whether the same principal can both authorise and perform the action without independent policy enforcement. If yes, the control is too weak. If no, the organisation has at least preserved an auditable decision boundary.

Edge cases often arise when shared admin roles, break-glass access, or delegated service accounts are used to speed delivery. Best practice is evolving toward zero standing privilege, narrowly scoped exceptions, and continuous review rather than broad permanent access. A practical benchmark is whether the identity that executes the action could be disabled without preventing approval, and whether approval evidence would still stand on its own. That standard is especially important in high-volume NHI estates, where hidden privilege accumulation is common and where the breach signal often appears after misuse has already occurred.

Related resources from NHI Mgmt Group

• Why is single-provider AI agent governance not enough for enterprise security?
• When do service accounts become a higher risk than ordinary user accounts?
• Who is accountable when a third-party integration is abused?
• Who is accountable when an unowned NHI is left active?