{"id":4649,"date":"2026-07-24T06:05:18","date_gmt":"2026-07-24T06:05:18","guid":{"rendered":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2026\/07\/24\/ai-agents-are-writing-your-infrastructure-code-is-anyone-governing-it\/"},"modified":"2026-07-24T06:05:18","modified_gmt":"2026-07-24T06:05:18","slug":"ai-agents-are-writing-your-infrastructure-code-is-anyone-governing-it","status":"publish","type":"post","link":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2026\/07\/24\/ai-agents-are-writing-your-infrastructure-code-is-anyone-governing-it\/","title":{"rendered":"AI Agents Are Writing Your Infrastructure Code. Is Anyone Governing It?"},"content":{"rendered":"
\"\"<\/div>\n

\"\"<\/p>\n

AI agents and coding assistants<\/a> 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\u2019s Spring 2026 GenAI Code Security Update<\/a> 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 \u2018it compiles\u2019 and \u2018it\u2019s safe to run\u2019 is quickly becoming the defining infrastructure risk of 2026.<\/p>\n

This is not a hypothetical concern. It\u2019s 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.<\/p>\n

Infrastructure Code Volume is Exploding, AI is Driving It<\/h3>\n

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<\/a>).<\/p>\n

That volume increase would be manageable if AI-generated infrastructure code were reliably safe. It isn\u2019t. DevOps.com<\/a> recently highlighted this exact mismatch, noting that \u201cAI 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.\u201d 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.<\/p>\n

Platform engineering was already becoming the default operating model for managing this kind of complexity. Gartner<\/a> projects that 80% of large software engineering organizations will have dedicated platform engineering teams by 2026<\/em>, 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\u2019 mandate.<\/p>\n

What the Data Actually Shows About AI-Generated Infrastructure Code<\/h3>\n

It\u2019s worth being precise about where AI models fail, because not every vulnerability class is equally likely. Veracode\u2019s testing \u2014 run across 80 coding tasks, four languages and four critical vulnerability categories, evaluated against more than 150 large language models (LLMs) \u2014 found sharply uneven results:<\/p>\n

SQL Injection (CWE-89): 82% secure \u2014 models handle well-known, heavily documented patterns reasonably well.<\/p>\n

Insecure Cryptographic Algorithms (CWE-327): 86% secure \u2014 another \u2018easy win\u2019 category models have learned to avoid.<\/p>\n

Cross-Site Scripting (CWE-80): 15% secure \u2014 a persistent failure point.<\/p>\n

Log Injection (CWE-117): 13% secure \u2014 the single worst-performing category, and one directly relevant to logging and observability configuration in infrastructure code.<\/p>\n

Model size barely moves the needle. Even flagship 2026 releases \u2014 GPT-5.1 and 5.2, Gemini 3 and Claude 4.5 and 4.6 \u2014 cluster around the same 55% overall security pass rate as their predecessors. The one meaningful exception is reasoning-focused models, which reach 70\u201372%, still short of what most security teams would consider acceptable for unreviewed production deployment.<\/p>\n

This pattern maps directly onto infrastructure code. Identity & access configuration is exactly the kind of \u2018contextual reasoning\u2019 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.<\/p>\n

The financial exposure is well quantified. IBM and the Ponemon Institute\u2019s Cost of a Data Breach Report 2025<\/a>, which is based on 600 breached organizations, found that breaches spanning multiple environments cost <\/em>a<\/em>n average<\/em> of<\/em> $5.05 million to resolve<\/em>, 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.<\/p>\n

Why This is a Platform Team Problem, Not Just an AppSec One<\/h3>\n

It\u2019s tempting to file \u2018AI writes insecure code\u2019 under application security and move on. That framing misses what\u2019s actually happening in infrastructure, specifically. Application code vulnerabilities are typically confined to a single service. Infrastructure code vulnerabilities \u2014 an overly permissive IAM policy, an open security group, a misconfigured storage bucket \u2014 can expose an entire environment.<\/p>\n

That\u2019s 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 \u2018correct\u2019 infrastructure looks like before a single line of Terraform gets written, whether by a human or an agent. Gartner\u2019s 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.<\/p>\n

The industry data on infrastructure drift reinforces why \u2018review after the fact\u2019 isn\u2019t sufficient. The DORA 2023 State of DevOps Report<\/a> found that teams experiencing frequent configuration drift had 2.3 times higher change failure rates<\/em> 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.<\/p>\n

What Governance Actually Looks Like for Agent-Generated Infrastructure<\/h3>\n

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:<\/p>\n