Topic starter
25/06/2026 1:05 am
TL;DR: July 2025 AWS service updates introduced new privileged permissions across Bedrock AgentCore, SageMaker, Oracle Database@AWS, VPC Lattice, and security tooling, creating fresh paths for privilege escalation, lateral movement, persistence, and defence evasion, according to Sonrai Security. The governance problem is not the new services themselves but the way cloud access boundaries expand faster than review, scope, and control models can keep up.
Editorial analysis by NHI Mgmt Group, based on content published by Sonrai Security: “July Recap: New AWS Services and Privileged Permissions”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: New AWS permissions can quietly enlarge the scope of existing cloud identities even when the underlying accounts do not change.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 10:16 am
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.
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: 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.
👉 Read our full editorial: New AWS privileged permissions are widening cloud access risk