In summary

On October 28, 2026, SACR published a report, authored by Jamie Feder and Paul Webber, that defines a new category in cloud security: Cloud Security Intent Enforcement (CSIE).

This new category is about turning what security teams already see into action, by enforcing controls in the infrastructure layer itself. It signals the shift we have been driving in cloud security: from finding risk and chasing it, to removing it at the source and keeping it removed.

This breakdown walks through what CSIE is, why it exists, how its control loop works, and where Act fits.

Why this is arriving now

Cloud security has spent a decade getting better at identifying risk. Teams can find misconfigurations, map attack paths and rank exposures across every cloud they run. Visibility  is largely solved. Acting on it is not.

Fixing vulnerabilities after the fact could still work while attackers moved at human speed. With AI in the picture, that no longer holds, and three things have shifted at once.

First, AI can find exploitable flaws faster than any team can fix them, and the queue only grows. Second, unknown zero-day attacks are growing fast, and for a zero-day a patch doesn't even exist, so remediating after the fact is not an option. Third, teams are now running AI agents inside their own environments, which adds access and risk of its own.

Put those together and the conclusion is hard to avoid: assume attackers already have a foothold. You will never patch fast enough, much of what they use can't be patched at all, and AI agents already run inside your environment. Getting in is close to a given. Once inside, things only get worse: they can run through every open path in your environment to reach your data and critical systems at machine speed.

The gap between knowing and doing is where risk lives. CSIE is the category built to close it.

What CSIE is

CSIE takes what your organization intends to allow in the cloud and enforces it as a control in your infrastructure. It is not a dashboard or another list of findings. It is a change to the infrastructure itself, made safely.

That change has two halves, and both are required: clearing the risk that is already there, and stopping new risk from arriving. Existing access and misconfigurations get cleaned up from the root. The boundaries then stay in place, keeping new risk out.

How we got here

Cloud security grew up around visibility: first posture, then identities, then attack paths. Each wave found more. But a finding on its own is not actionable. The person holding it does not know what the fix will touch or what it will break, so every change carries unknown risk. Teams hesitate, tickets age, and the finding stays open.

That hesitation used to be survivable. Now it isn't, because every unfixed finding will get used and every open path will be run through. The missing piece was never another finding. It was the confidence to act, and now it is urgent.

It works alongside CNAPP

CSIE is not CNAPP 2.0, and it does not replace what CNAPP does well. CNAPP shows you the exposures and attack paths that live in your cloud. CSIE changes the environment so those exposures and attack paths no longer exist, and can't resurface.

We see it the same way: findings tell you what is wrong, and action is what removes it.

The loop

SACR describes CSIE as a control loop rather than a checklist, because environments never stop changing. It has five stages.

The CSIE control loop: Understand, Translate, Predict, Enforce safely, Govern and maintain.

1. Understand. Know your specific environment, including its real reachability, alongside what you intend to allow.
   ‍
2. Translate. Turn that intent into controls you can enforce through your own native cloud controls.
   ‍
3. Predict. Know the impact of a change before it ships. Most of the weight falls on this stage, because without it no one will enforce anything. A good simulation has to be proven on your actual environment, with your real identities, data, resources, permissions, network paths and every existing control already in place.
   ‍
4. Enforce safely. Enforce the change in the infrastructure itself, at a point every principal is held to, whether human, non-human identity or AI agent, and that can't be manipulated or bypassed.
   ‍
5. Govern and maintain. Keep it in place as the environment changes. Every new person, vendor or resource lands inside your defined boundaries, and managing changes and exceptions stays simple, so staying secure doesn't take endless manual work.

What you should expect from it

• Attack paths are removed, not just reported.
• Every identity, workload and service can reach only what it needs.
• Changes are proven safe before they ship.
• Fixes stay fixed as the environment changes, instead of sprawling back.
• Teams get boundaries they can see and trust.
• The endless remediation chase ends.

Where it helps most

CSIE pays off fastest where the cloud is large and moving: multi-cloud estates, large engineering organizations and regulated companies, with many accounts, many identities and many teams changing things every day.

But CSIE is not just for giant corporations. It is for any company that wants to stop the endless remediation chase and build an infrastructure that is safe from AI attacks. Today, that is most teams.

Where Act fits

Act is built around action: removing risk at the source and keeping it removed for good. Access is where we start, because unneeded access is what turns a single foothold into a breach. Risk configurations sit inside the same loop, so nothing is left outside it.

All of it is organized around how your business runs, divided into contextual boundaries: external, environments, human access, AI, data and applications. Not a generic template.

• Understand: Act builds a digital twin of your real environment, modeling access across identity and network in one unified graph. It shows what is configured (what’s written on paper), what is effective (what’s actually reachable), and what is observed (what has really happened), all measured against what is intended (what should be allowed).
  ‍
• Translate: Act turns the gap between what is allowed and what should be allowed into guided Campaigns, where a single action resolves a whole class of risk across your environment.

• Access Campaigns place contextual boundaries around access, keeping it down to only what should be reachable, and nothing more.
  ‍
• Posture Campaigns eliminate the root cause of misconfigurations. Existing ones are neutralized with compensating controls, new ones are blocked from being created, and everything running in your cloud stays compliant with the regulations you adhere to.
  ‍
• Predict. Before anything ships, Act simulates a change against your real environment and shows exactly what it would affect. Audit mode lets you watch it play out over time first, and built-in exceptions keep legitimate work running.
  ‍
• Enforce. Act turns approved changes into native IAM, network, resource and organizational controls, delivered through Terraform, coding agents, tickets or DevOps workflows.
  ‍
• Govern and maintain. Act manages every exception and violation in your own tools, with the proof already attached, so staying secure doesn't take endless manual work.
  • Exception handling: requests and approvals happen right where your teams work. Users see why access was blocked in Slack, Teams or whatever tool they use, and can request an exception if they still need it. Security reviews the request with the investigation already done, and grants or declines in one click.
    ‍
  • Violation management: see every policy change with the investigation already done, and roll back if needed.
    ‍
  • Change management: new vendors, people and resources land inside your existing boundaries, with exceptions that grant only the access they need.
    ‍
  • CI/CD integration: block risk from shipping in CI/CD, with no downtime or disruption to app operations.

Closing

Visibility showed cloud security teams the problem. The next job is action: clearing the access and risk that built up over the years, and making sure it doesn't sprawl back. That is the shift CSIE names, and it is the work Act does every day. Thank you to Jamie Feder, Paul Webber and the SACR team for putting a name to it.

You can read the full report here.

‍