How the Sonrai Cloud Permissions Firewall enforces cloud least privilege at the AWS organization level — with Service Control Policies and Resource Control Policies, instead of cleaning up entitlements one identity at a time.
The standard answer to cloud over-permissioning has been CIEM: inventory every identity, compute its effective and used permissions, score the findings, and open tickets asking developers to rewrite IAM policies. That model is analytically sound and operationally broken. Sonrai's 2024 Cloud Access Data Report found that 92% of identities with access to sensitive permissions did not use them over a 90-day window, so ticket-driven remediation means thousands of bespoke policy edits, each carrying breakage risk and each competing with feature work. Most are undone by drift the following quarter.
The Sonrai Cloud Permissions Firewall (CPF) moves the enforcement point. Instead of fixing identity policies one at a time, it deploys preventative deny controls inside the AWS organization hierarchy — Service Control Policies (SCPs) and Resource Control Policies (RCPs) at the scope you choose — governing only the permissions that matter, with every legitimate existing user of those permissions automatically exempted based on historical usage. Least privilege stops being a backlog and becomes a default posture: 100% of identities protected by default, on day one, with no disruption to running workloads.
Cloud Infrastructure Entitlement Management (CIEM) tools are good at diagnosis. A CIEM platform will tell you, accurately, that a role has 2,900 permissions and uses 40. The failure is in the prescription: a finding becomes a ticket, the ticket goes to the team that owns the identity, and that team is asked to hand-author a tighter IAM policy. At cloud scale, this fails for three predictable reasons.
When the overwhelming majority of identities hold sensitive permissions they never touch, remediating each one requires someone who understands both IAM policy language and what that identity and its workloads actually do. That combination of skills is scarce, and the number of identities needing it grows with the estate. The arithmetic never closes.
Which permissions a workload depends on is rarely obvious from the outside. To avoid breaking something in production, teams defer the edit — and tickets age. The rational individual choice, repeated across every team, produces an organization that never tightens anything.
New identities, new services, and new deployments regenerate the finding set faster than teams can close it. The result is a permanent remediation backlog that measures activity in tickets closed rather than risk removed. The environment is never actually protected, and the backlog is permanent.
Most organizations that bought CIEM are no closer to least privilege than when they started.
| Dimension | CIEM ticket-driven remediation | Sonrai Cloud Permissions Firewall |
|---|---|---|
| Enforcement point | The individual identity's IAM policy | The AWS organization hierarchy — Org, OU, or account — via SCPs and RCPs |
| Unit of work | One hand-authored policy edit per over-privileged identity | One deny control per scope, covering every identity in it |
| Nature of the control | Advisory: a finding and a ticket | Preventative: a deployed deny policy |
| Developer involvement | Required for every remediation | Not required to reach a protected state |
| Scope of permissions addressed | All permissions, aiming at perfect least privilege | Roughly 2,500 privileged permissions that enable escalation, lateral movement, and exposure, catalogued and updated weekly by Sonrai research |
| Disruption risk | Unknown until the edit ships | Neutralized in advance: every identity that used a governed action in 90 days is auto-exempted |
| Granting new access | A new ticket and a new policy edit | An approval in Slack or Teams that flips a tag satisfying an existing policy condition |
| Effect of drift | Regenerates the backlog every quarter | New identities are born into the deny scope by default |
| Time to protected state | Indefinite; the backlog is permanent | Days, with 100% of identities protected by default |
| Reversibility | Requires re-editing each policy | The control can be withdrawn at any time |
The Cloud Permissions Firewall inverts the model. Rather than shrinking each identity's policy to match its usage, it deploys deny controls at the organization level — at the Org, an OU, or an account — that block privileged permissions for everyone except the identities that demonstrably need them.
Exemptions are expressed as conditions in the deployed policy, keyed on aws:PrincipalTag and aws:PrincipalArn, rather than as one statement per identity. When access needs change, an approval flips an attribute such as a tag on the identity, which satisfies a condition already present in the deployed SCP. The policy document itself is never rewritten. This is the structural difference that makes ongoing operation cheap: granting access is an attribute change, not a deployment.
Control stays entirely inside your account. Sonrai generates infrastructure-as-code — CloudFormation, Terraform, and similar — containing the SCPs and RCPs, and your team deploys it. Sonrai has no direct access to your organization's policies. Enforcement is preventative rather than advisory: the outcome is a deployed deny policy, not a ticket, and it is reversible at any time.
What follows are the properties that make organization-level enforcement practical to run in production, and that the ticket-driven model could never deliver.
CPF never asks you to rewrite the IAM policies you already have. Existing roles, users, and their attached policies stay exactly as they are — the organization-level deny simply sits above them and neutralizes the unused privileged permissions they contain. One control deployed at an OU does the work of hundreds of individual policy edits. There is no migration project, no policy refactoring sprint, and no dependency on developer time to reach a protected state.
Perfect least privilege — every identity trimmed to exactly its used actions — is the standard CIEM chased and never reached. CPF targets what matters instead. Sonrai's cloud research team maintains a catalog of privileged permissions — the actions that enable privilege escalation, lateral movement, and data exposure — updated weekly as cloud providers ship new services. It currently covers roughly 2,500 of the 47,000-plus permissions AWS exposes, and the default controls govern only those.
Low-risk actions remain allowed, which means an engineer browsing the AWS console does not hit a wall of denials. List and describe operations keep working, and day-to-day operations are untouched. You get the risk reduction of least privilege without the operational friction that causes least-privilege programs to be rolled back. Custom controls can extend the catalog where your environment needs it — preventing data-destruction actions, for example, or enforcing other company-specified initiatives.
You get the risk reduction of least privilege without the operational friction that causes least-privilege programs to be rolled back.
Before anything is enforced, CPF builds a complete map of every identity — users, roles, workloads, and agents — to the permissions and resources it actually uses. When a control is deployed, every identity that has performed a governed action within the previous 90 days is automatically exempted.
The practical consequence is counterintuitive but decisive: deploying a control against an estate where 92% of identities holding sensitive permissions never use them disrupts nothing, because the identities actively using a permission keep it and only the unused grants are cut off. This is what makes it safe to run the controls as-is on day one, rather than after months of analysis and sign-off.
AI agents now hold cloud identities of their own, acting directly or on behalf of humans, and they inherit the same over-permissioning humans do — with less predictable behavior. CPF governs agent identities exactly like any other principal: an agent gets the privileged permissions its history justifies and nothing more.
When an agent steps outside that envelope — because it has gone off-task, because its credentials have been hijacked, or because you are facing a red team or an attacker operating a frontier-class agent — the attempted action is denied and an approval request is raised automatically. EventBridge rules detect workload- and agent-triggered denials and route them to the right approvers for that part of the cloud immediately. A human decision sits between an autonomous system and a privileged action at precisely the moment it matters.
Deployment pipelines need to wield privileged permissions, and no security control that breaks the release train survives contact with engineering. CPF supports exemptions based on patterns — matching pipeline roles by principal pattern rather than enumerating them — so golden pipelines are never interrupted as new pipeline instances come and go. For tighter governance, you can instead treat pipeline elevation as a just-in-time access request: the pipeline requests it, an owner approves, and the grant is time-bound.
Zombie identities — dormant, unused roles and users left over from past projects — expand the standing attack surface while providing no operational value. They are not an edge case: the 2024 Cloud Access Data Report found that 61% of all cloud identities are unused, 88% of them machine identities. CPF quarantines them with an organization-level deny rather than deleting them. The identity becomes instantly unusable to an attacker, but nothing is destroyed. If a quarantined identity turns out to be needed, it is restored with an approval rather than an infrastructure archaeology project. Quarantine gives you the risk reduction of deletion with none of its irreversibility.
Least privilege fails when getting new access is painful, because teams respond by hoarding permissions. With CPF, when an identity needs a permission it does not have, the request arrives in Slack, Microsoft Teams, or email, and the approver actions it in place.
Grants can be time-limited. Self-approval can be permitted for designated low-risk scopes, and specific permissions can be designated to always require a second party. On approval, Sonrai updates an attribute such as a tag and the existing policy condition takes effect immediately — no policy change, no deployment, no ticket. Unanswered requests escalate to the approver at the next level up the scope hierarchy, and a request that reaches the end of the chain unapproved is simply denied: the system fails closed.
Every scope in the firewall — root, OU, account — has a designated owner and approvers, established when the firewall is set up. That single fact fixes the accountability gap that ticket-driven remediation never solved. When a permission change is requested, the person who owns that part of the estate sees it, decides it, and the decision is recorded. Teams always know when permissions in their scope are changing and who approved it, and access decisions are made by the people with context instead of a central security queue.
The CIEM generation proved that visibility alone does not change risk: a finding without an enforcement mechanism is a ticket, and tickets lose to feature work indefinitely.
The Cloud Permissions Firewall makes least privilege an enforced default rather than an aspiration. It eliminates the work of individual identity cleanup, and it eliminates the failure modes that kill least-privilege programs — broken consoles, disrupted workloads, and interrupted pipelines. It places a human approval in front of every privileged escalation, whether it comes from an engineer, a workload, or an AI agent.
Organizations deploy it and reach a protected state in days, with 100% of identities protected by default. The neverending backlog is eliminated. Cloud teams stop chasing a definition of least privilege that is ceaselessly out of date, and instead start managing a future-proof default-deny state.
Least privilege is the principle that every cloud identity — human, machine, or AI agent — should hold only the permissions it actually needs, and no more. In practice the gap is wide: Sonrai's 2024 Cloud Access Data Report found that 92% of identities with access to sensitive permissions did not use them over a 90-day window. So the hard part is not agreeing with the principle but finding an enforcement mechanism that scales beyond hand-editing IAM policies one identity at a time.
CIEM tools diagnose over-permissioning accurately but hand the remediation back as tickets. Three things then break the model: the volume of over-privileged identities exceeds the supply of people who understand both IAM policy language and workload behavior; each policy edit carries production breakage risk, so teams defer; and new identities and services regenerate findings faster than the backlog closes. The result is a permanent queue that measures tickets closed rather than risk removed.
CIEM produces findings about individual identities. A Cloud Permissions Firewall produces a deployed deny control at the AWS organization level. Instead of shrinking each identity's policy to match its usage, CPF blocks privileged permissions across an Org, OU, or account for everyone except the identities whose historical usage justifies them. The output is enforcement, not a ticket.
No. Existing roles, users, and their attached policies stay exactly as they are. The organization-level SCP or RCP sits above them and neutralizes the unused privileged permissions those policies contain. There is no migration project, no policy refactoring sprint, and no dependency on developer time to reach a protected state.
Not by design. Before enforcement, CPF maps every identity to the permissions and resources it actually uses, and any identity that performed a governed action within the previous 90 days is automatically exempted when the control deploys. Because only unused privileged grants are cut off, deploying against an estate where 92% of identities holding sensitive permissions never use them disrupts nothing. The console also shows the identity blast radius before anything is deployed.
Only permissions that are actually dangerous. Sonrai's cloud research team maintains a catalog of roughly 2,500 privileged permissions — the actions that enable privilege escalation, lateral movement, and data exposure — out of the 47,000-plus AWS exposes, and updates it weekly as new services ship. Low-risk actions such as list and describe operations remain allowed, so engineers browsing the console do not hit a wall of denials. Custom controls can extend the catalog for environment-specific needs such as blocking data-destruction actions.
Exemptions are expressed as conditions in the deployed policy, keyed on aws:PrincipalTag and aws:PrincipalArn, rather than as one statement per identity. When an access request is approved, Sonrai updates an attribute such as a tag on the identity, which satisfies a condition already present in the deployed SCP. The policy document is never rewritten and nothing is redeployed.
AI agent identities are governed exactly like any other principal: an agent keeps the privileged permissions its usage history justifies and nothing more. If an agent attempts an action outside that envelope — because it has gone off-task, because its credentials were hijacked, or because an attacker is operating it — the action is denied and an approval request is raised automatically. EventBridge rules detect agent- and workload-triggered denials and route them to the right approvers immediately, putting a human decision in front of autonomous privileged action.
CPF supports pattern-based exemptions that match pipeline roles by principal pattern rather than by enumerating each one, so golden pipelines keep working as new pipeline instances come and go. If you want tighter governance, pipeline elevation can instead be handled as a just-in-time request: the pipeline asks, an owner approves, and the grant is time-bound.
They are quarantined rather than deleted — which matters at scale, because the 2024 Cloud Access Data Report found 61% of cloud identities are unused. The identity becomes immediately unusable to an attacker, but nothing is destroyed — so if it turns out to be needed, it is restored with an approval instead of an infrastructure archaeology project. You get the risk reduction of deletion without its irreversibility.
No. Sonrai generates infrastructure-as-code — CloudFormation, Terraform, and similar — containing the SCPs and RCPs, and your team deploys it. Control stays entirely inside your account, and every control is reversible at any time.
Days rather than months. Because enforcement happens at the organization level with usage-driven exemptions, there is no per-identity cleanup phase to work through. Organizations deploy the controls and reach a protected state with 100% of identities protected by default, without months of analysis and sign-off.
The request arrives in Slack, Microsoft Teams, or email, and the approver actions it in place. Grants can be time-limited, self-approval can be permitted for designated low-risk scopes, and specific permissions can always require a second party. Unanswered requests escalate to the approver at the next level up the scope hierarchy, and a request that reaches the end of the chain unapproved is denied — the system fails closed.
The identity and permission statistics in this paper come from two sources, both Sonrai research:
Claims about deployment time, exemption behavior, and approval workflow describe the Sonrai Cloud Permissions Firewall product and are not drawn from the report.
Prefer the PDF? Download the full whitepaper to share with your team.
Download the whitepaper (PDF)