Using guardrails for custom policy enforcement

Terracotta AI Guardrails let DevOps, SRE, and Platform teams apply custom internal standards across Terraform and CDKTF pull requests. Guardrails go beyond traditional policy-as-code by enabling context-aware, AI-powered enforcement using your team's own best practices.

🚧 What Are Guardrails?

Guardrails are configurable rule sets that enforce your internal security, naming conventions, and compliance requirements. These are uploaded as text or file documents and applied automatically during PR review.

Unlike OPA or Sentinel, Guardrails don’t just pass or fail a policy. They:

✅ Explain the violation in plain language
✅ Point to the exact line of the offending code
✅ Recommend a resolution
✅ Help developers understand why it matters

📦 How Guardrails Work

Upload your standards (checklists, SOPs, naming rules, etc.)
Assign them to either:
- 🔒 Org-wide – enforced across all connected IaC repos
- 📁 Per-repo – applied only to one specific repository
Terracotta AI integrates those rules into every PR review
Developers can trigger a targeted check with the command:

tc:guard

🔍 Example Output: Guardrail Violation

Terraform Guardrail Violation Report

Detected Violations
File: main.tf
Line	Rule Category	Description	Severity	Resolution
125	Naming Convention	Resource name does not follow 'Andy-'	🔴 High	Rename the resource so its name starts with Andy-, e.g., Andy-myresource for consistency.

Explanation

What triggered the violation? A resource name at line 125 doesn’t start with "Andy-".
**Why is this a problem?**Your organization requires this naming for tracking, audit, and consistency. **
How to resolve it: Update the name to follow the required convention.

Recommended Actions

Fix the name in main.tf
If exceptions apply, document them
Use CI linters alongside Guardrails to catch early

Summary

High severity issues: 1
PR Status: 🚫 Block until fixed or exception granted

🛠 What Guardrails Can Enforce

Guardrails can be used to enforce a wide variety of custom organizational policies, including but not limited to:

Tagging Requirements: Ensure all resources include required tags such as Owner, Environment, Team, Project, CostCenter, etc.
Naming Conventions: Enforce specific naming patterns across environments (e.g., env-team-resource, prod-*, Andy-*).
Encryption Policies: Require encryption at rest or in transit for S3 buckets, RDS, DynamoDB, EBS volumes, etc.
IAM & Access Control Standards: Detect overly permissive IAM policies, enforce use of managed roles, or restrict usage of wildcard (*) permissions.
Public Exposure Restrictions: Prevent open ingress (0.0.0.0/0) to sensitive ports, or require bastion jump hosts.
Secrets Management: Block hardcoded secrets, credentials, or tokens within .tf or .tfvars files.
Resource Constraints & Quotas: Limit usage of expensive instance types, enforce region restrictions, or cap resource counts.
Consistency Checks: Validate that resources in modules follow the same structural patterns as root resources.
Compliance Rules: Map custom rules to SOC2, ISO 27001, or CIS benchmarks.
Environment-specific Conditions: Enforce stricter rules in prod than in dev or stage environments.

Guardrails are highly flexible and context-aware. You define the standards — we enforce them across all pull requests, with explanations and recommendations tailored to your code.

🤝 Why Use Guardrails?

Enforce Org Policy Automatically: Make your cloud team’s internal docs enforceable in code.
Catch Violations Early: No more "after deploy" surprises.
Empower Developers: Developers see what to fix and why it matters in the PR.
Build Organizational Memory: Institutionalize knowledge like "we always encrypt these tables" or "tag X is mandatory in prod".

📋 TL;DR

Guardrails are custom rules you define and apply across repos
Powered by AI that explains what’s wrong, not just that it failed
Applied org-wide or per-repo
Triggered via tc:guard in pull requests
Helps shift security, consistency, and compliance left into the PR review flow