Who is accountable when a cloud identity can both approve and execute changes?

Accountability breaks when one identity can both authorise and perform the same sensitive action because the approval control no longer provides independent oversight. In that case, organisations need separate operational, approval, and audit roles, plus evidence that machine identities cannot bypass those boundaries.

Why This Matters for Security Teams

When one cloud identity can both approve and execute changes, the control environment loses separation of duties and the accountability trail becomes ambiguous. That is not just an access issue; it is a governance failure that can hide privilege misuse, suppress meaningful review, and make post-incident attribution difficult. NIST Cybersecurity Framework 2.0 emphasises governance, access control, and auditability as core outcomes, and NHI management guidance from Ultimate Guide to NHIs shows why machine identities need lifecycle controls, not just authentication.

The practical problem is that cloud-native workflows often blur the line between request, approval, and execution. A service account, CI/CD bot, or AI agent may be trusted to open a change, validate it, and push it live, especially where speed is prized over control design. That creates an easy path for over-privileged identities to bypass human oversight, especially when secrets are long-lived or embedded in automation. The issue is reinforced by breach patterns discussed in 52 NHI Breaches Analysis and by the governance expectations in NIST Cybersecurity Framework 2.0.

In practice, many security teams only discover this failure after a change is made by the same identity that was supposed to stop it.

How It Works in Practice

Accountability starts with separating the roles that request, approve, and apply a change. In a healthy model, the operational identity can prepare an action, but a different approval path must authorise it, and a third control plane must execute and record it. For cloud workloads, that usually means RBAC for coarse access, policy-as-code for runtime decisions, and a tamper-evident audit log that captures who approved what, when, and under which context. Current guidance suggests pairing this with ZTA principles so that no identity is implicitly trusted just because it is inside the environment.

For autonomous systems and agents, static IAM is usually too blunt. A better pattern is just-in-time credential issuance, short-lived secrets, and workload identity that proves what the workload is rather than what someone configured last month. That is why implementation discussions increasingly centre on OIDC-backed workload identity, SPIFFE/SPIRE-style attestation, and runtime policy checks that can deny a change if the agent’s intent does not match the approved task. The operational goal is to ensure the identity that can request a change is not the same identity that can commit it. NHI guidance in Top 10 NHI Issues and the incident patterns in Snowflake breach both point to the same theme: over-broad machine access turns convenience into compromise.

• Use separate identities for request, approval, and execution.
• Issue JIT credentials with tight TTLs and automatic revocation.
• Bind approvals to context, not just to a named role.
• Log every step so audit can reconstruct the decision chain.
• Deny execution if the approving identity and executing identity are the same.

These controls tend to break down in legacy automation pipelines that were built around shared service accounts, because one credential often spans multiple toolchains and cannot enforce runtime separation cleanly.

Common Variations and Edge Cases

Tighter separation of duties often increases operational overhead, requiring organisations to balance deployment speed against stronger assurance. That tradeoff is especially visible in DevOps, infrastructure-as-code, and agentic AI environments where teams want fewer handoffs and faster remediation. Best practice is evolving, and there is no universal standard for every cloud workflow, but the direction is clear: approval must be independent from execution whenever the action is high impact.

Edge cases appear when one automation flow must both validate and remediate, such as an auto-scaling controller, a security response bot, or an AI agent acting on live telemetry. In those cases, the answer is not to remove automation, but to constrain it with context-aware authorisation, narrow blast radius, and explicit policy thresholds. If the workflow genuinely requires a single identity to trigger and carry out a low-risk action, the organisation should document why, add compensating detective controls, and review that exception regularly. For broader implementation patterns, the Ultimate Guide to NHIs — What are Non-Human Identities remains the clearest baseline reference.

Where this guidance gets hardest to apply is in multi-account cloud estates with inherited permissions, shared pipelines, and identities that also carry agentic execution authority, because approval boundaries become difficult to enforce consistently across tools and teams.

Related resources from NHI Mgmt Group

• Who is accountable when a single user can both approve and execute a sensitive action?
• How should security teams govern workload identity across mixed cloud environments?
• Who should approve identity issuance for autonomous agent inboxes?
• How should security teams prioritise NHI remediation in cloud environments?