How should security teams restrict new cloud permissions before they expand access to humans and machine identities?

Why This Matters for Security Teams

New cloud permissions are rarely harmless. When a platform adds a capability, that permission often lands in production before teams have updated guardrails, reviewed blast radius, or confirmed which identities should ever use it. For humans, that can mean a new admin path. For machines, it can mean a fresh way to chain tokens, assume roles, or reach data stores that were never in scope.

The practical risk is that cloud expansion outruns governance. Security teams should not wait for a business unit to ask for access; they should default to deny until the new permission is mapped to an approved use case and identity class. That approach aligns with the least-privilege direction in the OWASP Non-Human Identity Top 10 and the control discipline in NIST SP 800-53 Rev 5 Security and Privacy Controls.

NHIMG research shows the pattern is not theoretical: only 1.5 out of 10 organisations are highly confident in securing NHIs, and over-privileged accounts remain one of the top cited causes of NHI-related attacks in The State of Non-Human Identity Security. In practice, many security teams encounter permission sprawl only after a cloud service has already been granted broad access and started using it in ways no reviewer originally intended.

How It Works in Practice

The safest pattern is to treat every newly released permission as a controlled exception. Start by classifying the permission as sensitive, operationally broad, or low risk, then block it at the policy layer until an owner approves the business need. That means updating service control policies, IAM policies, permission boundaries, and conditional rules before the permission becomes generally available.

For human access, teams usually pair the new permission with role review, ticketed approval, and just enough scope for the task. For machine identities, the bar should be higher because workloads often scale faster than human review cycles. New permissions should be granted only to the specific service account, workload identity, or automation pipeline that needs them, and ideally only through short-lived access paths. Where possible, combine deny-by-default controls with session-based or ephemeral authorization so the permission exists only during the approved task.

• Map the new permission to specific data, APIs, and cloud resources before enabling it.
• Separate human roles from workload identities so a feature release does not inherit human-grade access.
• Use policy-as-code to express the deny rule once and enforce it everywhere.
• Require logging and alerting for first use, because unused permissions still create latent risk.

This approach is consistent with the Ultimate Guide to NHIs and the attack patterns documented in the 52 NHI Breaches Analysis, where excessive or stale access repeatedly widened the impact of compromise. It also fits the NIST control model for access enforcement, particularly when paired with runtime verification rather than one-time approval. These controls tend to break down when cloud teams can self-approve permissions outside central policy, because then the deny-first model becomes advisory instead of enforceable.

Common Variations and Edge Cases

Tighter permission controls often increase release friction, requiring organisations to balance speed against the cost of review, testing, and exception handling. That tradeoff is real, especially in fast-moving cloud environments where platform teams ship new services continuously.

Best practice is evolving for this area, but current guidance suggests different handling for different identity types. Human access can often be constrained through RBAC plus approval workflows, while machine identities need stricter scoping because they may call new APIs automatically the moment they appear. Some cloud permissions are safe to pre-authorise for low-risk telemetry or read-only operations, but anything that can create, delete, escalate, or exfiltrate should remain blocked until explicitly mapped.

There is also a governance edge case when teams assume a new permission is “just for future use.” That assumption is dangerous for NHIs, because dormant permissions become standing expansion paths later. The stronger pattern is to maintain a permission inventory, re-review newly enabled capabilities after each cloud provider release, and tie any exception to a named owner and expiry date. The 2026 Infrastructure Identity Survey found that 70% of organisations already grant AI systems more access than they would give a human employee doing the same job, which is a warning sign for every new permission review.

Related resources from NHI Mgmt Group

• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?
• How should security teams govern non-human identities in cloud environments?
• How should security teams rank machine identities when access paths matter as much as permissions?