AWS attack paths expose the cloud privilege escalation problem

At a glance

What this is: Independent testing showed that 16 AWS attack paths succeeded in an unrestricted lab but were blocked when cloud-native least-privilege controls were applied.

Why it matters: This matters because IAM, PAM, and cloud security teams need execution-time controls that constrain privileged AWS actions before escalation, persistence, or exfiltration can occur.

By the numbers:

• The Cloud Permissions Firewall blocked 16 of the 16 attack paths tested by Software Secured.
• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.

👉 Read Sonrai Security's analysis of AWS attack paths and cloud privilege controls

Context

AWS privilege escalation is not just a policy design problem. It is an execution problem, because attackers abuse legitimate control plane actions, service permissions, and orchestration paths once a principal has more access than it needs. In cloud identity programmes, the real question is whether standing privilege can be constrained before an attacker converts it into persistence or lateral movement.

Sonrai Security's testing frames the issue clearly for IAM and cloud security teams. The article compares unrestricted AWS attack chains with a protected environment and shows that cloud-native guardrails can stop the same scenarios that succeed when privilege is left broad. That makes least privilege an operational control issue, not a documentation exercise.

Key questions

Q: How should teams stop AWS privilege escalation without breaking cloud operations?

A: Teams should identify the few AWS actions that enable escalation or persistence, then require just-in-time approval for those actions only. The goal is not to block normal operations, but to stop high-risk IAM, Lambda, Systems Manager, and service control plane changes from becoming reusable attack steps. Cloud-native guardrails work best when they evaluate requests before execution.

Q: Why do over-privileged cloud identities create such a large attack surface?

A: Over-privileged cloud identities make ordinary administrative actions dangerous because an attacker can chain them into key creation, policy changes, session access, or code modification. Once those permissions are standing, the cloud provider sees the activity as authorised unless a control intercepts it. That is why excess privilege turns legitimate services into escalation paths.

Q: What do security teams get wrong about least privilege in AWS?

A: They often treat least privilege as a policy state rather than an execution control. In practice, privilege is safe only if dangerous actions are blocked when requested, not merely described in an access review or architecture document. If high-risk permissions remain available all the time, the environment is still exploitable.

Q: How can organisations validate that cloud guardrails are actually working?

A: They should test guardrails against known attack paths in a controlled environment and verify that the same scenarios fail after controls are applied. Validation should focus on whether IAM, service, and orchestration actions are stopped before they can support escalation, persistence, or lateral movement. If the attack still succeeds, the control is not effective.

Technical breakdown

Why AWS attack chains still work through legitimate API actions

Many cloud attacks do not rely on exotic exploits. They chain ordinary AWS control plane actions such as creating access keys, attaching policies, starting sessions, or modifying functions. The problem is that these actions become dangerous when a principal already has excess privilege. Once an attacker reaches a role, user, or service with broad permissions, the cloud provider treats the next step as authorised activity unless a guardrail intervenes. That is why abuse often looks like normal administration until the chain is complete.

Practical implication: map which IAM actions can be chained into escalation, persistence, or exfiltration and block them before they become reusable attack steps.

How permissions-on-demand changes privileged access in cloud environments

Permissions-on-demand is a just-in-time model for privileged cloud actions. Instead of granting broad standing access, the control requires approval for high-risk permissions only when a task truly needs them. In the article, that model is implemented with cloud-native guardrails and service control policies, which means the request path is evaluated before the action executes. This shifts the control point from post-fact detection to pre-execution authorisation, which is where cloud attack paths are often easiest to break.

Practical implication: require approval gates for high-risk IAM and service actions rather than allowing standing access across all privileged workflows.

Why service-based execution paths widen the cloud attack surface

The article notes that attackers now exploit service-based execution paths, orchestration layers, and newer AI-driven services such as Bedrock and Bedrock AgentCore. These paths expand the number of places where privilege can be misused, because access is no longer limited to a single console login or role assumption. A service that can update code, start sessions, or call other services may provide a faster route to impact than classic IAM misuse. The architectural takeaway is that cloud identity governance must follow the service path, not only the human or workload principal.

Practical implication: include orchestration, serverless, and AI service permissions in the same privilege review as traditional IAM roles.

Threat narrative

Attacker objective: The objective is to turn over-provisioned cloud access into durable control of AWS services, then use that control for persistence, pivoting, or exfiltration.

1. Entry occurs when a principal with excessive AWS permissions is able to use normal control plane actions such as access key creation, session start, or policy attachment.
2. Escalation follows when those legitimate permissions are chained into privilege escalation, persistence, or code modification across IAM, Lambda, Systems Manager, or Bedrock AgentCore.
3. Impact is achieved when the attacker preserves access, pivots to other systems, or reaches data exfiltration through approved service actions that were never meant to be standing privileges.

Breaches seen in the wild

• Codefinger AWS S3 ransomware attack — Codefinger used compromised AWS credentials to encrypt S3 buckets via SSE-C.
• Azure Key Vault privilege escalation exposure — Azure Key Vault Contributor role misconfiguration enabled privilege escalation.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Standing privilege is the control failure this article exposes. The testing shows that AWS attack paths succeed when high-risk permissions are always available, because the environment trusts access that should have been temporary and task-scoped. That is not a tooling nuance, it is a governance gap in the way cloud identity is being authorised today. Practitioners should treat standing privilege as an active attack surface, not as a convenience.

Cloud attack paths now span IAM, orchestration, serverless, and AI service permissions. The article is a reminder that privilege escalation no longer sits only inside IAM roles and users. When Lambda, Systems Manager, and Bedrock AgentCore can all become part of the chain, access reviews that focus only on identities miss the service actions that actually deliver impact. The implication is broader scope for cloud identity governance and stronger control over service execution paths.

Least privilege works when it is enforced at the moment of use, not when it is documented. The protected lab environment blocked all 16 scenarios because the control intercepted high-risk actions before execution. That is the governance difference between policy intent and operational restraint, and it is why execution-time controls matter more than policy statements alone. Practitioners should judge cloud IAM by what it prevents, not by what it claims to allow.

Permission scoping must now include AI-driven infrastructure services. The article's Bedrock and Bedrock AgentCore scenarios signal where the market is heading: identity controls must keep pace with service layers that can themselves trigger privileged actions. This does not change the principle of least privilege, but it changes the surface area that principle must cover. Security teams should re-evaluate whether their cloud identity model actually extends into AI service operations.

Service control policies are becoming the practical enforcement layer for cloud privilege governance. Sonrai Security's framing shows that cloud-native guardrails can convert abstract access policy into a blocking control for dangerous actions. That matters because many organisations still separate identity governance from cloud service governance, even though the attack chain does not respect that boundary. Practitioners should align cloud identity review with the actual control plane paths attackers abuse.

From our research:

• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems, according to The 2026 Infrastructure Identity Survey.
• Another finding from the same survey showed that 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments.
• For related analysis, see 52 NHI Breaches Analysis for the breach patterns that recur when standing privilege is left in place.

What this signals

Cloud identity programmes are moving from inventory control to execution control. The testing in this article shows that policy visibility is not enough when an attacker can chain legitimate AWS actions into impact. Teams should assume that service permissions, orchestration layers, and AI service APIs now belong in the same governance model as classic IAM roles, especially when cloud platform teams own the sharp end of the decision-making. The practical signal is to treat privileged action blocking as a first-class cloud control, not a secondary detective measure.

Least privilege will increasingly be judged by whether it can stop a live attack path. With 70% of organisations already granting AI systems more access than human employees, per the 2026 Infrastructure Identity Survey, the gap between policy and enforcement is widening quickly. For practitioners, that means access reviews need to connect to service-level enforcement, not just entitlement cleanup.

Permission scoping now has to account for infrastructure services that can themselves trigger privileged change. That is especially true where cloud operations and AI-enabled services converge, because the attack path can move through legitimate functions faster than review cycles can react. Organisations should prepare for a world where cloud identity governance is measured by blocked actions and reduced attack paths, not by the size of the entitlement catalogue alone.

For practitioners

• Map privilege escalation chains to specific AWS actions Identify which IAM, Lambda, Systems Manager, and Bedrock AgentCore permissions can be combined into escalation, persistence, or pivoting paths, then block the highest-risk actions first.
• Replace standing privilege with just-in-time approvals Require approval for access key creation, role policy attachment, login profile changes, session start, and code update actions so privileged use is task-scoped rather than persistent.
• Extend access reviews beyond human-style roles Review service permissions, orchestration layers, and AI service actions as part of the same cloud identity governance process, because attackers move through service paths as easily as through identities.
• Test blocking controls against real attack scenarios Use vulnerable-by-design labs or internal simulations to verify that guardrails stop actual attack chains before execution, rather than assuming policy intent equals prevention.

Key takeaways

• This article shows that AWS privilege escalation often succeeds through legitimate actions, not exotic exploits.
• The test data demonstrates that blocking controls can stop the same attack paths that work in unrestricted environments.
• Cloud identity teams should shift from documenting least privilege to enforcing it at the moment high-risk actions are requested.

Key terms

• Standing Privilege: Standing privilege is access that remains available all the time instead of being granted only for a specific task. In cloud identity programmes, it creates a permanent attack path because any compromised principal can reuse that access immediately without waiting for approval or time-bound provisioning.
• Permissions-on-Demand: Permissions-on-demand is a just-in-time approach to privileged access where high-risk actions are approved only when a task requires them. In cloud environments, it shifts enforcement from broad entitlement assignment to request-time control, which reduces the chance that an attacker can reuse dormant privilege.
• Cloud-native Guardrail: A cloud-native guardrail is an enforcement control built into the cloud control plane or surrounding policy layer that can block risky actions before they execute. It is stronger than visibility alone because it changes the system's behaviour, not just its reporting.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or governance in your organisation, it is worth exploring.

This post draws on content published by Sonrai Security: Independent Testing Confirms Sonrai’s Cloud Permissions Firewall Blocks Real AWS Attack Paths. Read the original.