Privileged AWS permissions expose the real cloud access risk

At a glance

What this is: This is a ranking of the most dangerous AWS privileged permissions and the real abuse paths they open.

Why it matters: It matters because IAM, PAM, and cloud security teams need to treat cloud permissions as identity risk, not just configuration noise, across human, NHI, and autonomous-operated workflows.

👉 Read Sonrai Security's list of privileged AWS permissions to restrict immediately

Context

AWS privilege is not only a permissions problem, it is an identity governance problem. When a workload, service account, or administrator can invoke high-impact actions like policy edits, role assumption, secret retrieval, or logging removal, the blast radius is determined long before an attacker appears.

The article focuses on permissions that have already been abused in real-world incidents or customer environments. For practitioners, the question is not whether AWS IAM is flexible enough, but whether least privilege, access review, and privileged access governance are actually aligned to the actions that matter most.

Key questions

Q: How should security teams restrict dangerous AWS privileged permissions?

A: Start by separating policy management, role assumption, secret retrieval, and logging controls into different administrative domains. Then apply approval workflows, session restrictions, and periodic access review to the small set of permissions that can alter trust or remove oversight. The goal is to prevent a single identity from both gaining access and dissolving the guardrails around it.

Q: Why do AWS privileged permissions create such a large breach blast radius?

A: Because many AWS permissions do not just expose data, they change identity reach, trust relationships, or governance visibility. A principal that can pass roles, rewrite policies, retrieve secrets, or delete logs can turn limited access into account-level compromise. The blast radius is determined by downstream actions, not the role name alone.

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

A: They often treat least privilege as a count of permissions instead of a map of consequences. In AWS, one risky API can be more dangerous than dozens of benign read actions if it can alter trust, create persistence, or remove logging. Effective least privilege requires action-level analysis, not just role-level certification.

Q: Who should approve AWS permissions that can remove logging or guardrails?

A: Those permissions should sit with a separate platform or security governance function, not the same team that runs day-to-day cloud operations. If an operator can disable CloudTrail, detach policies, or move accounts without independent checks, the organisation has built an escape hatch into its own control plane.

Technical breakdown

Why high-impact AWS permissions become escalation primitives

AWS IAM permissions often look narrow in isolation, but several of the actions in this list are escalation primitives because they alter trust, policy, or execution context rather than just exposing one resource. For example, iam:PassRole, iam:PutRolePolicy, iam:AttachRolePolicy, and iam:UpdateAssumeRolePolicy can transform a limited identity into a far more powerful one without changing the surrounding account structure. That is why cloud privilege abuse often starts with a permission that appears administrative only in the abstract. The control failure is not the API itself, but the absence of action-level governance around who can invoke it and under what conditions. Practical implication: classify these permissions as privileged identity controls, not ordinary application access.

Practical implication: classify these permissions as privileged identity controls, not ordinary application access.

How logging and org controls fail when privileged access is over-scoped

Some AWS permissions do not just widen access, they weaken observability and governance. cloudtrail:DeleteTrail can erase evidence, while organizations:LeaveOrganization and organizations:DetachPolicy can remove guardrails that central teams rely on for oversight. In practice, that means an attacker or insider does not need to defeat every control, only the few permissions that let them escape shared governance. This is why cloud access review cannot stop at who has admin rights. It has to include whether a principal can disable the very controls that make review and detection possible. Practical implication: treat logging, org policy, and policy-administration permissions as crown-jewel entitlements.

Practical implication: treat logging, org policy, and policy-administration permissions as crown-jewel entitlements.

Why secret retrieval and role assumption remain high-value abuse paths

Permissions such as secretsmanager:GetSecretValue, kms:Decrypt, and sts:AssumeRole are valuable because they let an attacker move from one identity boundary to another. Secret retrieval exposes durable credentials or sensitive configuration, while role assumption turns those credentials into broader access across services or accounts. This is the classic cloud identity problem: once a principal can read secrets or chain into another role, the original access scope no longer defines the true risk. The permission boundary is only as strong as the identities and trust relationships behind it. Practical implication: audit every path that turns read access into new identity reach.

Practical implication: audit every path that turns read access into new identity reach.

Threat narrative

Attacker objective: The attacker wants durable, hard-to-detect control over AWS identities, policies, and data paths.

1. Entry occurs through an over-permissioned AWS principal that can reach sensitive resources or modify security controls without immediate challenge.
2. Escalation happens when the attacker uses permissions such as PassRole, PutRolePolicy, AttachRolePolicy, or AssumeRole to expand reach or create durable access.
3. Impact follows when secrets are exfiltrated, logging is disabled, guardrails are removed, or systems are disrupted at account or organization scope.

Breaches seen in the wild

• 230M AWS environment compromise — 230M AWS environments compromised via exposed .env files with cloud credentials.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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

NHI Mgmt Group analysis

AWS privilege risk is fundamentally an identity governance problem, not a permissions inventory problem. The article is right to surface dangerous actions, but the deeper issue is that many cloud programmes still review identities as if access were static and low-risk by default. Once a principal can modify trust policy, attach policies, assume roles, or delete trails, the identity itself becomes a control plane. Practitioners should stop thinking in terms of permission count and start thinking in terms of identity blast radius.

Privilege escalation in AWS is often a trust-chain problem disguised as a single API call. iam:PassRole, sts:AssumeRole, and policy mutation permissions are dangerous because they let a principal inherit someone else’s authority rather than simply use its own. That pattern is exactly why identity governance must map not just direct entitlements but also delegated execution paths. The implication is straightforward: if your review process cannot follow the trust chain, it cannot judge the real risk.

Logging removal and org-policy bypass should be treated as governance escape hatches. cloudtrail:DeleteTrail, organizations:LeaveOrganization, organizations:MoveAccount, organizations:UpdatePolicy, and organizations:DetachPolicy do more than change configuration. They remove the mechanisms that prove who did what and whether central control still exists. A cloud programme that lets one principal dissolve its own oversight has already failed at the identity layer. Practitioners should classify these entitlements as high-risk governance controls, not operational conveniences.

Standing access to secret retrieval and role chaining creates identity blast radius that outlives the original compromise. secretsmanager:GetSecretValue and kms:Decrypt are not just data access permissions. They are bridges into other systems, other accounts, and other trust domains. That is why least privilege in AWS must be measured by downstream reach, not by the apparent narrowness of the initial permission set. Security teams should evaluate every secret and role as a propagation point, not a destination.

Cloud privilege reviews need a control taxonomy, not a flat access list. Not all permissions are equal, and the article usefully distinguishes destructive, escalation, and governance-bypass actions. The problem is that many access review programmes still certify AWS access at the IAM role level without isolating the specific API actions that create compounding risk. The practical conclusion is that review, PAM, and cloud governance must converge on action-level entitlement analysis.

From our research:

• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to The 2026 Infrastructure Identity Survey.
• 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to The 2026 Infrastructure Identity Survey.
• For a broader control model, compare this with 52 NHI Breaches Analysis, which shows how exposed credentials and over-privilege turn identity into an attack path.

What this signals

Privilege escalation in cloud environments is becoming an identity architecture issue. The more AWS teams allow high-risk actions to sit inside ordinary operational roles, the more likely they are to create invisible escalation paths. The practical signal for practitioners is not just whether permissions are assigned, but whether they can be chained into trust changes, secret exposure, or logging removal.

With 67% of organisations still relying heavily on static credentials despite the risks they pose to agentic AI deployments, the broader market signal is clear: identity teams are still underestimating how quickly privileged access can be abused once it exists. That makes action-level review and control separation more urgent, not less.

Identity blast radius should become a standard review metric. If a single principal can alter policies, read secrets, and disable evidence, the organisation has allowed governance to collapse into one access path. Teams should use this article as a prompt to map which AWS permissions can terminate oversight as easily as they grant access.

For practitioners

• Restrict policy-writing permissions aggressively Remove iam:PutRolePolicy, iam:AttachRolePolicy, and iam:UpdateAssumeRolePolicy from broad admin groups unless there is a documented change workflow and strong approval path. These actions should be isolated to tightly controlled break-glass or platform administration roles.
• Separate governance controls from runtime operations Treat organizations:DetachPolicy, organizations:UpdatePolicy, cloudtrail:DeleteTrail, and organizations:LeaveOrganization as privileged governance actions that require independent oversight. Do not allow routine operators to touch controls that can remove logging or break central guardrails.
• Review secret and role chaining as one attack path Map every principal that can use secretsmanager:GetSecretValue, kms:Decrypt, or sts:AssumeRole, then trace where those permissions lead across accounts and services. A permission is only low-risk if the downstream trust chain is also constrained.
• Limit destructive EC2 and network-change permissions Scope ec2:TerminateInstances, ec2:ModifySecurityGroupRules, ec2:RunInstances, and ec2:ModifyInstanceMetadataOptions to narrowly defined operating roles. These actions can support exfiltration, command-and-control, persistence, or credential theft when they are too broadly available.

Key takeaways

• The core risk in AWS is not the presence of permissions, but the ability of a few permissions to expand access, hide evidence, or remove guardrails.
• Real-world breach patterns show that secret access, role chaining, policy mutation, and logging removal can turn limited cloud access into full compromise.
• Security teams should treat high-risk AWS API actions as privileged governance controls and review them at the level of downstream impact, not role labels.

Key terms

• Privilege Escalation Primitive: An action that lets a limited identity expand its authority without first becoming a new user or role. In cloud IAM, these are permissions that rewrite trust, attach policy, assume roles, or expose secrets, turning a small foothold into broader control.
• Identity Blast Radius: The amount of damage a compromised identity can cause once its permissions are abused. It is measured by downstream reach, not by the number of roles attached. In cloud environments, a single high-risk API can create a much larger blast radius than many low-risk permissions.
• Governance Escape Hatch: A privileged action that allows an identity to remove oversight, logging, or central policy enforcement. These controls matter because they let an attacker or insider operate outside the mechanisms that prove accountability and constrain access.
• Trust Chain: The sequence of permissions and delegated roles that determines how one identity can inherit another identity's authority. In practice, the trust chain is where cloud access risk compounds, because a narrow permission can open access far beyond the original role boundary.

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 NHI governance in your organisation, it is worth exploring.

This post draws on content published by Sonrai Security: Privileged AWS permissions you should restrict immediately (Top 25 + bonus). Read the original.