AI Passes Coding Tests 86% of the Time. On Infrastructure Code, It Passes 19%.

When GPT-4 was tested on 458 real-world AWS Terraform scenarios for a NeurIPS 2024 benchmark called IaC-Eval, it produced a working, correct configuration on the first try only 19.36% of the time. The same model scored 86.6% on equivalent Python coding tasks in a separate benchmark. Same model, four times worse at infrastructure than at application code.

That gap hasn't closed with newer models. A 2026 study accepted at FSE, called DPIaC-Eval, tested six frontier LLMs across 153 real-world infrastructure-as-code tasks. First-attempt deployment success ranged from 20.8% to 30.2%. When the output was filtered through standard Checkov policy checks instead of just "did it deploy," the pass rate dropped to 8.4%.

Meanwhile, according to Sonar's 2026 State of Code Developer Survey, 42% of code being committed today is written or assisted by an AI agent, a share expected to reach 65% by 2027. More AI-generated infrastructure code is shipping, at a moment when that code is measurably less reliable than the application code sitting next to it.

Security researchers tracking AI-generated Terraform describe four recurring failure patterns: permissive defaults, missing security blocks, hardcoded values, and stale provider patterns that no longer match current schema. These map directly onto the misconfigurations behind real cloud breaches, not theoretical edge cases.

The uncomfortable part is that terraform validate and terraform plan won't catch most of this. Those commands check syntax and confirm what will change in your state, not whether the resulting security posture is sound. A configuration can pass both checks cleanly and still open a bucket to the internet.

There's a subtler failure mode too. LLMs occasionally generate infrastructure code that's syntactically valid but semantically empty. A Terraform provider attribute that doesn't actually exist gets silently ignored by terraform plan rather than rejected. A Kubernetes manifest annotation with a made-up prefix does nothing at all. The apply succeeds. The dashboard looks fine. But the security control the developer thought they were configuring was never actually applied, and nothing in the standard toolchain says so.

It's not only Terraform and Kubernetes manifests written with AI assistance that carry this risk. The infrastructure organizations are standing up specifically to run AI workloads and agents shows the same misconfiguration pattern, often at the default settings level. Microsoft's security team found that 15% of remote MCP servers allow unauthenticated access to sensitive internal systems, including ticketing platforms, HR systems, and private code repositories, because the server executes tool actions in its own security context rather than the calling user's. They also documented cases where popular AI orchestration platforms, deployed through their own official Helm charts using default settings, exposed the application directly to the internet or stored API keys as plainly reversible Base64-encoded Kubernetes secrets rather than proper encrypted secrets.

The through-line is the same one running through Terraform and Kubernetes misconfigurations generally: a default that was reasonable for a quick local test becomes a serious exposure the moment it's deployed as-is to a real environment, and nothing in the standard deploy process stops to ask whether that default is still appropriate.

None of this is new in kind, only in scale. The 2019 Capital One breach that exposed 106 million customer records traced back to a WAF execution role with an IAM policy broad enough to list and read any S3 bucket in the account. A policy-as-code scanner would have flagged that overly permissive grant before it ever reached production. In 2023, a misconfigured Azure storage account exposed 38TB of internal data, including credentials and private messages. In 2024, a healthcare provider's Kubernetes cluster exposed patient records because its API server was reachable from the public internet without authentication, a pattern that standard scanners like Checkov and KICS are built specifically to catch.

Verizon's Data Breach Investigations Report analysis found misconfiguration accounts for 21% of breaches in cloud-heavy environments. AI-generated infrastructure code doesn't remove the human error element. It just moves it earlier and makes it faster to reproduce at scale, since a flawed pattern in a Terraform module gets copied every time the module is reused.

Catching this requires a layer that understands security posture, not just syntax: a policy engine that scans every deployment against known-good baselines for IAM, network exposure, encryption, and container privileges, before the change reaches production. That baseline matters because it's the reference point everything else gets measured against: without a defined "golden" configuration for what secure looks like on your infrastructure, a scanner has nothing to compare a new deployment to beyond generic, one-size-fits-all rules.

Drift detection matters just as much as pre-deployment scanning, and for a specific structural reason. Terraform applies changes when someone runs it, so a mistake sits there until the next deliberate update. Kubernetes is different: its controllers continuously reconcile the live cluster toward whatever is declared in the manifest, which means a misconfiguration doesn't just get applied once, it gets actively re-enforced every time the controller reconciles state, including after someone manually fixes it in a console out of band. Catching that requires ongoing comparison between the declared configuration and what's actually running, with alerts the moment the two diverge.