Delfen
All articlesAI in Practice

The policy-as-code gate — where infrastructure safety actually lives

Article 2 said Category 2 configurations need non-negotiable validation. But 'you should run Checkov' is advice, and advice does not survive contact with AI generation speed. Validation only protects you when it is a gate that cannot be skipped. Here is how to build one — and the five ways teams build one that doesn't hold.

Jacques Domenie·13 July 2026·8 min read

In the previous article, Category 2 — configuration with constraints — came with one non-negotiable instruction: run Checkov or OPA against every output before it goes near an environment. That instruction is correct and almost useless. "You should validate" is advice. Advice depends on a human remembering to follow it, under deadline pressure, on the Friday afternoon when the AI just produced forty resources in a clean-looking plan.

Advice does not survive contact with AI generation speed. A control does.

The difference between the two is the difference between running a tool and building a gate. A tool you run is a thing someone chooses to do. A gate is a thing the pipeline does whether anyone remembers or not — it runs on every change, it blocks the merge or the apply when a policy is violated, and it cannot be skipped without a deliberate, logged, accountable act. That last property is the whole point.

Safety does not live in the review

Here is the shift the AI era forces, stated plainly: review happens at human speed, and the machine no longer generates at human speed. When a person wrote the Terraform, the review kept pace with the writing — they were the same order of magnitude. When AI writes the Terraform, the generation is a minute and the competent review is an hour, and the economic pressure is entirely toward shipping at the speed of generation. So you cannot put your safety in the review. The review will be the thing that gets compressed.

You have to put the safety somewhere that runs at machine speed too. That place is the gate.

This is not a theoretical concern. The DPIaC-Eval study found that 91.6% of AI-generated infrastructure-as-code fails security checks on the first pass. Read that as an operational number, not a headline: if your teams are using AI coding tools — and they are — then roughly nine in ten of the configurations they generate would fail a policy check, and the only question that matters is whether a check is actually standing between that output and production. If the check is advice, it isn't. If the check is a gate, it is.

What the gate actually is

Concretely, a policy-as-code gate on a Terraform pipeline is two enforcement points, not one.

Gate 1 — plan-time, before merge. On every pull request, the pipeline runs terraform plan, exports the machine-readable plan with terraform show -json, and evaluates it against your policy set. Static HCL scanners like Checkov catch a large class of issues directly from the source. But the plan JSON is what matters most, because computed and interpolated values — the ones AI gets wrong in interesting ways — only resolve at plan time. You evaluate the plan with OPA (via Conftest, the policy CLI) against Rego rules. A violation fails the CI job.

Gate 2 — apply-time, before the change lands. The plan-time check proves the proposed change is clean. It does not prove that what gets applied is what was proposed, or that someone didn't bypass the PR entirely. For teams on HCP Terraform or Terraform Enterprise, HashiCorp Sentinel runs as a policy set at apply, with enforcement levels — advisory, soft-mandatory, hard-mandatory — that decide whether a violation warns, can be overridden by a named approver, or hard-stops. Hard-mandatory at apply is the floor under everything.

A minimal Rego rule — deny any storage bucket without encryption — reads about like this:

package terraform.s3

deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "aws_s3_bucket"
  not resource.change.after.server_side_encryption_configuration
  msg := sprintf("S3 bucket '%s' has no server-side encryption", [resource.address])
}

That is the entire mechanism: the guardrail, written once, as code, evaluated against every plan forever. You are not reviewing forty AI-generated resources. You are writing the rule that reviews them — and every plan after them.

The part that makes it a gate, not a suggestion

Writing the Rego is the easy 20%. The 80% that decides whether you actually have a gate is the enforcement wiring, and it is almost entirely a governance question rather than a technical one:

  • The policy job is a required status check in branch protection — the merge button is disabled until it passes.
  • The required check applies to administrators too. A gate that repo admins can wave past is a gate with a door in it.
  • There is a break-glass path — a deliberate, named, logged override for the genuine emergency — and it is the only way past, because the alternative to a sanctioned exception is an unsanctioned one.

That last point connects directly to compliance. Under NIS2 Article 21, cybersecurity risk-management measures must be accountable to named individuals. A policy gate with a logged break-glass override is that accountability, expressed as infrastructure: every bypass has a name and a timestamp attached to it. A pipeline where the check is advisory has the opposite property — it manufactures plausible deniability at scale.

Five ways teams build a gate that leaks

I have seen each of these in production. They are the difference between a gate on the org chart and a gate in the pipeline.

1 — Advisory, not blocking. The policy check runs, posts a tidy comment listing violations, and the merge proceeds anyway because the check is not required. This is the most common failure and the most seductive, because the pipeline looks governed — there is a check, it has output, someone built it. It blocks nothing. A gate that does not block is a logging system with good PR.

2 — The administrator bypass. Branch protection is configured, but "include administrators" is unchecked, and under a release deadline a lead merges past a red check in four seconds. The exception becomes the habit. Fix: protect against admins, and make the only override the logged break-glass path — friction by design, because the friction is the accountability.

3 — Plan-clean, state-dirty. The gate validates the plan beautifully, and meanwhile someone changes a security group in the console. The pipeline's model of reality and reality have diverged, and the gate is guarding a door that people are walking around. Fix: drift detection on a schedule, and apply-time enforcement (Sentinel hard-mandatory, or an equivalent), so the running state — not just the proposed change — is what gets checked.

4 — Too strict, so switched off. An over-broad policy starts blocking legitimate work — it denies a pattern the platform team explicitly sanctioned — and rather than tune one rule, someone disables the whole policy set. The gate goes from 100% to 0% in a single commit. Fix: policies need an owner and an exception mechanism per rule, not a binary on/off switch that pressure will eventually flip. A gate you can tune is a gate that survives; a gate you can only disable is a gate that gets disabled.

5 — Checking the wrong layer. A static HCL scan passes, the apply ships a misconfiguration, and everyone is confused — because the dangerous value was computed at plan time and never appeared in the source the scanner read. Fix: evaluate the plan JSON, not only the HCL. Static scanning and plan evaluation catch different failure classes; AI-generated config is exactly where the gap between them shows up.

When the gate catches what review missed

The first time your policy gate blocks something your human review had already approved, two things are true at once, and both matter.

The first: the gate is working. It caught a real problem that a competent reviewer, moving at the compressed speed the AI era imposes, did not. That is the entire justification for building it.

The second, and the one the 10x architect acts on: every gate catch is a signal about where your review is blind. Do not just merge the fix and move on. Ask the governance question — why did review miss this? The answer is always one of two things. Either the miss encodes a lesson that belongs in the policy set as a new rule, so the gate catches the whole class next time — or the review itself has a structural gap that more rules won't fix. Over a few months, the pattern of what the gate catches becomes a map of where AI-assisted generation reliably fails in your environment specifically. That map is not in any tool's documentation. It is the thing you are uniquely positioned to build, and it is worth more than the gate itself.

The architect's actual job here

You will notice what the architect does not do in any of this: review the forty AI-generated resources. That work has moved. The 10x enterprise architect's job on this is four things, and none of them is typing faster than the model:

  1. Own the policy set — the encoded guardrails. This is the architectural runway from the last article, made executable: the rules every team's AI-assisted delivery runs inside.
  2. Decide enforcement levels — what is advisory, what is hard-mandatory, and why. That is a risk judgment, and it is yours.
  3. Design the exception path — the break-glass with a name on it, the per-rule tuning, the thing that keeps the gate from being switched off the first time it's inconvenient.
  4. Evolve the policies from what the gate catches — closing the loop, turning each incident into a rule.

AI creates the configurations. The gate decides what ships. And the gate enforces your judgment, encoded once and applied at machine speed to everything that comes after — which is the only way judgment scales to meet generation that never sleeps. You do not out-type the machine. You write the gate the machine has to pass through.

The IaC guardrails starter — a baseline Rego/OPA policy set, the CI wiring for the two gates, and the break-glass pattern — will be available as a toolkit at delfen.ai/toolkits. Subscribe below to be notified when it lands.

Next

Article 4 steps back from the pipeline to the thing the gate is an instance of: the architectural runway — designing the rails ahead of delivery so that AI-accelerated teams have somewhere safe to run fast, instead of improvising into a vacuum the machine will happily fill.

If you want the series as it lands, subscribe below.

If you can't beat them, lead them.

Sources & further reading

Continue reading

Get the next article in your inbox.

One deep-dive per week. Free. No pitch. Unsubscribe anytime.

Subscribe to the Delfen Briefing →
← Back to all articles