The Policy Guardrail Checker evaluates pasted Terraform configuration against a practical set of SCP/OPA-style guardrail rules so you can catch policy and security violations before they ever reach a plan or an apply. It inspects standard HCL and reports required tagging gaps, publicly readable S3 buckets, missing S3 encryption, open security-group ingress from 0.0.0.0/0, and hardcoded AWS access keys embedded in attributes. Everything runs locally inside your browser, so your infrastructure code never leaves the machine and no cloud credentials or network calls are required. This makes the checker ideal for platform engineering teams that want a fast, opinionated quality gate during pull requests, for individual developers who want immediate feedback while authoring modules, and for auditors who need a repeatable, transparent control set. Use it as a lightweight stand-in for policy-as-code when you are not ready to stand up OPA, Sentinel, or a full CI control plane, or as a first-pass lint that runs before those heavier systems. Because the rule set is plain JavaScript embedded in the generated page, you can fork and extend it to match your organization exact tagging schema and security baseline. The checker works on arbitrary HCL, not just AWS, so you can adapt the same rules to other providers by editing the resource type conditions. Reports are plain text, which means they diff cleanly in code review and can be attached to tickets without special viewers.
Terraform Policy Guardrail Checker
Evaluate .tf against SCP/OPA-like guardrail rules. Runs entirely in your browser.
Your guardrail report will appear here.
About Terraform Policy Guardrail Checker
Features
- Required tags - verifies Owner, Environment and CostCenter on every resource and lists each missing key.
- Public S3 detection - flags buckets configured with public-read or public-read-write ACLs.
- Encryption checks - flags S3 buckets that lack a server-side encryption configuration block.
- Open ingress - flags security groups that allow inbound traffic from 0.0.0.0/0.
- Hardcoded keys - detects likely AWS access keys, including AKIA patterns, embedded in attributes.
- Severity levels - each finding is tagged HIGH for security, MEDIUM for policy gaps, or LOW for notes.
- Typed summary - a header line reports the total findings and a per-severity breakdown.
- Live stats row - counts by severity update after every check for an at-a-glance view.
- Export options - copy the report, download it as a text file, or send it to a printer.
- Zero upload - all parsing and evaluation happen locally with no network calls.
- Provider agnostic - rules key off resource attributes, so they apply to any provider, not only AWS.
- Diff friendly - plain text output drops into pull requests and tickets without extra tooling.
How to Use
- Open the tool and locate the Terraform input box on the left panel of the page.
- Paste your configuration - drop in the .tf file or snippet you want to evaluate for guardrails.
- Load a sample if you prefer to start from a realistic example that already contains several violations.
- Click Check guardrails to run the rule set against the parsed HCL resources.
- Review the report on the right, reading each finding with its severity, rule name and affected resource.
- Fix the issues in your source configuration based on the messages provided.
- Re-run until the report shows a clean pass with no remaining findings.
- Export the result by copying, downloading or printing the final guardrail report.
- Share the evidence - attach the downloaded report to the pull request so reviewers see the guardrail result inline.
Examples
Example 1 - clean configuration - a properly tagged instance with no public resources returns a passing report with no findings and a clear PASSED message.
Example 2 - public bucket - an aws_s3_bucket with acl = "public-read-write" produces a HIGH severity finding flagging the exposed ACL, plus a MEDIUM finding if server-side encryption is missing.
Example 3 - open ingress - an aws_security_group allowing cidr_blocks = ["0.0.0.0/0"] on port 22 raises a HIGH open-ingress finding so you can tighten the rule before deployment. Running the sample loads two resources that together trigger a HIGH, two MEDIUM and one LOW finding, demonstrating the full severity spread in a single pass.
Benefits
- Safer deployments - catch exposed resources and missing controls before they reach production.
- Consistent standards - enforce the same tag and encryption rules across every team and repository.
- Faster feedback - get results in seconds without waiting on a pipeline or cloud round-trip.
- Lower cost of compliance - reduce audit preparation by keeping a repeatable, documented check.
- Privacy by design - your configuration is never uploaded and no credentials are required.
- Teaching aid - new engineers learn the org rules by seeing exactly why each resource failed and how to fix it.