The Risk Isn't AI. It's Ungoverned Automation.

A single misconfigured Ansible Playbook can touch thousands of systems in seconds. A single untested Terraform change can do the same to a cloud environment. That’s always been true. What’s changed is who’s writing the code that reaches that point — and how fast it’s arriving.

GitHub Copilot, ChatGPT, Claude Code, and a growing wave of autonomous agents are now generating real chunks of the automation running in production. You’re not going to slow that down. You can only decide how to handle what it produces. AI assistants write faster than any team could, and most of what they produce is genuinely useful. But speed at the authoring stage doesn’t mean anything about what happens at the execution stage. Somewhere between “AI wrote this” and “this just ran in production,” someone still has to decide whether it’s allowed to run at all.

Steampunk Spotter is your AI guardrail for Ansible and Terraform code — verifying it before it ever executes.

We’ve written before about the specific ways AI-generated Ansible code goes wrong — hallucinated modules, deprecated syntax, leaked secrets. This post isn’t about whether you should use AI or Spotter for your infrastructure code – it’s about why the two need to work together. That means catching any mistake, from any author, before it ever runs — across Ansible and Terraform both.

Who’s Actually Writing Your Automation Now?

Five years ago, your Ansible Playbooks and Terraform configurations came from a short list of people you could name. Today, the list of authors looks different: your engineers, an AI assistant suggesting the next fifteen lines, an agent pipeline generating a full rollout on its own, a third-party collection pulled in as a dependency, and inherited content nobody on the current team originally wrote.

None of that is a red flag on its own. The tools themselves aren’t the risk — they’re the reason the next part matters more than it used to. The risk isn’t AI, it’s ungoverned AI: automation that reaches ansible-playbook or terraform apply without anyone or anything checking whether it’s safe, compliant, or even correct first.

The fix isn’t slowing AI down or reviewing every line by hand — neither scales. It’s applying the same deterministic standard to every author, human or otherwise, at the one point that actually matters: before execution. That’s the job Spotter is built to do.

A Generator Can’t Be Its Own Auditor

A scanner flags what’s wrong in a file, a guardrail decides what’s allowed to run at all — and the difference matters more, not less, once a growing share of what reaches the gate was never reviewed by a person at all.

Here’s what that looks like without a gate: an agent pipeline generates a Terraform configuration that provisions a storage bucket with public read access, because the examples it learned from skewed toward public-facing setups. Nothing about the code is syntactically wrong — it applies cleanly. The mistake only becomes visible once it’s already live. Put Spotter in front of that same pipeline, and the configuration never reaches terraform apply: a policy check flags the public ACL before it leaves the pipeline, and the engineer gets a specific reason, not a 2 a.m. page. The tool that generated that configuration has no way to catch this itself — it isn’t testing its own output against your policies, just producing something that looks plausible. Verification has to come from somewhere else, applied the same way no matter which of your five authors wrote the line.

Spotter’s governance model stands on four things:

1. Policy — the rules that define what “safe to run” means for your organization, written once and applied everywhere, not re-litigated per pull request.

2. Coverage — checks that go beyond syntax, into security, compliance, and upgrade risk, across every Playbook and Terraform configuration that reaches the gate.

3.Enforcement points — the ability to block execution, not just flag a warning after the fact.

4. Evidence — a record of what was checked, what was blocked, and why, so “we govern our automation” is provable, not just claimed.

Take any one of those away and you’re back to hoping someone reviews the AI’s output before it ships.

What Shift-Left Governance Looks Like in Practice

Picture one gate in front of two execution targets — Red Hat Ansible Automation Platform (AAP) on one side, terraform apply on the other. Spotter sits at the gate: every AI’s or author’s output passes through it before reaching either target, checked against policy-as-code rules written in REGO and evaluated through OPA, CIS benchmark validation, SBOM and CVE visibility, and custom rules specific to your environment.

In practice, policy, coverage, enforcement, and evidence work like this: Policy includes an AI Policy Generator that turns a plain-language description of a rule into working REGO, so a new standard doesn’t wait on a security engineer’s availability. Coverage means prebuilt CIS benchmarks for RHEL, Azure, AWS, and more, so you’re not writing compliance checks from scratch on top of your own custom rules. Enforcement means Spotter plugs into the CI/CD pipeline you already run — no separate workflow for AI-generated content versus hand-written code. Evidence means an audit trail with enterprise identity management (SSO) built in, so “we govern our AI-generated automation” is something you can show an auditor, not just say in a meeting.

In practice, policy, coverage, enforcement, and evidence work like this: Policy includes an AI Policy Generator that turns a plain-language description of a rule into working REGO, so a new standard doesn’t wait on a security engineer’s availability. Coverage means prebuilt CIS benchmarks for RHEL, Azure, AWS, and more, so you’re not writing compliance checks from scratch on top of your own custom rules. Enforcement means Spotter plugs into the CI/CD pipeline you already run — no separate workflow for AI-generated content versus hand-written code. Evidence means an audit trail with enterprise identity management (SSO) built in, so “we govern our AI-generated automation” is something you can show an auditor, not just say in a meeting.

Spotter’s latest capability meets AI agents where they already work: an MCP server that gives them structured context instead of raw scan output — enough for an agent to actually understand why a finding was raised, not just that it was. That’s what turns a scan result into something an agent can act on: understanding the finding comes first, fixing the code directly comes next.

The result, at organizations already running this way, is fewer surprises in production — one enterprise customer saved 17,000 hours by catching issues at the gate instead of after deployment.

Let Spotter Hold the Gate

AI is going to keep writing and managing more of your automation. That part isn’t really a decision your team gets to make anymore — it’s already happening. What is still a decision is whether that automation runs unchecked or passes through Spotter’s governance layer first. Same policy, same coverage, same gate, no matter who — or what — wrote the code.

How much of your AI-generated automation would actually survive a closer look? Find out in our webinar, What AI Gets Right and Wrong in Your Ansible and Terraform Automation, where we break down two real cases line by line — what AI got right, what it missed, and where it confidently got it wrong. Register here.