AWS privileged permissions: what cloud teams need to watch

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

View Full Forum →  |  NHI Foundation Course →