New AWS privileged permissions are widening cloud access risk

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Sonrai Security's blog post: July AWS service updates introduced privileged permissions that widen access boundaries and create fresh escalation paths.

Why it matters: Cloud IAM teams need to treat new service permissions as governance events, because service expansion can silently widen effective privilege and weaken least-privilege boundaries across cloud programmes.

Context

AWS service launches often arrive with new permissions that expand what an identity can do inside a cloud environment. In this case, the security issue is not the presence of new services themselves, but the way newly exposed actions can shift privilege boundaries faster than IAM review cycles can absorb.

For cloud IAM, PAM, and workload-identity teams, that creates a recurring governance gap: entitlement catalogues, role design, and control testing lag behind the platform's pace of change. The result is a moving target where least privilege is defined by yesterday's service map.

The article's core subject is cloud access risk created by newly introduced AWS permissions, and that is a typical cloud governance problem rather than an edge case.

Key questions

Q: What breaks when new cloud service permissions are added without a role review?

A: Least privilege becomes stale as soon as the new action lands, because existing roles can suddenly control execution, routing, or security boundaries that were never in scope when the role was designed. That creates hidden escalation paths even when no new accounts are created.

Q: Why do new sensitive cloud permissions increase the risk of lateral movement and defense evasion?

A: New sensitive permissions often expand the set of actions an identity can take without changing its user-facing role. That creates hidden paths for disabling monitoring, altering network exposure, or widening access between services. When permissions are not tightly scoped, attackers or insiders can use legitimate APIs to move laterally, evade detection, or maintain persistence.

Q: How do security teams know whether least privilege is actually working?

A: Least privilege is working when identities have narrowly scoped permissions, unused credentials are removed or quarantined, and repeated access reviews consistently shrink entitlements. A good signal is whether a compromised identity would be unable to move beyond one bounded workflow. If broad resource reach still exists, the control is not effective.

Q: What should teams do when a cloud permission can change firewall, gateway, or scan settings?

A: Treat that permission as a boundary-changing control, not a routine admin right. Those actions can weaken detection, alter enforcement, or redirect traffic, so they need stricter approval paths, logging, and periodic reassessment than ordinary operational permissions.

Technical breakdown

Why new AWS permissions become privilege escalation paths

Cloud services do not only add features. They add new authorization verbs, and each verb can change what an already-trusted identity can reach, modify, or delegate. In IAM terms, that means the risk is often not a new account but a new action attached to an existing role. When a permission can create runtimes, alter gateways, or update network policies, the control problem becomes scope control, not just account control. The technical issue is that cloud services frequently bundle operational convenience with high-impact side effects, so a single new action may grant more effective authority than its name suggests.

Practical implication: Treat newly released service permissions as escalation candidates and review them before attaching them to production roles.

How Bedrock AgentCore and SageMaker permissions change execution boundaries

The Bedrock AgentCore and SageMaker examples show how cloud permissions can move beyond infrastructure administration into execution control. A permission that creates an agent runtime, starts a remote session, or generates presigned access to model artefacts does not merely configure a service. It can create a persistence path, a code-execution path, or a data-exposure path depending on how the role is scoped. In practice, these are identity decisions disguised as platform features. That is why AI and ML services need the same privilege scrutiny as classic admin surfaces, especially where execution roles and external content access are involved.

Practical implication: Model AI and ML service permissions as execution-risk entitlements, then separate deployment authority from data-access authority.

Why networking and security-service permissions matter for cloud defence

Permissions in Oracle Database@AWS, VPC Lattice, Network Firewall, and security tooling show that lateral movement and defence evasion often begin with administrative-looking actions. Creating peer connections, associating services, modifying firewall protection, or updating scan configurations can alter the shape of the security boundary itself. That makes these permissions high-value even when they do not look like traditional data-access rights. For cloud security, the key architectural lesson is that control-plane permissions are also attack-plane permissions whenever they can reshape routing, inspection, or detection.

Practical implication: Apply tighter approval and monitoring to control-plane actions that can change routing, inspection, or security coverage.

Threat narrative

Attacker objective: The objective is to turn newly granted cloud service permissions into broader execution, movement, or evasion capability inside the environment.

1. Entry occurs when an identity already holding broad cloud permissions reaches a newly exposed service action that was not covered by the original role review.
2. Escalation follows when that action is used to create execution paths, expand gateway targets, alter network controls, or modify access policies beyond the intended scope.
3. Impact arrives when those changes enable persistent access, lateral movement, or defence evasion across cloud services and security tooling.

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 risk now starts at service release time, not only at account creation time. The article shows that new AWS permissions can change the effective power of existing identities as soon as they appear. That means cloud governance is no longer just about provisioning and review cadence, but about continuously tracking the privilege impact of platform change itself. Practitioners should treat release notes as access-control inputs, not product news.

Control-plane permissions have become security-boundary permissions. Actions that update gateways, peer networks, modify firewall coverage, or alter scan configurations can change both exposure and detectability. This widens the gap between what teams think a role can do and what it can actually influence across routing, inspection, and enforcement layers. The practitioner takeaway is that cloud IAM and cloud security operations now share the same blast radius.

Privilege creep in cloud programmes is increasingly a service-design problem. The permissions described in the article are not isolated exceptions. They reflect a broader pattern in which every new managed service ships with fresh administrative verbs that can bypass older least-privilege assumptions. That is why the right governance unit is the service action, not just the role name or the resource type.

Identity blast radius is the right named concept for this risk. A new permission can increase the number of downstream systems, datasets, and control paths an identity can affect without changing the identity itself. In cloud environments, blast radius expands through control-plane reach as much as through data access. Teams should measure and govern that radius as a first-class access-security metric.

Cloud access governance must move from static entitlement review to release-aware authorization governance. This is where traditional quarterly access review fails to keep pace with an environment whose high-risk actions are being redefined continuously. The implication for practitioners is not just tighter review, but a governance model that tracks newly introduced service verbs as part of ongoing entitlement risk.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• 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 teams should now measure how far a single role can reach across execution, routing, inspection, and data access. New service permissions expand that radius faster than annual or quarterly entitlement review can absorb, so release-aware governance becomes part of access control.

The practical shift is to treat platform change as an authorization event. When AWS introduces new verbs, cloud IAM and PAM teams need to test whether those verbs create new control-plane authority, because control-plane authority is often the shortest path to persistence, lateral movement, or security evasion.

For practitioners

• Map new service actions to privilege tiers Classify newly introduced AWS permissions by whether they create execution, movement, policy-change, or monitoring-impact risk before they are added to roles.
• Separate deployment from data-access authority Do not let the same role both deploy runtimes and reach sensitive artefacts, especially in AI and database services where execution and access can collapse into one permission set.
• Review control-plane permissions as security controls Treat firewall, gateway, peering, and scan-management actions as control-boundary changes and require the same scrutiny you apply to direct data-access entitlements.
• Continuously rebaseline least-privilege roles Recheck high-privilege cloud roles whenever AWS adds new service verbs so that yesterday's safe scope does not become today's escalation path.

Key takeaways

• New AWS permissions can quietly enlarge the scope of existing cloud identities even when the underlying accounts do not change.
• The risk is not limited to data access. Execution, routing, and security-control permissions can all become escalation paths.
• Cloud teams need release-aware authorization governance so new service verbs are reviewed before they are absorbed into privileged roles.

Key terms

• Control-plane permission: A control-plane permission is an action that changes how a cloud platform governs access, identity, or resilience rather than just reading data. These permissions matter because they can alter policy, authentication, or recovery behavior, creating outsized security impact if granted too broadly.
• 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.
• Control-Plane Authority: Control-plane authority is the power to change infrastructure, access paths, or protective settings rather than simply consume a service. It matters because these permissions can redirect traffic, weaken inspection, or expand execution scope, which makes them a primary target for privilege reviews and detection design.
• Release-Aware Authorization: Release-aware authorization is the practice of reassessing entitlements whenever a platform introduces new actions, APIs, or service features that can alter access risk. For cloud programmes, it means treating service releases as governance triggers, not waiting for periodic recertification cycles to catch up.

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.