AWS privileged permissions are expanding the cloud attack surface

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Sonrai Security's blog post: Sonrai Security tracks August AWS permission changes that expand what privileged identities can do across data, monitoring, sessions, and workload execution.

Why it matters: IAM and PAM teams need to treat cloud service permissions as a living attack surface because new privileges can quickly alter exfiltration, detection, and persistence boundaries.

Context

Cloud privilege expansion is the steady growth of what service permissions can do inside managed cloud services. In AWS, that matters because a new action can change data exposure, monitoring visibility, session controls, or execution rights without any new account being created.

For IAM and PAM programmes, the governance problem is not just who has access. It is also which newly published service actions now behave like privileged access and therefore need review, classification, and lifecycle control.

Sonrai Security's August roundup is a typical example of this cloud drift: the permissions are service-specific, but the security consequences land on identity governance, detection, and privilege boundaries.

Key questions

Q: What breaks when AWS adds privileged permissions faster than IAM teams can review them?

A: Least privilege stops reflecting the current platform. Roles may still look correct on paper, but new service actions can change encryption, access scope, detection settings, or workload exposure without any governance update. The result is entitlement drift, where access reviews certify an outdated model rather than the live cloud permission set.

Q: Why do newly added cloud permissions often create hidden privilege risk in mature environments?

A: New permissions often bypass existing review habits because teams focus on services, not the actions hidden inside them. A permission that looks administrative can quietly enable exfiltration, policy changes, or encryption downgrades. Mature environments are especially exposed when security depends on periodic audits instead of continuous permission governance across accounts, workloads, and shared services.

Q: What are the signs that cloud resource governance is failing?

A: Common signs include unexpected cost spikes, resources being enlarged without review, new assets appearing outside approved procedures, and engineers not knowing the financial impact of what they deploy. If teams cannot explain what should be running or in what configuration, governance is already weak. These symptoms usually show up before the monthly bill makes the problem obvious.

Q: How should teams respond when cloud services expand privileged permissions?

A: They should reclassify the new actions, update access reviews, and decide whether those permissions belong in standard roles at all. If a permission can change data scope, trust duration, or observability, it should be treated as privileged from day one. The question is not whether it is convenient, but whether it is governable.

Technical breakdown

How new AWS actions become privileged permissions

Cloud platforms frequently add fine-grained actions that look operational but function as high-risk entitlements. A permission becomes privileged when it can alter data scope, bypass monitoring, extend trust, or trigger code execution. In this article, examples include Clean Rooms actions that change table references and allowed columns, SES actions that shift sending authority, and WorkSpaces or SSO actions that affect session trust. The technical issue is not the service name itself, but the effect of the action on confidentiality, integrity, or control plane boundaries.

Practical implication: Treat newly released cloud actions as candidate privileged entitlements and classify them before they enter production roles.

Why monitoring and session controls are identity controls

Permissions that delete or update telemetry rules, disassociate session loggers, or create root client certificates are identity controls because they shape what can be observed and how long access survives. Once logging can be disabled or session limits can be bypassed, the environment no longer provides reliable evidence of use. That changes the meaning of PAM in cloud settings: it is not only about blocking admin rights, but also about preserving the signals needed to detect misuse and enforce revocation. Detection failure often follows control-plane entitlement growth.

Practical implication: Review observability and session-related permissions as part of PAM and logging governance, not as separate platform hygiene.

Why execution and persistence permissions widen cloud attack surface

Permissions such as Batch job submission, re:Post role assignment, Directory Service hybrid directory creation, and WorkSpaces image import can create execution or persistence paths that outlive a normal access decision. These actions may not look like classic admin rights, yet they let an identity run code, establish trusted presence, or shape downstream identity sources. In practice, attack surface expands when a permission can create durable effect rather than perform a one-off task. That is why cloud privilege review has to focus on what an action enables after the API call completes.

Practical implication: Map durable side effects from each permission so you can separate routine operations from entitlements that create persistent control.

Threat narrative

Attacker objective: The objective is to convert ordinary service permissions into broader access, weaker visibility, or persistent control over cloud resources.

1. Entry occurs through a legitimate cloud identity that already has permission to call newly introduced AWS actions.
2. Escalation follows when that identity uses an action that changes data access, telemetry, session limits, or workload execution scope beyond its intended task.
3. Impact emerges through data exposure, reduced detection visibility, longer-lived access, or arbitrary workload execution that broadens the attack surface.

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

Cloud privilege drift is now a governance problem, not a release-note problem. AWS keeps adding actions that alter data access, logging, trust duration, and workload execution, and those changes can silently reclassify ordinary permissions into privileged ones. IAM and PAM programmes that only review roles at creation time will miss the real risk window, because the entitlement meaning changes after deployment. The practitioner conclusion is simple: permission review must track platform change velocity, not just role assignment.

Identity blast radius is the right concept for AWS privilege growth. A permission that changes table references, session configuration, telemetry rules, or trusted devices does not just grant access, it changes how far an identity can reach if misused. That is why the security question is no longer whether a role is broadly privileged in theory, but how much irreversible effect a single action can create. Practitioners should measure blast radius per action, not per role.

Monitoring bypass and access persistence are privileged outcomes in their own right. Permissions that silence logs, alter telemetry, or extend sessions weaken the evidence base that identity teams rely on for investigation and enforcement. When observability and session duration become mutable by the same identities being governed, PAM and detection can no longer be treated as separate disciplines. The practical conclusion is that logging and session boundaries must be governed as access controls.

Cloud service expansion keeps turning least privilege into a moving target. The important shift here is not that AWS is unusual, but that platform evolution continually produces new privilege edges faster than organisations update entitlement catalogs. Sonrai Security's roundup shows why mature programmes need a continuous mapping between cloud service releases and access policy scope. The practitioner conclusion is to govern newly published actions as if they were new admin capabilities until proven otherwise.

From our research library:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
• Read next: Top 10 Agentic AI Identity Issues

What this signals

Identity blast radius: cloud programmes need a way to measure how much damage a single permission can cause after the API call completes. When a permission can redirect data, weaken monitoring, or extend trust, the unit of review is the effect on the environment, not the service label.

AWS privilege growth also exposes a gap between entitlement inventory and platform release cadence. Teams that only recertify roles on a calendar will miss newly added actions that materially change access scope, so governance has to move toward continuous permission classification and review.

For practitioners

• Review newly published cloud actions weekly Compare each new AWS service action against your privileged access catalog and flag any permission that can alter data scope, monitoring, sessions, or execution.
• Classify session and logging permissions as privileged Treat telemetry rule changes, session logger changes, and certificate-based trust changes as PAM-relevant entitlements rather than ordinary admin operations.
• Map durable side effects for each permission Document whether a permission can persist access, redirect data, weaken observability, or create workload execution rights after the call completes.
• Reconcile role design with changing service APIs Re-certify roles whenever cloud providers add actions that expand the authority of existing identities, especially in data and identity services.
• Separate operational access from privileged access Build review criteria that distinguish routine service use from actions that can change security boundaries, even when both live in the same service namespace.

Key takeaways

• AWS permission growth can turn ordinary service actions into privileged access paths that change data, monitoring, and execution boundaries.
• The core risk is not abstract privilege inflation. It is that one new action can create broader access or weaker visibility before governance catches up.
• IAM and PAM teams should continuously classify newly published cloud actions and re-certify roles when their effect on the environment changes.

Key terms

• Privileged Cloud Permission: A privileged cloud permission is an access right that can change infrastructure, create workloads, or alter security-relevant settings. These rights matter because they sit at the control-plane layer, where one compromised identity can create disproportionate impact if the permission is always available.
• 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.
• Telemetry Control Plane: The telemetry control plane is the layer that decides what security data is collected, transformed, enriched, and routed before it reaches downstream tools. It is where log governance happens, because the organisation can still shape quality, volume, and destination before paying ingestion and storage costs.
• Session-boundary Control: Session-boundary control is the practice of limiting what can happen inside an already authenticated session. In AI-assisted browsing, it means using lock states, confirmation prompts, and domain matching to keep assistant-driven actions inside deterministic limits rather than relying on the model to judge intent.

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.