Ask a platform engineer how much of their Terraform, Kubernetes manifests or CI/CD YAML was drafted with an AI assistant, and the honest answer is usually “most of it.” Ask the same engineer how much of that code was security-reviewed before it shipped, and the answer gets quieter. This gap — between how fast AI writes infrastructure and how carefully anyone checks it — is no longer a theoretical risk. It’s showing up in production, in audits and now in a growing public CVE record.
This isn’t about whether AI coding assistants are good or bad. They’re clearly useful, and they’re not going away. It’s about a specific, measurable failure mode that most CI/CD pipelines were never designed to catch, and what it takes to close that gap without slowing teams down to a crawl.
The Numbers Are Worse for Infrastructure Than for Application Code
IOActive’s April 2026 whitepaper, The Security Gap in AI-Generated Code, is the most rigorous test of this to date: 27 leading AI models, 730 real-world prompts spanning 27 languages, evaluated by 72 automated vulnerability detectors against roughly 20,000 generated code samples. The prompts deliberately didn’t mention security, because most developers don’t ask for it either. They just ask for working code, and that’s what they receive.
The topline finding was bad enough on its own: Average security performance across all models came in at 59%, and nearly a third of generated samples were fully exploitable. Not one model configuration tested clean — even the best-performing setup produced 90 distinct vulnerabilities across the sample set.
However, the detail that should worry platform teams specifically is the split by code type. Deployment infrastructure — containers, CI/CD configuration, serverless definitions — came back 57.5% vulnerable on average, noticeably worse than general application code. Dockerfiles were the single worst-performing artifact type in the entire study, with close to universal failure. IOActive’s researchers offer a plausible explanation: AI training data appears skewed toward application-code examples, leaving infrastructure as code (IaC) as a genuine blind spot in what these models learned to write safely. Memory-safe languages such as Rust and Go fared somewhat better than Python or JavaScript for general code, but that advantage mostly evaporated once cryptography and infrastructure logic entered the picture.
This isn’t an outlier finding from one lab. Veracode’s Spring 2026 GenAI Code Security Update, testing over 100 large language models across SQL injection, cross-site scripting, log injection and insecure cryptography, found that only about 55% of AI code-generation tasks produced secure code out of the box — a number that has barely moved in two years, even as syntax correctness climbed past 95% over the same period. Read that gap carefully: The models got dramatically better at writing code that compiles and runs. They did not get meaningfully better at writing code that’s safe to run. That’s the entire problem in one sentence.
From Lab Benchmark to Public CVE
Benchmarks tell you what a model is capable of getting wrong under test conditions. They don’t tell you what’s actually breaking in production. For that, there’s a live tracker worth paying attention to.
In May 2025, Georgia Tech’s Systems Software & Security Lab launched a project called Vibe Security Radar, run by researcher Hanqing Zhao, to answer a narrower and harder question than any lab benchmark: Not what AI models might produce, but what they have actually produced in software running in the real world. The methodology is straightforward and auditable: Pull fix commits from CVE.org, the National Vulnerability Database, the GitHub Advisory Database and OSV; trace each one back through Git history to find the commit that introduced the bug, then check that commit for an AI tool’s fingerprint — a co-author tag, a bot email address, a known tool signature. Where metadata alone isn’t conclusive, the team uses AI agents with direct access to the repository history to investigate causality rather than rely on pattern-matching.
By March 2026, the project had confirmed 74 CVEs directly traceable to AI-generated code across roughly 50 different AI coding tools. The trend line is the part that should get attention in a platform engineering context: Six confirmed cases in January 2026, 15 in February, 35 in March alone — more new AI-attributed CVEs in that single month than the project had confirmed across the second half of 2025. Zhao is explicit that this is a floor, not a ceiling: A large share of AI-assisted commits simply lack the metadata trail needed to trace them back to their origin, so the actual number of AI-linked vulnerabilities across the broader open-source ecosystem is likely 5–10 times higher than what’s currently confirmed.
Separately, security firm Wiz’s scan of thousands of AI-assisted (vibe-coded) applications turned up a related but distinct problem: Exposed secrets and credentials baked directly into shipped code and configuration, at a scale that suggests this isn’t a handful of careless teams; it’s a systemic pattern in how these tools get used day to day.
Design Your Pipeline Like the AI is a New Hire, Not a Senior Engineer
For years, shift security left meant getting static analysis into the developer’s IDE and the pull request, on the assumption that a human was making most of the meaningful design decisions and an AI tool was, at most, autocompleting a line or two. That assumption no longer holds. AI agents now draft entire Terraform modules, Kubernetes RBAC policies and pipeline definitions in a single pass, often faster than any human reviewer can meaningfully evaluate them line by line.
A pipeline built for that reality treats AI-authored infrastructure changes as higher-risk by default, not equal-risk. In practice, that means routing them through more automated scrutiny before a human ever sees them:
Developer (AI-assisted) commits code
│
▼
Pre-commit policy check (Block obvious anti-patterns)
│
▼
Terraform validate/helm lint (Does it actually parse correctly?)
│
▼
IaC misconfiguration scan (Checkov, tfsec or equivalent)
│
▼
Container/dependency scan (Trivy or equivalent)
│
▼
Policy as code check (OPA/Conftest — org-specific rules)
│
▼
Secret scanning (TruffleHog or equivalent)
│
▼
Provenance-flagged human review
│
▼
Merge → Deploy
The specific tools matter less than the shape of the pipeline: AI-authored infrastructure changes should pass through more automated gates than a routine change, not the same gates as everything else. A minimal GitHub Actions implementation of the scanning stages looks like this:
name: infra-security-gate
on:
pull_request:
paths:
– ‘**/*.tf’
– ‘**/Dockerfile’
– ‘.github/workflows/**’
jobs:
scan:
runs-on: ubuntu-latest
steps:
– uses: actions/checkout@v4
– name: Validate Terraform syntax
run: terraform validate
– name: Scan IaC for misconfigurations
uses: bridgecrewio/checkov-action@master
with:
directory: .
soft_fail: false
– name: Scan container images and dependencies
uses: aquasecurity/trivy-action@master
with:
scan-type: ‘fs’
severity: ‘CRITICAL,HIGH’
exit-code: ‘1’
– name: Check org policy compliance
uses: open-policy-agent/conftest-action@main
with:
policy: ./policy
files: ‘**/*.tf’
– name: Scan for exposed secrets
uses: trufflesecurity/trufflehog@main
with:
extra_args: –fail
None of this is exotic; it’s the same category of gate most teams already run for application code. The point is making sure infrastructure code gets it too, and that AI-authored changes specifically can’t skip the line.
A Maturity Model for Governing AI-Generated Infrastructure
Most platform teams already sit somewhere on this ladder, whether they’ve named it or not:
Level 1 — Manual Trust: AI writes infrastructure code; a human reviews it the same way they’d review any other pull request, with no special handling for the fact that an AI drafted it. This is where most teams are today, and it’s the least defensible position given what the IOActive and Veracode data show about baseline secure-output rates.
Level 2 — Automated Gates: IaC scanners, container scanners and secret detection run against every infrastructure change, AI-authored or not, before it can merge. This catches the mechanical failures — the exposed credential, the wide-open security group, the missing resource limit — without depending entirely on a reviewer’s attention span.
Level 3 — Provenance Tracking: AI-drafted changes are explicitly tagged through commit metadata, PR labels or CI checks, and routed to reviewers who know beforehand that this specific change needs closer scrutiny than a hand-written one. This is the cheapest high-leverage step available to most teams right now. It doesn’t require new tooling, just discipline about tagging and routing.
Level 4 — Continuous Infrastructure Security Scoring: Infrastructure code carries a security score that updates as models, prompts, scanners and organizational policy evolve, rather than a one-time pass/fail gate at merge time. Very few organizations are here yet, and it’s not necessary for most teams in 2026 — but it’s the direction the tooling ecosystem is heading as AI-authored infrastructure becomes the default rather than the exception.
Most teams reading this are at Level 1 or 2. Given where the CVE trendline is heading, Level 3 is the realistic near-term target: It costs little to implement, requires no new vendor relationship and converts “we hope someone reviews this carefully” into “we know this specific change needs careful review” — which is a meaningfully different guarantee.
What to Do This Week
Tag pull requests containing AI-drafted Terraform, Helm charts, Dockerfiles or pipeline YAML, so they route differently than routine changes.
Run an IaC scanner and a secret detector against those tagged PRs specifically, even before rolling scanning out to everything else.
Set AI agent tokens and service accounts to read-only by default. Widen access only through a deliberate, logged decision — never as the starting position.
Revisit these controls quarterly. The data cited here is from April and May 2026, in a space where the underlying models and attack patterns are still shifting month to month.
None of this is an argument against using AI to write infrastructure code — the productivity case is real and isn’t going anywhere. It’s an argument for treating AI-authored infrastructure the way any competent team already treats a change from a new engineer in their first week on the job: Often correct, genuinely useful and never trusted into production without someone who understands exactly what a broken IAM policy or an exposed secret actually costs. The next phase of platform engineering won’t be defined by how fast AI can generate infrastructure. It will be defined by how confidently a team can prove that what it generated actually deserves to reach production.
