Testing preventive policies has always been the hardest part of deploying them. Teams hesitate because they don't know the impact. Will a new SCP block a legitimate workflow? Will an Azure Policy deny a production deployment? The fear of breaking things keeps policies stuck in draft mode.
In Launch Week 11, we introduced the Policy Simulator to test policies before deploying them. You could create mock events, duplicate and modify policies, and iterate through variations in a safe environment. Now Guardrails connects directly to your SIEM, streaming real event data into the simulator so you can test against what's actually happening in your environment.
Connect your SIEM
Guardrails integrates with your SIEM to bring real event data into the prevention platform. Connect AWS CloudTrail Lake or Splunk Enterprise, and preventive activity from your environment starts flowing into Guardrails automatically.
Point Guardrails at your CloudTrail Lake Event Data Store, deploy an IAM role with the provided CloudFormation or Terraform template, and denial events start flowing in automatically. No agents to deploy, no log forwarding to configure. Your existing SIEM investment becomes a direct input to your preventive security posture.
See what your preventions actually do
Your preventive controls are working on your behalf every day. The Guardrails dashboard shows denied actions and blocked activity across your organization, giving you a real-time view of your preventive posture in action.
Drill deeper into any preventive objective and the observations tab shows denied events over time. Each objective tracks its own denial activity, so you can see exactly which preventions are doing the most work and how activity is trending.
When a developer gets blocked
Here's where it gets practical. A developer on the payments team logs into the goliath-payments-prod account, switches to the Asia Pacific (Singapore) region, and tries to create an S3 bucket. AWS returns an error: "Failed to create bucket. To create a bucket, the s3:CreateBucket permission is required." The API response mentions an "explicit deny in a service control policy," but doesn't say which one.
The developer knows they were blocked by an SCP, but not which one, not where it's attached, and not why. They open a support ticket and wait.
With Guardrails connected to CloudTrail Lake, that denied event flows into the platform automatically. No digging through CloudTrail logs. No guessing.
See exactly why it was blocked
Open the event in the Policy Simulator and the full picture appears. The org tree shows the path from Root through the Workloads OU, down to the Payments OU, and into the goliath-payments-prod account. The Region-Restriction-Workloads SCP on the Payments OU is highlighted as the policy that denied the request.
The SCP allows only six regions: us-east-1, us-east-2, us-west-1, us-west-2, eu-west-1, and eu-central-1. The developer requested ap-southeast-1, which isn't on the list. Mystery solved in seconds.
But the simulator shows more than just the region restriction. The Workloads OU above also applies RequireIMDSv2, IAM-Complete-Controls, and Data-Compute-Controls. You see every layer of prevention in the evaluation chain, not just the one that triggered the deny.
Test changes before deploying
Now suppose the payments team has a legitimate need for ap-southeast-1. Instead of modifying the SCP in production and hoping for the best, duplicate the policy in the simulator. Add ap-southeast-1 to the allowed regions list. Re-run the evaluation against the same real event. The simulator shows you exactly what changes and what stays the same, so you can see the full blast radius before anything touches production.
The simulator works across AWS, Azure, and GCP. Test SCPs against CloudTrail events, Azure Policies against activity logs, and GCP Organization Policy constraints against audit logs. One simulator, consistent approach across every cloud.
From guesswork to evidence
Connecting your SIEM to Guardrails closes the loop on preventive security. Your controls block actions in production. Those events flow into the platform. You see exactly what was blocked and why. And when you need to make a change, you test it against real activity before deploying.
No more cryptic error messages. No more support tickets. No more guessing which policy in which OU is responsible. Connect your SIEM, and your preventive posture becomes something you can see, understand, and improve with confidence.
Ready to connect your SIEM to Guardrails? Get started to see how real-world event data powers smarter prevention.