Governing AI-generated infrastructure starts before the Terraform is written.

Coding agents produce plausible Terraform in seconds, and every module they write becomes code your platform team maintains. Reviewing and scanning all of it gets harder each month. Massdriver moves the decision earlier: your team approves the modules once, and agents configure those modules instead of writing new ones.

Talk to us Download the executive brief

Code review is now the only gate

It usually becomes obvious in a pull request. An agent was asked for a small feature and also produced a new Terraform module for a bucket, a role, and a queue. The code is tidy and it passes the linter. A reviewer now has to decide whether those resources match how your company builds infrastructure, and the only tool they have is reading.

At a few pull requests a week, that holds. When every developer has an agent and every agent writes infrastructure, review becomes the boundary between generated Terraform and production, and the reviewers are the same people who were already behind.

The quality of the generated code is rarely the problem. The problem is that every request produces a new design, so there is always something new to check.

How teams try to control generated infrastructure

Each layer below is useful. Most of them judge infrastructure after an agent has already designed it.

Review every generated pull request

What it gives you

A person sees every change before it applies.

What it leaves to you

Review time grows with generation volume, and generation is the part that keeps getting cheaper.

Checkov and linters

What it gives you

Fast detection of known misconfigurations, such as public buckets and missing encryption.

What it leaves to you

Scanners know common rules. They do not know that your production Postgres must use the hardened module with your backup, network, and tagging conventions.

OPA or Sentinel policy

What it gives you

Enforceable rules at plan time, written by your team and versioned.

What it leaves to you

A strong gate on arbitrary infrastructure. Every new design still has to be written, planned, and judged.

Approved examples in the agent’s context

What it gives you

Better first drafts that look more like your code.

What it leaves to you

Guidance that the agent can ignore or adapt. Nothing enforces it.

A Massdriver catalog as the only way to deploy

What it gives you

Agents configure modules your team already reviewed. The schema bounds every parameter, and policy still runs on each plan.

What it leaves to you

Your team maintains the modules and decides which parameters to expose.

Scanning and a catalog answer different questions

A scanner asks whether a piece of infrastructure is acceptable. It has to ask that about every design an agent produces, and it can only check rules someone thought to write down.

A catalog decides which infrastructure can be deployed at all. When the deployment interface is a set of approved modules, an agent’s job is to pick a module and set its inputs. The design questions were answered once, by your platform team, when they published the module. Scanning still runs on every plan, as a second line.

Turn the Terraform you have into the agent’s vocabulary

Massdriver packages the Terraform, OpenTofu, and Helm your team already runs as bundles. Nothing has to be rewritten.

Each module becomes a bundle

A bundle wraps your module with a JSON Schema for its inputs, its connections to other bundles, and its policies. Developers see a generated form, and agents see a typed interface.

The schema is the boundary

The agent can set only the inputs the schema exposes, to values the schema allows. A request for an instance class you never published fails validation before any plan runs.

Connections are typed

Bundles connect through versioned resource types, so a service gets the database’s outputs without anyone wiring them by hand.

Policy still runs

Policy checks (SOC 2, HIPAA, CIS) run on every plan before apply, the same checks a change from a person gets.

What stays configurable, and what your platform team decides

A Postgres bundle is a typical example. The split is yours to choose, module by module.

The agent sets the size. Instance class and storage, from the values the bundle allows.
The agent picks the engine version. From the versions your team supports.
The agent tunes what the app needs. Backup retention within a range, or read replicas where the bundle offers them.
The platform team decides the rest. Network placement, encryption, backup policy, tagging, and deletion protection live in the module and are not inputs.

One generated change, start to finish

An agent building an export feature needs a bucket for the files.

01
What happens
The agent asks for the storage bundles its team may use, and proposes an instance of the approved bucket bundle.
What the record shows
The proposal names the agent and the bundle version. No new module enters your codebase.
02
What happens
The agent tries to make the bucket public for easy downloads. The bundle does not expose that input, so the proposal fails validation.
What the record shows
The rejected value is part of the record, and nothing was planned.
03
What happens
The agent revises the proposal within the schema. Policy checks run on the plan, and the bucket deploys to dev.
What the record shows
Policy results, diff, and deploy result are attached to the change.
04
What happens
A person with deploy permission approves the production change.
What the record shows
The approver is named on the change.
05
What happens
Months later, your team publishes a new version of the bucket bundle with a fix.
What the record shows
Every instance shows which bundle version it runs, so you know exactly which deployments to upgrade.

Questions platform teams ask

Should agents never generate Terraform?

Agents can generate code where it makes sense, such as a new module your team will review and publish. Production infrastructure rarely needs a new design for each application when approved patterns already exist.

Is Checkov enough?

Checkov catches known misconfigurations and should keep running. It cannot know your organization’s rules for how a production database is built. The module encodes those rules, and the scan checks the result.

Do we keep our Terraform?

Yes. Your existing Terraform, OpenTofu, and Helm modules become the bundles.

Does every application end up identical?

No. Each bundle exposes the inputs that should vary per application and fixes the decisions your platform team wants standard.

How do updates reach the apps that use a module?

Bundles are versioned. Each deployment records the version it runs, so you know exactly which deployments an upgrade affects.

Does this cover Helm charts and Kubernetes manifests?

Helm charts become bundles the same way Terraform and OpenTofu modules do. An agent sets the values the bundle exposes, and the chart your team approved is what deploys.

Start with one module your team already trusts

Pick the resource agents ask for most often, usually a database or a bucket, and publish the module your team already uses as a bundle. Point your agents at it. Within a week you can see how many generated modules you no longer have to review, and which inputs the agents actually need.

Standard modules, less release work

UniDoc runs its infrastructure through Massdriver. A blue/green release that took three engineers more than three hours now takes one engineer less than an hour.

“Massdriver’s platform has revolutionized our approach to infrastructure, saving us 89% of the time spent managing infrastructure. Our operation could upscale by an order of magnitude.”

Chip McIntosh

Chief Innovation Officer · UniDoc

One governed path, for agents and every other change.

Give us an hour with your platform and security leads, and within a day you have a governed path running on your own infrastructure, ready to prove for 30 days.

Talk to us Agentic platforms