How do organisations decide which identities should keep access to new sensitive cloud actions?

Organisations should map each action to the smallest set of identities that need it, then validate that access against job function and operational necessity. Human administrators, automation roles, and service accounts should not share the same standing permissions by default. If an action can change scanning, encryption, or execution behavior, treat it as high risk and scope it tightly.

Why This Matters for Security Teams

New sensitive cloud actions are where identity sprawl becomes operational risk. If a permission can alter scanning, encryption, key management, or execution paths, it can change the blast radius of a compromise instantly. The practical question is not whether an identity can technically be granted access, but whether it should retain standing access after the business need is met. That is why current guidance increasingly aligns with least privilege, explicit approval paths, and continuous review, as reflected in the OWASP Non-Human Identity Top 10 and the control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls.

NHIMG research shows why this is hard in practice: the 2024 Non-Human Identity Security Report found that 88.5% of organisations say their non-human IAM practices lag behind or merely match human IAM. That gap matters most when new cloud actions are introduced faster than access reviews can be updated. In practice, many security teams discover over-entitled identities only after a sensitive action has already been enabled and exercised.

How It Works in Practice

Organisations usually decide access by starting with the action itself, not the identity. The first step is to classify the new cloud action by impact: does it affect data exposure, encryption state, code execution, network reachability, or privileged configuration? If yes, it should be treated as a high-risk capability and mapped to the smallest identity set that truly needs it. That often means separating human administrators, automation roles, and service accounts rather than reusing one broad role across all three.

For sensitive actions, static role-based access is often too blunt. Agents and automation do not always follow fixed patterns, so teams increasingly use context-aware authorisation, just-in-time grants, and short-lived secrets. This is where workload identity becomes important: a strong cryptographic identity can prove what the workload is, while policy decides what it may do at request time. In modern implementations, that may be enforced with policy-as-code and runtime evaluation rather than a one-time role assignment.

• Define the action’s risk level before assigning any identity.
• Map access to job function, operational necessity, and environment scope.
• Use separate identities for humans, service accounts, and automation.
• Prefer ephemeral credentials and revocation on task completion.
• Review whether the same action should be allowed in dev, staging, and prod.

That approach is consistent with the identity governance concerns documented in the Ultimate Guide to NHIs and the access-risk patterns highlighted in the 52 NHI Breaches Analysis. These controls tend to break down in fast-moving multi-cloud environments because ownership, policy propagation, and revocation lag behind the rate at which new actions are introduced.

Common Variations and Edge Cases

Tighter access scoping often increases operational overhead, so organisations have to balance security benefit against deployment friction. That tradeoff is especially visible when a new action is needed by many pipelines or by a third-party integration that touches multiple accounts. Current guidance suggests avoiding broad shared permissions, but there is no universal standard for exactly how much exception handling is acceptable in every environment.

One common edge case is emergency access. Teams may allow temporary elevation for break-glass scenarios, but that should be time-bound, heavily logged, and reviewed after use. Another is agentic automation, where the identity may need access to chain several actions in sequence. In those environments, the better pattern is usually narrow task-scoped privilege plus continuous policy checks, not a single standing role that covers the entire workflow.

The main exception is legacy systems that cannot support fine-grained policy or short-lived credentials. In those cases, organisations should compensate with segmentation, stronger monitoring, and faster review cadences until the platform can be modernised. The broader lesson from NHIMG research on non-human identity maturity is that access decisions fail most often when teams confuse convenience with entitlement. New sensitive cloud actions should be granted only where the identity’s business purpose remains current and provable.

Related resources from NHI Mgmt Group

• Why do organisations struggle to keep identity controls effective as human and machine identities grow together?
• What breaks when organisations keep using user and password authentication for cloud automation?
• What breaks when organisations expand cloud access faster than they improve identity controls?
• Why does privileged access become a higher-risk control area when organisations expand into hybrid cloud and autonomous systems?