AI agents and coding assistants now generate a growing share of the Terraform, Kubernetes and cloud configuration code running in production, but the security quality of that code has not improved in step with its volume. Veracode’s Spring 2026 GenAI Code Security Update found that only 55% of AI code-generation tasks produce secure code out of the box, a number that has barely moved in two years, even as syntax correctness surpassed 95%. For platform engineering, DevOps and SRE teams, that gap between ‘it compiles’ and ‘it’s safe to run’ is quickly becoming the defining infrastructure risk of 2026.
This is not a hypothetical concern. It’s showing up in the numbers, in the incident reports and in the conversations platform teams are having right now about who or what is actually allowed to touch production infrastructure.
Infrastructure Code Volume is Exploding, AI is Driving It
Infrastructure as code (IaC) used to be authored almost entirely by humans, reviewed by humans and merged by humans. That model is breaking down. As generative AI (GenAI) tools embed themselves into developer workflows, teams are generating infrastructure definitions faster than review processes were ever designed to handle. Recent platform engineering research found that 71% of cloud teams have seen a measurable increase in IaC volume directly attributable to GenAI (env0, 2026).
That volume increase would be manageable if AI-generated infrastructure code were reliably safe. It isn’t. DevOps.com recently highlighted this exact mismatch, noting that “AI coding assistants can generate pull requests faster than most teams can review them, and that mismatch is creating a new kind of bottleneck across engineering organizations.” Engineering leaders are left with two bad options: Slow everything down to manually review every AI-generated change or accept a growing volume of unreviewed risk moving into production.
Platform engineering was already becoming the default operating model for managing this kind of complexity. Gartner projects that 80% of large software engineering organizations will have dedicated platform engineering teams by 2026, up from roughly 45% in 2022. This shift was originally driven by developer self-service and toolchain consolidation. In 2026, governing AI-generated infrastructure has become just as central to platform teams’ mandate.
What the Data Actually Shows About AI-Generated Infrastructure Code
It’s worth being precise about where AI models fail, because not every vulnerability class is equally likely. Veracode’s testing — run across 80 coding tasks, four languages and four critical vulnerability categories, evaluated against more than 150 large language models (LLMs) — found sharply uneven results:
SQL Injection (CWE-89): 82% secure — models handle well-known, heavily documented patterns reasonably well.
Insecure Cryptographic Algorithms (CWE-327): 86% secure — another ‘easy win’ category models have learned to avoid.
Cross-Site Scripting (CWE-80): 15% secure — a persistent failure point.
Log Injection (CWE-117): 13% secure — the single worst-performing category, and one directly relevant to logging and observability configuration in infrastructure code.
Model size barely moves the needle. Even flagship 2026 releases — GPT-5.1 and 5.2, Gemini 3 and Claude 4.5 and 4.6 — cluster around the same 55% overall security pass rate as their predecessors. The one meaningful exception is reasoning-focused models, which reach 70–72%, still short of what most security teams would consider acceptable for unreviewed production deployment.
This pattern maps directly onto infrastructure code. Identity & access configuration is exactly the kind of ‘contextual reasoning’ problem the Veracode report flags as an LLM weak point, since it requires tracking how permissions and data flow across dozens of resources rather than pattern-matching a single line. That helps explain the documented rise in identity-related misconfigurations in AI-assisted environments, the same general class of issues implicated in a large share of cloud security incidents industry-wide. When AI agents are the ones defining identity & access management (IAM) roles, security groups and network policies at scale, the cost of getting this wrong compounds fast.
The financial exposure is well quantified. IBM and the Ponemon Institute’s Cost of a Data Breach Report 2025, which is based on 600 breached organizations, found that breaches spanning multiple environments cost an average of $5.05 million to resolve, while public cloud breaches average $4.18 million and cross-environment incidents take 276 days to identify and contain, 59 days longer than on-premises breaches. Every one of those breaches started with a configuration that someone or something created and nobody governed.
Why This is a Platform Team Problem, Not Just an AppSec One
It’s tempting to file ‘AI writes insecure code’ under application security and move on. That framing misses what’s actually happening in infrastructure, specifically. Application code vulnerabilities are typically confined to a single service. Infrastructure code vulnerabilities — an overly permissive IAM policy, an open security group, a misconfigured storage bucket — can expose an entire environment.
That’s precisely why platform engineering, not just AppSec, has to own this problem. Platform teams are the ones who define the paved road: The templates, modules and guardrails that determine what ‘correct’ infrastructure looks like before a single line of Terraform gets written, whether by a human or an agent. Gartner’s platform engineering guidance is explicit that internal platforms exist to give developers safe, reviewed defaults rather than open-ended tooling access, and that mandate now has to extend to AI agents as first-class consumers of the platform, not exceptions to it.
The industry data on infrastructure drift reinforces why ‘review after the fact’ isn’t sufficient. The DORA 2023 State of DevOps Report found that teams experiencing frequent configuration drift had 2.3 times higher change failure rates than teams with consistent IaC hygiene. AI-generated infrastructure changes, applied quickly and often outside a slow, deliberate review cycle, are a direct accelerant for exactly this kind of drift.
What Governance Actually Looks Like for Agent-Generated Infrastructure
Governing AI-generated infrastructure code in 2026 looks different from the manual code review model most teams still default to. Four capabilities now show up consistently in mature platform engineering practices:
- Policy as Code Enforced Before Generation, not After: Waiting for a CI/CD pipeline to catch a policy violation means an engineer or an agent has already spent cycles producing code that gets rejected. Teams using pre-plan policy validation with tools such as HashiCorp Sentinel report a 45% reduction in policy violation-related build failures compared to teams enforcing policy only after the plan stage. The lesson generalizes directly to AI-generated infrastructure: Constraints belong upstream of generation, not downstream of it.
- RBAC and Identity Scoping That Treats Agents as First-Class Actors: Mature platforms are extending role-based access control (RBAC), resource quotas and audit logging to AI agents the same way they would to a new hire — with scoped permissions, not blanket production access. This matters because a significant share of developers reportedly fails to adjust default permission scopes in AI-generated code before deployment, a pattern that becomes far riskier when the ‘developer’ is an autonomous agent operating at machine speed.
- Continuous Drift Detection With Automated Correction, not Just Alerts: The days of drift detection tools that simply notify a human and wait are ending. Platform teams increasingly expect infrastructure to self-correct: Reverse unauthorized changes, reconcile state automatically and flag only the exceptions that genuinely require judgment.
- Compliance Validation Built Into the Generation Step Itself: Rather than generating infrastructure code and then scanning it for problems, the more resilient pattern is validating intent against organizational policy at the moment of generation, so the code that comes out the other side is compliant by construction, not by correction.
Closing the Gap: Governing Infrastructure From Intent
This is the exact problem StackGen’s intent-to-infrastructure platform was built to address. Instead of treating AI-generated Terraform and Kubernetes manifests as raw output that still needs a separate governance layer bolted on afterward, StackGen translates infrastructure intent — expressed in natural language or high-level policy — directly into infrastructure code that is validated against organizational security and compliance standards as it’s generated, not after the fact.
That distinction matters given what the Veracode data shows: Security failures cluster in exactly the areas requiring contextual, cross-resource reasoning — identity, access scope, log handling — rather than isolated syntax errors a linter would catch. StackGen’s approach pairs generation with policy enforcement so that platform teams retain control over what ‘correct’ infrastructure looks like, while developers and AI agents alike can request infrastructure without needing to be Terraform or IAM experts themselves. Role-specific capabilities — including Aiden for Platform Engineering and Aiden for Governance — extend this further into drift detection, remediation and continuous compliance, so infrastructure stays aligned with policy long after the initial deployment, whether the original change came from a person or an agent.
A Practical Checklist for Governing AI-Generated Infrastructure
For platform, DevOps and SRE teams evaluating where they stand today, five questions are worth answering honestly:
- Can you identify which infrastructure changes in the last quarter were AI-generated? If the answer is no, you have a visibility gap before you have a governance gap.
- Do AI agents operate under the same RBAC and quota constraints as your most junior engineer, or do they have broader effective access?
- Is policy validated before infrastructure code is generated, or only after it’s submitted for review?
- Does your drift detection auto-remediate, or does it just add another alert to an already-saturated queue?
- Could you produce an audit trail today showing who or what approved a specific production infrastructure change?
Teams that can’t answer all five confidently aren’t behind because AI adoption outpaced them technically. They’re behind because governance was designed for a world where every infrastructure change had a human name attached to it. That world is already gone for a meaningful share of production changes, and that’s where StackGen’s Aiden for Infrastructure helps create infrastructure, keeping these guardrails.
Frequently Asked Questions
- Can AI agents write secure infrastructure code?
Not reliably without guardrails. Veracode’s 2026 testing found that AI models produce secure code in only about 55% of generation tasks overall, with particularly weak performance on vulnerability classes that require contextual reasoning, such as identity & access configuration.
- What is infrastructure-from-code governance?
Infrastructure-from-code governance refers to enforcing security, compliance and access policies at the moment infrastructure code is generated — whether by a human or an AI agent — rather than relying solely on post hoc review or scanning.
- Why does platform engineering matter for AI infrastructure risk?
Platform engineering teams define the templates, guardrails and self-service workflows that determine what infrastructure gets deployed. As AI agents generate a growing share of that infrastructure, platform teams are the natural owners of the policy layer that governs agent behavior.
- What’s the business cost of ungoverned AI-generated infrastructure?
According to IBM and the Ponemon Institute’s Cost of a Data Breach Report 2025, breaches spanning multiple cloud environments cost an average of $5.05 million and take 276 days to identify and contain, underscoring the financial stakes of ungoverned configuration drift.
The Bottom Line
AI has already changed who or what is writing infrastructure code. It hasn’t yet changed how that code gets governed at most organizations, and that gap is where the next wave of cloud incidents will come from. Platform teams that extend policy as code, RBAC and continuous compliance to AI agents now — rather than treating agent-generated infrastructure as a special case — will be the ones who capture AI’s productivity gains without inheriting its security debt.