Notifications
Clear all
Topic starter
24/06/2026 10:33 pm
TL;DR: March 2026 AWS permission additions expand privileged reach across customer engagement, AI-driven DevOps automation, and database replication, with Sonrai Security warning that the main risk is silent degradation rather than obvious disruption. The editorial conclusion is that reactive detection is not enough when permissions can quietly disable alerts, redirect objectives, or copy data continuously.
NHIMG editorial — based on content published by Sonrai Security: March Recap: New AWS Privileged Permissions and Services
Questions worth separating out
Q: How should security teams review cloud permissions that can silently change system behaviour?
A: They should review them by operational effect, not just service ownership.
A: Because machine identities often hold permissions that influence monitoring, automation, and replication at the same time.
Q: What breaks when AI-driven DevOps permissions can change an agent's goal?
A: The control assumption that automation behaviour is stable enough to govern through ordinary access review.
Practitioner guidance
- Review privileged permissions by operational effect Classify new cloud permissions according to what they can silently change, such as alerting, automation goals, or data replication, then route them for approval before deployment.
- Place AI automation goals under entitlement control Treat permissions that can update agent objectives as sensitive NHI entitlements.
- Separate replication rights from standard database access Move multi-account or cross-environment replication privileges into a restricted review path with business justification, because continuous sync can function as covert data movement even when the source system remains healthy.
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 March AWS changes and why each one is privileged.
- The service-specific impact analysis for Amazon Connect, AWS DevOps Agent Service, and DynamoDB.
- The MITRE ATT&CK mapping Sonrai Security used to classify the risk of each permission.
- How Sonrai Security's Cloud Permissions Firewall tracks newly released permissions before they are abused.
👉 Read Sonrai Security's March recap on new AWS privileged permissions →
Silent degradation in AWS permissions: what IAM teams missed?
Explore further
25/06/2026 7:16 am
Silent degradation is the right concept for cloud privilege risk when the system keeps working after control has already failed. The March AWS changes show that the most damaging permissions are often those that suppress observability, alter automation intent, or enable continuous data movement without obvious errors. That means security teams can be blind to compromise until the business impact is already established. Practitioners should evaluate privilege by operational effect, not by whether the action looks destructive at the point of execution.
A few things that frame the scale:
- Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems, according to the 2026 Infrastructure Identity Survey.
- 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, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: Who should approve permissions that can suppress alerts or copy data across accounts?
A: They should be approved by the owners of the control plane they affect, not just by the service team. Permissions that disable notification paths or create continuous replication change detection and data governance outcomes, so they need IAM, PAM, and security oversight together. The right question is whether the organisation is willing to let that control exist at all.
👉 Read our full editorial: March AWS privilege changes expose silent degradation risk
