Topic starter
25/06/2026 1:15 am
TL;DR: AWS June 2025 service updates added new privileged permissions across EC2, AWS Backup, Security Hub, and Bedrock that can alter restore approvals, connector integrity, automation rules, and security boundaries, according to Sonrai Security. The pattern is a widening cloud privilege surface where small permission changes can undermine trust boundaries faster than traditional review cycles can catch them.
Editorial analysis by NHI Mgmt Group, based on content published by Sonrai Security: “June Recap: New AWS Services and Privileged Permissions”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: AWS service updates can create new attack paths when privileged permissions are added faster than roles and approvals are re-evaluated.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 10:33 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: AWS permission changes expose new cloud privilege attack paths