Runtime Prevention with Guardrails

Prevention works in layers. Build-time scanning catches misconfigurations in infrastructure code before deployment. Access-layer controls like AWS Service Control Policies block risky actions at the API level. These controls are powerful, they prevent bad configurations from being introduced and safeguard against dangerous changes.

But they come with tradeoffs. Tight controls slow developer velocity. Access-layer policies are blunt instruments that block legitimate workflows alongside risky ones. And they have hard limits: AWS restricts you to 5 SCPs per account with strict character limits per policy. If you tried to prevent every CIS benchmark objective with SCPs alone, you'd run out of capacity quickly.

Runtime prevention fills the gap. It allows innovation and speed. Minor misconfigurations pass through access-layer controls, then get auto-corrected in flight within seconds. Teams move fast. Security stays in control. Both goals achieved without the friction of gates and approvals.

Configure Runtime Enforcement

You've assessed your prevention posture and received recommendations on which controls to implement. The recommendations guide you on the right enforcement layer for each control. Critical actions that should never happen get blocked at the access layer: wrong regions, disabled audit logging, exposing data publicly. Configurations that can be corrected after resource creation get auto-enforced at runtime: versioning, logging, tagging.

Let's look at S3 bucket versioning as an example. The recommendation shows runtime enforcement as the approach. Select it to see the policy configuration.

The recommendation links directly to the policy that controls this behavior. Navigate to the policy to see how it's configured.

Configure With Point-and-Click Simplicity

The policy screen shows the control setting for S3 bucket versioning. Set it to "Enforce: Enabled" to automatically enable versioning on all buckets. Point-and-click simplicity, no code required.

Select where to apply the policy in your organizational hierarchy. Set it at the root and all child resources inherit the protection automatically. Or apply it to specific OUs or accounts for targeted enforcement. Inheritance flows down the hierarchy, so setting it once protects everything below.

This is one of 14,000+ out-of-the-box policies available in Turbot Guardrails. Coverage spans AWS, Azure, GCP, GitHub, Kubernetes, and ServiceNow. All part of your preventive posture, mapped to objectives and integrated with your other layers of preventive controls.

Advanced policy options provide even more control. You can set policies to expire, provide more context about the setting with annotations, and extend enforcement with dynamic conditional logic using calculated policies.

Calculated policies allow conditions that can be based on resource tags, any configuration detail from the cloud provider, audit trail data, or third-party datasets. This reasoning adjusts the control's posture in real-time. For example, you may enforce versioning on all buckets by default, except when a specific tag like "temp":"true" is set to enforce disabling versioning. There are infinite possibilities to handle any dynamic posture nuances for your organization.

The policy is now active. Any bucket without versioning enabled will be automatically corrected, and any new buckets or changes to existing will be evaluated in real-time with automatic remediation enforced.

See It Enforce in Real-Time

Create a new S3 bucket in the AWS console. In this case, our existing SCPs allow the creation to proceed.

The bucket is created but missing several configurations: versioning is disabled and there are required tags are absent. These settings weren't blocked because they can be corrected after creation. The bucket exists and is ready to use.

But within seconds, Guardrails detects the new bucket and evaluates it against all applicable policies set. The activity screen shows the automated actions Turbot takes to bring the bucket into compliance.

Versioning enabled. Required tags applied. Public Access Block was evaluated and marked OK. All within seconds of bucket creation. The sequence:

• Turbot Guardrails identified the bucket created (seconds from creation in AWS)
• Evaluated multiple controls (5+ seconds)
• Shifted applicable controls to ALARM state to alert
• Auto-remediated controls in ALARM state (within 9 seconds from resource creation)
• Turbot loops back to discover its own change (screenshot below)
• Closes its own ALARMs after validating the change was completed

Heading back to the resource's controls screen for the bucket shows green across all policies.

Refresh the AWS console. The bucket now has versioning enabled, logging configured, and tags applied. The changes are visible immediately.

The developer wasn't blocked. The bucket was created quickly. Security requirements were enforced automatically. No tickets, no delays, no manual intervention. This is runtime prevention at work.

See it in action

Watch this demo to see how Guardrails automatically detects and remediates misconfigurations in real-time.

Move Fast, Stay Secure

Runtime prevention completes your defense-in-depth strategy. Build-time scanning catches issues in code. Access-layer controls block critical actions. Runtime enforcement auto-corrects configurations within seconds. Each layer handles what it does best, providing comprehensive protection without sacrificing agility. Development teams deploy at speed. Security teams enforce compliance automatically.

Interested in running this in your environment? Connect with us to get your free preventive security posture assessment and start auto-enforcing compliance across your cloud environment.