TL;DR: Independent testing against 16 known AWS attack paths found that unrestricted environments remained exploitable while Cloud Permissions Firewall controls blocked all 16 scenarios, including privilege escalation, persistence, and lateral movement paths, according to Sonrai Security. The result reinforces that cloud least privilege must be enforced at execution time, not only described in policy.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Sonrai Security's blog post: Unrestricted AWS environments remained exploitable while cloud controls blocked 16 of 16 tested scenarios.
Why it matters: It matters because IAM teams need to treat standing privilege, over-provisioned permissions, and service-based execution paths as live attack surface, not just configuration issues.
Context
AWS privilege escalation is not limited to one bad policy or one exposed key. In cloud environments, attackers can chain legitimate control-plane actions, service permissions, and orchestration paths to move from access to escalation, persistence, and lateral movement.
This article examines that problem through controlled testing against known AWS attack paths. The central identity-governance issue is whether least privilege exists only on paper, or whether it is enforced at the moment permissions are actually used.
The article also points to newer cloud surfaces, including service-based execution paths and AI-related services, which expand the number of places where privilege can be abused if access is over-provisioned.
Key questions
Q: What breaks when AWS access is still based on standing privileges?
A: Standing privileges create a governance gap because access can outlive the task, the approval, and sometimes the operator. That makes overprovisioning, audit blind spots, and hidden reuse far more likely. In AWS, the failure is not only excess access. It is the absence of a reliable expiry boundary that forces privileges to disappear when the work is done.
Q: Why do over-provisioned cloud permissions increase the risk of escalation?
A: Over-provisioned permissions increase risk because privileged APIs can become attacker tools when an identity can attach policies, create keys, change roles, or start sessions without additional approval. Once those actions are available, the environment can be turned into an escalation path rather than a controlled workflow.
Q: How do you know if cloud least privilege is actually working?
A: You know it is working when every high-sensitivity datastore has a short, explainable list of identities with clearly bounded access and documented business need. If cross-account roles, inherited trust, or federated permissions reach sensitive data without a strong justification, least privilege is only partially implemented.
Q: Should organisations use service control policies or role reviews to control cloud privilege?
A: Both matter, but they solve different problems. Role reviews show who appears over-privileged, while service control policies can stop risky actions from being used at all. For cloud escalation paths, the stronger control is the one that constrains execution, because that is where legitimate permissions become abuse.
Technical breakdown
Why standing privilege remains the core AWS escalation primitive
In AWS, the dangerous condition is not simply that an identity exists, but that it can keep high-risk permissions available long enough to be abused. Privilege escalation often depends on control-plane actions such as attaching policies, creating access keys, updating assume-role policies, or starting sessions that should have been gated. If those permissions are always on, the environment becomes a chain of exploitable actions rather than a set of isolated controls. The technical issue is that legitimate APIs can be used as attack steps when authorization is too broad.
Practical implication: treat high-risk IAM actions as issuance events, not permanent entitlements.
How permissions-on-demand changes cloud attack paths
Permissions-on-demand is a just-in-time model for privileged cloud access. Instead of leaving risky permissions attached to a role or user, the control grants them only when a task requires them and removes them again after use. That matters because many AWS attack paths rely on the persistence of usable privilege across multiple steps. If the attacker cannot keep the permission long enough to chain the next action, escalation, persistence, and lateral movement become much harder to complete.
Practical implication: scope privileged actions to the shortest possible execution window.
Why service control policies matter in cloud identity defense
The article shows the controls were enforced through cloud-native guardrails, primarily service control policies. That is important because identity policy alone is often too permissive once inherited roles, service access, and delegated permissions are in play. SCPs give organisations a way to constrain which services and actions are even available for use, which is stronger than simply reviewing what a role is allowed to do in theory. In cloud privilege security, the control point has to sit close to the execution layer.
Practical implication: use organisation-level guardrails to prevent risky IAM and service actions from ever becoming available.
Threat narrative
Attacker objective: The attacker aims to turn legitimate but over-broad cloud access into durable escalation, persistence, and movement across AWS services.
- Entry occurs through legitimate AWS access, not necessarily through compromise of the platform itself, because the attack path begins with an identity that can call privileged control-plane APIs.
- Credential or privilege abuse follows when over-provisioned permissions allow actions such as policy attachment, key creation, session start, or role assumption changes.
- Escalation and lateral movement become possible when those permissions are chained into persistence, new access paths, or service pivoting across AWS control surfaces.
- Impact is the ability to continue operating inside the cloud environment with broader access than originally intended, despite the original least-privilege model.
Breaches seen in the wild
- Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Execution-time least privilege is the real cloud control boundary: AWS privilege escalation is no longer just a policy design problem. When permissions remain available during runtime, legitimate API actions become an attack chain rather than a governed task sequence. The practitioner conclusion is that cloud identity controls have to be evaluated where action occurs, not where policy is documented.
Standing privilege creates a reusable attack surface: The article shows that over-provisioned permissions can support escalation, persistence, and lateral movement in the same environment. That pattern matters because a cloud role with broad rights is not a single exposure, it is a reusable platform for chaining control-plane actions. The practitioner conclusion is that entitlement scope and privilege duration must be analysed together.
Cloud-native guardrails matter more than visibility alone: Many organisations can see over-privilege, but visibility does not stop a live attack path. By enforcing service restrictions, region restrictions, and approval for high-risk actions, cloud-native policy can interrupt the exploit chain before privilege becomes abuse. The practitioner conclusion is that detection without execution control leaves the same attack path available.
Identity blast radius should be treated as a first-class metric: The most useful concept in this article is identity blast radius, meaning the amount of cloud control an identity can reach before it is constrained. When a role can invoke policy changes, session starts, and service updates, the blast radius is wider than most teams assume. The practitioner conclusion is to measure privilege by the number of exploitable paths, not by assigned role names.
Least privilege in cloud now spans human, workload, and service access: The article is not only about human administrators. It also reflects the wider cloud pattern in which service-based execution paths and AI-driven services expand the number of identities and permissions that can be abused. The practitioner conclusion is that cloud privilege governance has to cover every identity type that can touch the control plane.
From our research library:
- 91% of organisations say at least half of their privileged access is always-on, and only 1% have fully implemented just-in-time privileged access, according to a CyberArk study.
- Read next: AI Agent Authorisation Guide
What this signals
Identity blast radius: The useful question is no longer whether an AWS role is privileged, but how far that role can reach before control boundaries stop it. When organisations measure exposed paths instead of static entitlement lists, they can see why execution-time control matters more than post-hoc review.
Cloud privilege governance now has to cover service-based execution paths as well as classic IAM administration. That means teams should treat policy attachment, session initiation, and service updates as governed actions with runtime constraints, not as routine background permissions.
The cloud control point is shifting closer to the action itself. If a permission can be abused to create more privilege, then the governance problem is not documentation quality, it is whether the permission can be exercised in the first place.
For practitioners
- Map high-risk AWS actions to approval-gated permissions Treat actions such as policy attachment, access-key creation, role policy updates, and session starts as privileged events that require explicit approval before execution.
- Reduce standing privilege in cloud roles Replace always-on access with just-in-time permission grants for the specific service and task so high-risk rights do not persist between operations.
- Block unused services and regions at the organisation boundary Use cloud-native guardrails to disable services and regions that should not be available in the account structure, shrinking the number of usable attack paths.
- Review delegated and inherited permissions for escalation paths Check whether attached policies, assume-role settings, and service permissions allow an identity to elevate itself or pivot into new privileges.
- Test privileged access controls against real attack chains Validate cloud identity policy against known escalation and lateral movement scenarios rather than against static compliance checklists alone.
Key takeaways
- AWS attack paths remain exploitable when high-risk permissions are left standing, even if policy language says least privilege is in place.
- Independent testing showed that cloud-native guardrails can stop complete escalation chains, which makes execution-time control the decisive variable.
- IAM teams should focus on privilege duration, service boundaries, and approval for risky actions if they want to reduce cloud attack paths.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Over-provisioned cloud identities are the core exposure in these AWS attack paths. |
| NHI-07 — Long-Lived Secrets | The article stresses standing privilege and access that persists long enough to be abused. | |
| Recommendation — Reduce overprivileged cloud identities and remove rights that enable escalation or lateral movement. Replace persistent cloud access with short-lived permission grants and revoke standing credentials. | ||
| MITRE ATT&CK | TA0004;TA0008 — Privilege Escalation; Lateral Movement | The tested scenarios center on escalation and movement across AWS services. |
| Recommendation — Map AWS attack paths to escalation and lateral movement tactics to prioritise detections and controls. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about whether permissions are constrained at execution time. |
| Recommendation — Apply entitlement controls that limit risky AWS actions before they can be used. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account and permission lifecycle govern the standing access being exploited. |
| Recommendation — Review account and permission assignments for standing access that can be chained into escalation. | ||
Key terms
- Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
- Execution-time control: A policy or guardrail that blocks or restricts a tool while it is running, before it can read secrets, execute commands, or exfiltrate data. For developer environments, execution-time control is the difference between observing a malicious artifact and stopping it from doing harm.
- Cloud Attack Path: A cloud attack path is a sequence of exposures that could let an attacker move from a weak point to meaningful compromise. It may combine identity misconfiguration, excessive permissions, exposed data, and reachable workloads, so prioritisation depends on understanding how those risks connect.
- Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 24, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org