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.
Editorial analysis by NHI Mgmt Group, based on content published by Sonrai Security: “Dec Recap: New AWS Privileged Permissions and Services”.
Key questions
Q: What breaks when cloud permissions can change service behaviour after deployment?
A: The assumption that authority is fixed at provisioning breaks down.
Q: Why does telemetry access need privileged access controls?
A: Telemetry often contains sensitive operational detail, investigative evidence, and data that can expose systems at scale.
Q: Where does least privilege fail in modern cloud service accounts?
A: It fails when service identities receive permissions that are small on paper but large in effect, such as changing trust stores, modifying deployments or enabling cross-service data movement.
Practitioner guidance
- Classify service-level actions by blast radius Build permission reviews around the operational effect of each AWS action, especially when a single call can redirect logs, alter deployments or widen trust.
- Separate mutation rights from creation rights Treat update permissions on deployed services, trust stores, pipelines and agents as privileged functions, not as ordinary operator permissions.
- Put observability permissions under privileged access review Review who can create, modify or delete scheduled queries, telemetry pipelines and log integrations because those actions can conceal activity or move data.
Bottom line: Cloud privilege is expanding inside ordinary AWS services, not just in administrator roles, and that shifts attention to the effect of each permission.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 8:18 am
Blast-radius control is now the core cloud IAM design problem. Sonrai Security’s review shows that privilege is increasingly embedded in service actions rather than only in IAM administrator roles. That changes the unit of governance from user accounts to operational capabilities, especially where a single permission can redirect logs, alter execution or expand network reach. Practitioners should judge cloud IAM by the maximum effect of each action, not by the label attached to the service.
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 decide which AWS permissions are truly privileged?
A: Prioritise permissions that can change trust, execution, visibility or data destination, even when they belong to managed services rather than admin consoles. If an action can redirect logs, alter a running deployment or expand who can reach a resource, it should be treated as privileged access.
👉 Read our full editorial: AWS permission sprawl is widening the cloud blast radius