Is AI-Generated Terraform Secure? We Scanned It (2026)

What exactly did we test?

We took the six resources people ask for most often and wrote each one the way an assistant writes it when the prompt says nothing about security — the minimal block, close to the first example in the provider documentation. Then we scanned each with Checkov, the same open-source engine Sovereign Observer runs.

This is deliberately not a strawman. Nobody wrote acl = "public-read" to make a point. These are the blocks you get from "add an S3 bucket for user uploads".

40 findings across 6 resources. 10 critical or high. An average of 6.7 findings per resource, before anyone has written a second line.

Why does a three-line resource produce seven findings?

Because Terraform providers optimise their defaults for it works, not for it is safe. A bucket that refuses public access, encrypts with a customer-managed key and versions every object is more secure and more likely to break someone’s first tutorial. So the default is the permissive one.

Take the S3 bucket. Three lines:

resource "aws_s3_bucket" "uploads" {
  bucket = "user-uploads"
}

That is valid, idiomatic Terraform. It also has no public access block, no versioning, no server-side encryption configuration, no access logging and no lifecycle policy. Every one of those is a separate resource in the AWS provider, and none of them exist unless you write them.

The model is not hallucinating. It is reproducing the documentation faithfully. The security gap is in the ecosystem, and the assistant inherits it.

Which failures actually matter?

Most of the 40 are hygiene — lifecycle policies, event notifications, tags on snapshots. Three patterns are worth stopping a merge for:

• Open ingress. The default security group example allows 0.0.0.0/0 on port 22. That is one finding, and it is the one that turns into an incident. Public exposure is consistently the most exploited misconfiguration class.
• Unencrypted data at rest. aws_db_instance has storage_encrypted off by default, and you cannot enable it on a running instance — you restore from a snapshot into a new encrypted one. Cheap to fix while it is text in an editor; a migration once it holds production data.
• Missing deletion protection. Not a breach, but the finding that costs the most when it fires.

Azure is the worst of the three clouds on defaults: a minimal azurerm_storage_account produced 3 critical and 2 high findings, largely because public network access and shared key authorisation are both enabled unless you turn them off.

Why does asking the AI to "make it secure" not solve this?

It helps, and it is unreliable. Ask for "a secure S3 bucket" and you will usually get a public access block and encryption. You will not consistently get your requirements — the regions you are allowed to deploy into, the retention your auditor expects, the tags your finance team bills on. The model does not know those, so it invents plausible ones.

It also depends on the developer remembering to ask, every time, forever. Any control that requires people to care is a control that decays.

What actually works: give the rules to the generator

The useful shift is moving the check from after generation to during it. Instead of the assistant writing Terraform and then a scanner telling it what is wrong, the assistant asks what the rules are before it writes anything.

That is what the Model Context Protocol makes possible. An MCP server runs alongside your assistant in Claude Code, Cursor, VS Code or Windsurf, and the assistant calls it while it works:

You:       "add an RDS instance for the orders service"
Assistant: → asks what the policy requires
           ← storage_encrypted = true
             backup_retention_period ≥ 365
             region ∈ eu-west-1, eu-central-1
           [writes Terraform satisfying all three]
           → scans its own output → clean

The violation is never written, so there is nothing to review, argue about or fix. That is a different economic proposition from catching it in a pull request three days later.

How do I set this up?

Sovereign Observer ships a free, open-source MCP server. It runs entirely on your machine — no account, no API key, and your Terraform is never uploaded.

claude mcp add sovereign -- uvx sovereign-observer

For Cursor, VS Code and Windsurf configurations see the package README. Once installed, the assistant scans what it writes without being asked, because the server tells it to.

If you also want the same rules enforced on pull requests and against your live cloud accounts, that is what Sovereign Observer does — one rule set in the editor, in CI, and in production.