Notifications
Clear all
Topic starter
09/06/2026 11:00 pm
TL;DR: May’s new AWS permissions create a consistent infrastructure hijacking pattern, where permissions can redirect workloads, extend attacker-controlled networks, or destroy operational resources across ECS, Omics, and external AI services, according to Sonrai Security. The security model is shifting from individual permission review to controlling permission combinations that can seize fleet-wide execution.
NHIMG editorial — based on content published by Sonrai Security: May recap on new AWS privileged permissions and infrastructure hijacking
Questions worth separating out
Q: What breaks when cloud identities can create, update, and delete the same workload service?
A: When one identity can create, update, and delete the same workload service, least privilege stops being a meaningful control.
Q: Why do privileged cloud permissions increase infrastructure hijacking risk?
A: Privileged cloud permissions increase infrastructure hijacking risk because they can change where workloads run, how traffic moves, and which runtime is trusted.
Q: How do security teams decide which cloud permissions need extra control?
A: Security teams should prioritise permissions that can redirect execution, expand network reach, or destroy operational state.
Practitioner guidance
- Map permission combinations, not just individual permissions. Build reviews that identify identities holding create, update, and delete rights over the same service or cluster, because the dangerous state is often the combination.
- Separate deployment, modification, and teardown authority. Ensure no single NHI or service role can register workloads, alter them in place, and delete the supporting daemon or workspace.
- Classify destructive actions by effect, not by label. Treat actions such as archive, reset, reconfigure, or recreate as potentially destructive until you confirm whether they can remove sessions, vaults, agents, or logs.
What's in the full article
Sonrai Security's full blog post covers the operational detail this post intentionally leaves for the source:
- The per-permission breakdown for AWS ECS, EC2, Omics, and external AI platform actions that broaden the attack surface.
- Sonrai Security's MITRE ATT&CK mapping for each new permission, useful for control validation and monitoring design.
- The specific reasoning behind why certain permissions are privileged even when their names appear administrative rather than destructive.
- The context behind the Cloud Permissions Firewall approach and how Sonrai Security positions detection and control of newly released permissions.
👉 Read Sonrai Security's recap of May AWS privileged permissions and infrastructure hijacking →
AWS privilege expansion and cloud hijacking risk for IAM teams?
Explore further
10/06/2026 1:11 am
Infrastructure hijacking is the right lens for this permission pattern. Sonrai’s recap shows that modern cloud privilege is no longer only about data access. Permissions can now redirect compute, alter network paths, and terminate observability across a fleet, which means the attack surface is the infrastructure itself. The practitioner implication is that cloud identity controls must be designed around control-plane consequences, not just resource access.
A few things that frame the scale:
- 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to The 2026 Infrastructure Identity Survey.
- Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption.
A question worth separating out:
Q: What is the difference between destructive cloud actions and routine administrative actions?
A: Destructive cloud actions change or remove the operational state that other controls depend on, including sessions, agents, tasks, logs, and workspaces. Routine administrative actions adjust configuration without eliminating the control plane itself. The practical difference is blast radius, not wording, and identity governance should classify permissions accordingly.
👉 Read our full editorial: AWS privileged permissions are widening the cloud hijack surface
