Notifications
Clear all
Topic starter
24/06/2026 11:26 pm
TL;DR: Cloud permissions have become a primary cloud attack surface, and Sonrai Security says its Cloud Permissions Firewall drove 4x year-over-year ARR growth, 220% customer growth, and 60% expansion among existing customers, reflecting demand for default-deny and just-in-time controls at the permission layer. Legacy PAM assumptions no longer hold at cloud scale, especially across human, machine, and AI identities.
NHIMG editorial — based on content published by Sonrai Security: Sonrai closes 2025 with 4x ARR growth as Cloud Permissions Firewall adoption surges
By the numbers:
- Sonrai Security reported 4x year-over-year ARR growth, 220% customer growth, and 60% of customers expanded Cloud Permissions Firewall deployments in 2025.
- Sonrai Security said its Cloud Permissions Firewall preventatively blocked 16 of 16 real AWS privilege-escalation attack paths in independent research.
Questions worth separating out
Q: How should security teams govern cloud privileged access in DevOps environments?
A: Security teams should govern cloud privileged access at the permission layer, not only at login or session time.
Q: Why do cloud permissions create more risk than traditional server-era PAM models?
A: Cloud permissions create more risk because they can authorize identity creation, policy changes, data access, and service deployment across highly dynamic environments.
Q: What breaks when standing privilege remains in cloud environments?
A: Standing privilege breaks the assumption that access is only used when needed and only for a narrow task.
Practitioner guidance
- Inventory high-risk cloud permissions by actor type Separate permissions held by humans, service accounts, automation, and AI-assisted workflows so you can see where standing access exists and where task-bound access is missing.
- Move privileged cloud access to task-scoped approval Use just-in-time approval for sensitive cloud actions and enforce the grant at the permission layer, not only through post-access review or ticketing.
- Prioritise permission scopes that can create new blast radius Focus first on roles that can create identities, alter policies, read secrets, or expand access paths, because those permissions turn small errors into large incidents.
What's in the full analysis
Sonrai Security's full article covers the operational detail this post intentionally leaves for the source:
- The product-side explanation of how the Cloud Permissions Firewall enforces default-deny at the permission layer across cloud identities.
- The specific workflow detail behind just-in-time approvals in Slack and Teams for privileged cloud actions.
- The independent research and customer outcome context behind the reported AWS privilege-escalation blocking results.
- The practical deployment scope across AWS, Google Cloud, and the planned Azure support timeline.
👉 Read Sonrai Security’s update on cloud permissions firewall adoption and cloud PAM growth →
Cloud permissions firewall adoption: what IAM teams should change now?
Explore further
25/06/2026 8:19 am
Cloud permissions have become the control plane that legacy PAM never covered. Sonrai Security’s update reflects a broader truth: access in cloud environments is no longer concentrated in a few admin sessions, but distributed across permissions attached to users, workloads, and automation. Legacy PAM was designed around human privileged logins and finite server access, not dynamic cloud permissioning. The practitioner implication is that permission governance now sits at the center of cloud identity security.
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 be accountable for cloud PAM when human, machine, and AI identities all have access?
A: Accountability should sit with the identity and cloud control owners who define permissions, approval policy, and revocation rules across all actor types. Human users, service accounts, and AI-driven operational identities should not be governed by separate privilege logic unless their risk profiles are explicitly different.
👉 Read our full editorial: Cloud permissions are becoming the real PAM battleground in DevOps
