AWS permission changes expose new cloud privilege attack paths

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Sonrai Security's blog post: New privileged actions in EC2, AWS Backup, Security Hub and Bedrock can undermine trust boundaries and automation controls.

Why it matters: It matters because cloud IAM teams need to treat new permissions as governance events, not just service updates, when restore workflows, security automation and model creation are exposed to privilege drift.

Context

AWS permission changes are not just feature additions. In cloud IAM, each new privileged action can expand who can alter security boundaries, redirect workflows, or influence recovery paths before governance teams have time to re-baseline access.

This article focuses on how June 2025 AWS service updates affect least privilege, privileged access management, and cloud workload governance. The issue is not the existence of new services, but the creation of new control points that can be abused if permissions are not re-scoped quickly.

For identity programmes, the practical question is whether permission review processes are tuned to cloud release velocity. When restore approvals, connectors, automation rules and model creation all gain new authority, standing privilege becomes harder to justify and easier to exploit.

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 service-level permissions increase cloud risk?

A: Service-level permissions increase risk because they can change behaviour inside the control plane without using a traditional administrator path. That means a seemingly small entitlement can redirect logs, loosen trust, or expand execution scope, creating disproportionate impact from ordinary operational access.

Q: What are the signs that privileged cloud permissions are expanding too fast?

A: Watch for new API actions that alter identity, access or recovery state, especially when they appear in services that are not traditionally treated as IAM tools. Another warning sign is when deny policy support arrives after the permission already exists, because that usually means the governance surface has just widened.

Q: How should teams govern permissions that can change recovery or detection workflows?

A: Teams should place workflow-changing permissions under separate ownership, review them as privileged access and require explicit business justification for every identity that can alter approvals, automation or integration settings. The control objective is to keep process authority from hiding inside ordinary cloud administration.

Technical breakdown

Why new AWS permissions create privilege drift

Cloud privilege drift happens when a service adds actions faster than organisations can revise role boundaries, approval paths and exception handling. A new permission may look narrow, but if it controls restore approval, connector registration or security workflow mutation, it becomes a governance control point rather than a simple API action. In practice, the risk is not only misuse by an administrator. It is that inherited roles, automation identities and delegated service permissions keep carrying authority that no longer matches the current service behaviour. That mismatch creates a widening attack surface even when no account is obviously over-privileged.

Practical implication: Review new cloud permissions as governance changes and re-evaluate every role or automation identity that can invoke them.

How restore approvals and automation rules become attack paths

AWS Backup and Security Hub updates illustrate a common cloud pattern: control-plane permissions can affect downstream security decisions without touching the protected data directly. If an identity can disassociate a backup approval team, update an automation rule, or disable the workflow entirely, it can shape whether recovery or response ever happens. That is privilege escalation by process control, not by raw data access. The security problem is that operational trust is being enforced by permissions scattered across multiple services, which makes it easy to miss how a small action changes the end-state of recovery or incident handling.

Practical implication: Separate workflow-control permissions from routine operator access and monitor them as high-risk entitlements.

Why Bedrock and security tooling permissions matter together

The addition of model-creation and connector-management permissions shows that identity risk now spans cloud operations, security operations and AI-adjacent services. A permission that creates a custom model can affect downstream behaviour, while a connector update can redirect findings or break the link between detection and response. These are not isolated product updates. They reveal a broader cloud governance problem where one service can modify another service's assurance pipeline. The result is a larger trust boundary that needs explicit review across platform, security and AI governance teams.

Practical implication: Map cross-service permissions to the business process they control, not just the service that owns them.

Threat narrative

Attacker objective: The objective is to change security outcomes by abusing newly exposed cloud permissions rather than by stealing data directly.

1. Entry occurs through legitimate cloud permissions that are newly introduced or expanded in AWS services and then assigned into existing roles or automation paths.
2. Escalation happens when an identity uses backup, Security Hub or Bedrock permissions to alter approval workflows, automation rules or model creation authority.
3. Impact follows when restore checks are bypassed, security findings are redirected or disabled, and service boundaries no longer enforce the intended control state.

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 release-management problem, not just an IAM problem: when AWS adds privileged actions inside existing services, the governance burden shifts to proving that inherited roles still match current behaviour. That makes release cadence part of the access-control boundary. Teams that review permissions only on a fixed cycle will always trail the service changes that redefine privilege.

Workflow-control permissions are the new high-risk entitlements: backup approval teams, security automation rules and connector registrations are not operational conveniences, they are control points. When an identity can redirect or disable those controls, the trust model breaks at the process layer before it breaks at the data layer. Practitioners should classify these permissions with the same seriousness as direct data-access rights.

Cross-service authority creates a cloud trust boundary that traditional least privilege often misses: a permission in one service can change the integrity of recovery, detection or AI-adjacent workflows in another. That means cloud IAM, SecOps and platform teams need a shared entitlement model for actions that modify security outcomes. The practical conclusion is to govern process-changing permissions as a separate privilege class.

Privilege is now distributed across the control plane, so visibility alone is not enough: knowing that a permission exists does not explain what operational decision it can override. Sonrai Security's June recap reflects a category-wide shift where small permission deltas can have large governance effects. Security teams should treat each new high-impact action as a signal to revisit ownership, approval and revocation boundaries.

Identity blast radius is the right lens for cloud service updates: the meaningful question is not whether a permission is rare, but how far its effect propagates across approvals, automation and response chains. When a single entitlement can change recovery or detection behaviour, the blast radius extends beyond the service that exposed it. That should drive stricter review thresholds for cloud privilege changes.

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: Agentic AI Identity Guide

What this signals

Cloud service updates now need entitlement impact review: the real control question is whether a new permission can change a workflow, not whether it sits inside a familiar service. IAM teams should add release-driven privilege review to their cloud governance model so entitlement changes are assessed before they enter standard roles.

Identity blast radius should be a separate cloud governance metric: permissions that can alter backup approval, automation or connector integrity should be tracked by how far their effects propagate across operational boundaries. That gives security and platform teams a practical way to prioritise the privileges that matter most.

AWS permission changes can reshape trust boundaries faster than quarterly access reviews can react. Teams that manage cloud IAM, PAM and security operations need a process for reclassifying new service actions as soon as they appear, especially when they influence recovery or incident response.

For practitioners

• Classify new cloud permissions by control impact Map each new AWS action to the business control it can change, such as restore approval, connector integrity or automation rules, before allowing it into standard roles.
• Re-scope roles after each AWS service update Revalidate IAM roles and automation identities whenever AWS adds or changes privileged service actions, because inherited permissions can outlive the original service design.
• Treat backup approvals as privileged access Move backup vault approval changes into a privileged-access workflow with explicit ownership, separation of duties and review of every identity that can alter the approval team.
• Monitor security workflow mutations as high-risk events Alert on connector updates, automation-rule changes and service disablement actions in Security Hub so that detection and response paths cannot be silently redirected.
• Review AI-adjacent service permissions separately Evaluate model-creation and connector-management rights on their own, because they can influence downstream behaviour and assurance pipelines in ways normal platform roles do not capture.

Key takeaways

• AWS service updates can create new attack paths when privileged permissions are added faster than roles and approvals are re-evaluated.
• The most consequential permissions are the ones that change recovery, response or connector integrity rather than those that simply expose more data.
• Cloud IAM teams need to treat control-plane changes as entitlement events and review them through a privileged access lens.

Key terms

• Cloud Privilege: Cloud privilege is the set of actions an identity can perform through permissions in a cloud environment. It is defined by role assignments, policies, and inherited entitlements rather than by a single administrator account, which makes governance dependent on continuous review of effective access.
• Workflow-Control Permission: A workflow-control permission is an entitlement that changes how security or operational processes behave rather than directly reading or writing data. In cloud environments, these permissions can alter approvals, automation rules, integration routing or recovery handling.
• 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 how a service behaves, not just what data it stores. For cloud IAM teams, it is the authority to mutate approvals, connectors, policies or security workflows that govern downstream operations.

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.