Notifications
Clear all
Topic starter
25/06/2026 12:25 am
TL;DR: New AWS permissions across OpenSearch Ingestion, Aurora DSQL, QuickSight, ARC Region Switch, and RTB Fabric can alter logging, escalation, and workflow controls in ways that quietly expand cloud attack paths, according to Sonrai Security’s October 2025 analysis. The lesson is clear: privilege growth is a governance problem, not just a permissions problem.
NHIMG editorial — based on content published by Sonrai Security: Oct Recap: New AWS Privileged Permissions
By the numbers:
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes , and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: How should security teams govern new cloud permissions as AWS services expand?
A: Security teams should review every new permission for its effect on data movement, policy enforcement, logging, and automation before it is folded into existing roles.
Q: Why are permissions that affect logging and connectors so risky in cloud environments?
A: Because they can hide activity without needing to steal data directly.
Q: What do IAM teams get wrong about least privilege in cloud platforms?
A: They often classify privilege by service name instead of by what the permission can change.
Practitioner guidance
- Review new AWS actions as privilege changes, not feature additions Map each new permission to its effect on data flow, access scope, logging, and automation before assigning it to any production role.
- Separate visibility permissions from ordinary service administration Treat actions that modify resource policies, log pipelines, or alert connectors as privileged access with independent approval and monitoring.
- Re-baseline least privilege after every platform expansion When AWS introduces a new service or new API action, run a role recertification against the changed permission set and remove inherited access that no longer matches actual duties.
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 new AWS actions and the control effects they create across OpenSearch Ingestion, Aurora DSQL, QuickSight, ARC Region Switch, and RTB Fabric
- MITRE ATT&CK mapping for each privileged action, useful if you are aligning cloud permissions to threat modelling or detection coverage
- Service-specific examples of how logging, alerting, and policy controls can be weakened through seemingly routine API permissions
- Sonrai Security's rationale for why each permission belongs in a privileged access review rather than a standard admin role
👉 Read Sonrai Security's analysis of new AWS privileged permissions and cloud risk →
AWS privileged permissions: what cloud teams need to watch?
Explore further
25/06/2026 9:19 am
Cloud privilege sprawl is now a control-boundary problem, not a service-by-service hygiene issue. Sonrai’s analysis shows that new AWS actions can reshape data ingress, policy enforcement, and alerting in one change set. That means IAM teams are no longer governing only who can administer a service, but what that service is allowed to become inside the operating model. The practitioner conclusion is that permission review must move closer to effective risk, not service labels.
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 agree identity management must fundamentally shift to address agentic AI systems, according to The 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: Who should approve permissions that can change automation plans or alerting paths?
A: Those permissions should sit in a separate governance path from day-to-day administration, with explicit owner review from IAM, cloud platform, and security operations. If a permission can change an executable plan or suppress alerting, it belongs in a higher-trust class than routine operator access.
👉 Read our full editorial: AWS privilege expansion is quietly widening cloud attack paths
