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