Notifications
Clear all
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.
NHIMG editorial — based on content published by Sonrai Security: July recap of new AWS services and privileged permissions
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
What's in the full article
Sonrai Security's full blog post covers the operational detail this post intentionally leaves for the source:
- Service-by-service permission table for the AWS actions introduced in July, including why each one is privileged
- MITRE tactic mapping for each permission, useful when you are translating cloud IAM findings into detection and control work
- Specific examples of how Bedrock AgentCore, SageMaker, and network permissions can be abused in real environments
- The vendor's remediation framing for organisations trying to keep pace with AWS service expansion
👉 Read Sonrai Security's July recap of new AWS privileged permissions →
AWS privileged permissions: what cloud IAM teams need to know?
Explore further
25/06/2026 10:16 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: New AWS privileged permissions are widening cloud access risk
