Notifications
Clear all
Topic starter
24/06/2026 11:26 pm
TL;DR: AWS added privileged permissions across identity, observability, containers, AI, and networking in December, with many new actions able to redirect logs, alter deployments, or expand execution scope, according to Sonrai Security. The result is a larger, more distributed cloud attack surface that makes least privilege harder to enforce at the service level.
NHIMG editorial — based on content published by Sonrai Security: Dec Recap on new AWS privileged permissions and services
Questions worth separating out
Q: How should security teams govern new cloud service permissions?
A: Security teams should treat new cloud service permissions as privileged access from day one.
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 breaks when observability permissions are over-granted?
A: When observability permissions are over-granted, attackers or insiders can disable logging, delete telemetry pipelines, or reroute data before defenders notice.
Practitioner guidance
- Classify service actions as privileged access Review newly introduced cloud permissions for their effect on logs, trust, execution, and network paths, then place them into the same governance queue as admin entitlements.
- Separate observability from routine operations Treat permissions that create, update, delete, or reroute telemetry as high-risk controls because they can remove evidence while the system remains technically functional.
- Review AI-adjacent permissions independently Isolate permissions tied to Bedrock, agent services, and workflow execution so they require explicit approval, tighter logging, and separate access recertification.
What's in the full article
Sonrai Security's full blog post covers the operational detail this post intentionally leaves for the source:
- Permission-by-permission breakdown of the newly added AWS actions and the exact services they affect
- MITRE ATT&CK tactic mapping for each permission, useful if you need to align cloud entitlements to threat modelling
- Service-specific descriptions of why each permission is privileged, which is the detail needed for engineering review
- The monthly recap format that helps teams track whether newly released permissions have become standing risk in production
👉 Read Sonrai Security's recap of newly released AWS privileged permissions →
AWS privilege updates: what cloud IAM teams need to watch?
Explore further
25/06/2026 8:18 am
Service-level privilege is now the real cloud governance boundary. The article shows AWS permissions that do not look administrative on paper but still change logging, execution, trust, and network paths. That is the current failure mode for cloud programmes: privilege is being expressed through services, not just roles. Practitioners should stop treating service actions as low-risk by default and govern them as blast-radius controls.
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.
- 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: How do cloud teams decide which permissions need tighter review?
A: Cloud teams should tighten review around permissions that can modify trust stores, model deployments, network paths, log exports, or execution roles. Those are the actions that expand blast radius. If a permission can change the behaviour of a shared service, it belongs in the highest review tier.
👉 Read our full editorial: AWS permission sprawl is widening the cloud blast radius
