New AWS privileged permissions are widening cloud access risk

At a glance

What this is: Sonrai Security’s July recap shows how newly introduced AWS permissions can expand cloud access boundaries across AI, database, networking, and security services.

Why it matters: It matters because IAM, PAM, and cloud identity teams need to recognise how new service permissions can create fresh escalation paths before they show up in incident response.

By the numbers:

• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems.
• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.

👉 Read Sonrai Security's July recap of new AWS privileged permissions

Context

AWS service launches often arrive with permissions that are technically valid but operationally risky. In cloud IAM, the problem is not only which service is new, but which actions expand privilege, alter trust boundaries, or enable cross-service movement before governance teams have mapped them.

For IAM, PAM, and workload identity programmes, these permission changes matter because they reshape the blast radius of cloud access. That means security teams need to review permissions as governance events, not as routine release notes, especially when the permissions touch AI runtime execution, storage policies, gateway targets, or network controls.

Key questions

Q: What should security teams do when AWS introduces new privileged permissions?

A: They should treat each new permission as a governance change, not a routine feature update. The first step is to classify whether the action can expand execution, connectivity, or data access. If it can, the permission belongs in privileged review, recertification, and logging before it reaches production roles.

Q: Why do new cloud service permissions create lateral movement risk?

A: Because lateral movement in cloud environments often comes from configuration rights, not stolen passwords. If an identity can create peering connections, update gateway targets, or associate services across networks, it can move through the environment by reshaping trust paths instead of taking over another account.

Q: How should teams govern AI runtime permissions in AWS?

A: Separate the right to deploy an AI runtime from the right to operate or modify it. A runtime that can inherit execution roles, call external tools, or update its own image has a much larger blast radius than the deployment event suggests, so those permissions need distinct approval and monitoring.

Q: How do we know if cloud permissions are exceeding intended privilege?

A: Look for permissions that change topology, encryption control, or security findings without a corresponding business need. If a role can alter gateway targets, network controls, or key association settings, it is already operating beyond a narrow service-account model and should be recertified.

Technical breakdown

Why newly minted AWS permissions matter to cloud IAM

Cloud services rarely fail closed when new permissions appear. Instead, each new action can expose an adjacent control plane, such as storage policies, gateway routing, execution roles, or encrypted data paths. In practice, a permission that looks narrow can become powerful when it interacts with existing trust relationships, inherited roles, or service-linked permissions. That is why cloud IAM teams should treat new AWS actions as changes to the authorization surface, not just as feature releases. The security question is whether a new permission creates a new path to move, persist, execute, or suppress visibility.

Practical implication: review new AWS actions for privilege escalation and lateral movement potential before they are allowed into production roles.

How AI and agent runtimes change the privilege model

Permissions such as creating or updating agent runtimes, code interpreters, or model deployments are different from ordinary infrastructure actions because they can combine execution, data access, and orchestration in one control path. When an AI runtime can start with an execution role, the identity boundary is no longer only about who can call the API. It is also about what the runtime can do once launched, which data it can reach, and whether the permissions let it redirect tools or change its own behaviour. That makes least privilege in AI infrastructure both broader and harder to prove.

Practical implication: separate deployment rights from execution rights and inspect every agent runtime permission for implicit tool or data access.

Cross-service permissions create hidden lateral movement paths

Permissions that associate networks, update gateway targets, or create peering connections are often the most dangerous because they do not look like classic account takeover actions. They instead let a privileged identity reshape how services connect to one another. In cloud environments, lateral movement can happen without new credentials if the actor already holds the right configuration rights. The result is a governance blind spot: security teams may harden identities while leaving network and service association permissions open enough to move between environments.

Practical implication: map service-to-service connectivity permissions into your privileged access reviews, not just human or workload account entitlements.

Threat narrative

Attacker objective: The attacker’s objective is to turn legitimate AWS service permissions into broader control over execution, access, and movement inside the cloud environment.

1. Entry begins when a privileged identity receives new AWS service permissions that can alter execution, networking, or security controls across Bedrock AgentCore, SageMaker, VPC Lattice, and related services.
2. Escalation follows when those permissions are used to create runtimes, update gateway targets, modify network policies, or generate presigned access paths that extend reach beyond the original role boundary.
3. Impact occurs when attackers or misused identities redirect workloads, expand access, suppress detections, or alter encryption and network controls enough to create persistence and control-plane abuse.

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

New cloud permissions are governance events, not just product events. When AWS introduces permissions that can start runtimes, alter gateway targets, or change network policy, the security surface changes before the organisation has re-reviewed roles. That is why cloud identity programmes need to treat every privileged permission release as a review trigger. The practical consequence is that entitlement governance must track service evolution as closely as infrastructure teams do.

Identity blast radius: is the right concept for this class of risk. These permissions do not merely add access, they expand how far a single identity can reach across execution, storage, and connectivity boundaries. The same role that looks harmless in a role review may become powerful once a new AWS action unlocks an adjacent control plane. Practitioners should think in terms of blast radius, not just permission count.

AI runtimes collapse the separation between deployment rights and operational control. Permissions to create or update agent runtimes, code interpreters, or custom model deployments give an identity a route into execution itself. That means traditional infrastructure guardrails are no longer enough when AI services can inherit roles, call tools, and change behaviour at runtime. Cloud teams need to reassess whether their current governance model can still distinguish provisioning from abuse.

Cross-service privilege requires a broader PAM model than many teams have today. Network association, gateway update, and presigned access permissions are privileged even when they do not look like admin actions. This is where cloud PAM needs to encompass configuration authority, not just interactive login or secret use. The implication for practitioners is simple: privileged access reviews must include service topology changes, not only identity changes.

Least privilege in cloud security now depends on change velocity, not only scope. As AWS adds new services and permissions, the risk is that role definitions lag behind the available actions. Controls that worked when a service had fewer capabilities can fail once the same identity is able to manipulate more of the platform. Teams should re-evaluate entitlement review cadence and role design whenever AWS expands the permission model.

From our research:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to The 2026 Infrastructure Identity Survey.
• 67% of security leaders still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to The 2026 Infrastructure Identity Survey.
• For the broader governance pattern behind this risk, see 52 NHI Breaches Analysis for recurring identity failure modes and control gaps.

What this signals

Identity blast radius is becoming the right operating metric for cloud teams. With 70% of organisations already granting AI systems more access than human employees, the issue is no longer whether cloud permissions exist but how far a single identity can move when AWS expands the permission surface. That should push teams to recertify by control impact, not by role label, and to pair cloud IAM with stronger privileged access governance.

AWS permission churn also exposes a programme design problem. Teams that review only login access or secret rotation will miss the configuration rights that actually alter execution paths, network paths, and encryption control. The practical signal is to widen entitlement reviews across service topology changes and align them with the NIST AI Risk Management Framework where AI runtimes are involved.

Cloud privilege is now converging with agentic control. As AI platforms inherit more runtime authority, the distinction between workload identity and operational authority gets thinner. Practitioners should expect future cloud governance to combine least privilege, PAM, and runtime supervision into one review motion rather than three separate programmes.

For practitioners

• Reclassify new AWS actions as privileged by default Review newly introduced service permissions before they reach production roles, with special attention to actions that create runtimes, update gateways, alter policies, or expose presigned access paths.
• Split deployment rights from runtime control Ensure the identity that can deploy an AI service cannot also silently update the runtime image, execution role, or downstream tool targets without separate approval and logging.
• Extend PAM to cloud configuration authority Include network association, peering, gateway, and policy modification permissions in privileged access reviews so service topology changes are governed like admin access.
• Map permissions to blast radius, not role names Score each high-risk AWS action by its ability to change execution, connectivity, or data access, then recertify roles based on that blast radius rather than job title or team ownership.

Key takeaways

• AWS permission changes can create privilege escalation, lateral movement, persistence, and defence evasion even when the underlying service is legitimate.
• AI runtimes and cross-service configuration rights expand blast radius faster than many IAM role models can absorb.
• Cloud teams should govern new permissions as privileged access events and recertify roles based on control impact, not service names.

Key terms

• Cloud Privileged Permission: A cloud action that can change access, execution, connectivity, or security control beyond ordinary operational use. In practice, these permissions matter because they can expand blast radius even when they are attached to a valid, authorised identity.
• Identity Blast Radius: The amount of damage or reach a single identity can create if its permissions are misused or over-scoped. In cloud and AI environments, blast radius is shaped by configuration rights, runtime authority, and service-to-service trust, not just login credentials.
• Runtime Control Plane: The set of permissions and interfaces that let an identity start, modify, or redirect an execution environment after deployment. In AI and cloud infrastructure, runtime control can be more sensitive than provisioning because it influences live behaviour, data access, and downstream tool use.

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: July recap of new AWS services and privileged permissions. Read the original.