Skip to content
OTFotf
All posts

AI-driven infrastructure incidents are the new normal: governing vibe-coded IaC

D
DaveAuthor
6 min read
AI-driven infrastructure incidents are the new normal: governing vibe-coded IaC

AI now writes infrastructure code faster than most teams can govern it. Ask a coding agent for a Terraform module, a Kubernetes manifest, or an IAM policy and you get plausible, working-looking output in seconds — output that can open a security group to the world, skip encryption defaults, or drift from compliance baselines without a single human noticing. The failure pattern is consistent across teams adopting AI-generated infrastructure as code: generation speed scales instantly, while review, policy enforcement, and attribution stay manual. That gap — between how fast AI changes infrastructure and how slowly governance catches up — is the risk surface this post is about.

What AI-caused infrastructure incidents look like

The incidents are rarely exotic. They are ordinary misconfigurations produced at machine speed and deployed with human-level trust. The recurring taxonomy:

  • Security misconfigurations. Overly permissive IAM roles, publicly exposed databases or storage buckets, security groups opened wider than intended. An agent optimizing for "make it work" routinely trades least privilege for connectivity.
  • Compliance drift. Required guardrails — encryption at rest, resource tagging, backup policies, region constraints — silently skipped because the prompt never mentioned them and the model was never told they were mandatory.
  • Unplanned outages. Faulty generated IaC applied through a pipeline: conflicting changes, broken module references, state mismatches. The error slips through review because the diff looks reasonable and nobody ran a plan against production state.
  • Siloed, unattributable change. An agent modifies infrastructure outside the team's normal workflow, and legacy monitoring cannot answer "who changed this and why" because the change never passed through a human decision point.

None of these require a sophisticated attacker. They require only an agent with write access and a team measuring yesterday's metrics. That combination is now common, which is why governance — not model quality — is the bottleneck.

Why governance lags generation

Three structural reasons, all fixable, none fixed by default.

First, review processes were designed for human-paced change. A pull request review that catches a bad security group rule works when engineers open a handful of infra PRs a week. When agents generate dozens a day, the same review step becomes a rubber stamp — approved on vibe, not on verification. Throughput went up much faster; scrutiny stayed flat.

Second, teams measure pre-AI signals. Deployment frequency, lead time, change-failure rate — the standard DORA family — describe the delivery system, not the author. Almost nobody tracks the AI-specific signals that would reveal whether governance is working: what share of applied IaC was agent-authored, what the error or rollback rate on agent-authored change looks like, how long AI-introduced misconfigurations survive before detection. Without those measurements, "our process handles AI changes fine" is a guess, and the incident record usually contradicts it.

Third, policy enforcement sits outside the generation loop. The agent writes code in one context; policy checks run later, optionally, in CI — if they exist at all. Anything the pipeline does not enforce is a suggestion, and agents are excellent at satisfying the letter of a suggestion while missing its intent. Governance that is not executable is documentation, and documentation does not stop 0.0.0.0/0.

11 production screens. Login, database, payments — all wired.

The SaaS Dashboard Kit ships everything already connected. Nothing to set up. Live demo at saas.otf-kit.dev.

See the live demo

The governance playbook that actually works

Closing the gap is unglamorous work, but it is bounded and well understood. In priority order:

1. Measure the AI-authored share. Start tracking how much of your applied infrastructure change was generated or materially modified by agents, plus the rollback and incident rate on that subset. This is the baseline everything else depends on. If you cannot distinguish agent-authored from human-authored change in your pipeline metadata, fix that first — attribution is the prerequisite for every control below.

2. Make policy executable, not advisory. Policy-as-code belongs in the critical path of every AI-generated change: least-privilege enforcement, mandatory tagging and encryption, backup and region constraints, evaluated on every plan before apply. The Open Policy Agent ecosystem is the canonical example of the pattern — declarative policies evaluated against structured input, which is exactly what IaC plans are. Human review then handles intent ("should we build this at all") while machines handle invariants ("is this compliant"), which is the correct division of labor at agent throughput.

3. Require plan-before-apply with teeth. No agent-authored infrastructure change should reach production without a generated plan, a policy evaluation, and a human approval for anything outside pre-authorized boundaries. Pre-authorized low-risk change classes (tag updates, replica count within bounds) can auto-apply; everything else queues. The boundary definitions are themselves policy — versioned, reviewed, auditable.

4. Standardize telemetry so agents and auditors share truth. When an incident happens, "which change caused this" must be answerable in minutes. Standardized instrumentation is what makes that possible: OpenTelemetry is the vendor-neutral open-source standard for traces, metrics, and logs, supported by more than 90 observability vendors (OpenTelemetry docs). If your IaC pipeline, your policy evaluations, and your runtime telemetry all speak standard formats, both your incident responders and your future SRE agents can trace a failure from symptom to the exact agent-authored diff. The same discipline that makes production background jobs observable applies to the infrastructure those jobs run on.

5. Treat agent permissions like deploy permissions. Least privilege, scoped to the task, revocable, with break-glass paths that page a human. An agent that can rewrite IAM policy is not a coding assistant — it is a privileged operator, and it should be provisioned like one. The AI app security checklist covers the access-control side of this in detail.

Where governance platforms fit

This is also a tooling category, not just a discipline. Infrastructure orchestration platforms now compete partly on governance depth: Spacelift, for example, is a real IaC orchestration platform covering Terraform, OpenTofu, CloudFormation, Pulumi, and Kubernetes, with policy enforcement and drift detection in its feature set (Spacelift). Whether you buy that layer or build it from scanners and policy engines, the evaluation criterion is the same: does the platform constrain, audit, and attribute agent output — or does it just deploy faster? Deployment speed without governance is the problem, not the solution. Data-layer controls matter too: if your agents touch production data paths, the RLS production checklist is the database-side companion to everything above.

The bottom line: govern the author, not just the code

AI-caused infrastructure incidents are not a model-quality problem. The models do what they are asked; the incidents come from asking at machine speed inside governance designed for human speed. Teams that baseline their agent-authored share, enforce policy as code, require plan-before-apply, standardize telemetry, and permission agents like operators will absorb AI-assisted infrastructure safely. Teams that keep pre-AI processes while scaling AI output will keep collecting incidents — and the blast radius grows with every automation step they add without guardrails.

The ask is concrete: invest in governance before the incident, not as the postmortem action item. Pick the boring controls once, automate them into the pipeline, then let agents move fast inside boundaries that hold.

Ship the app layer on the same principle: OTF kits give your coding agent a production-shaped starting point — auth, billing, database, and deploy wiring already done — so agent-generated features land inside an architecture that was designed to be governed. Browse the kits →

Sources

  • Spacelift — confirms Spacelift as an IaC orchestration platform (Terraform, OpenTofu, CloudFormation, Pulumi, Kubernetes) with policy and drift-detection positioning.
  • OpenTelemetry documentation — confirms OTel as the vendor-neutral open-source standard for traces, metrics, and logs, supported by more than 90 observability vendors.
ai-toolsbackendagents
OTF SaaS Dashboard Kit

Ship the product, not the setup.

  • 11 production screens — auth, billing, team, analytics, settings
  • Real database, payments, and login — all wired on day 1
  • AI configs pre-tuned so your agent extends instead of regenerates
Need more than components?

Full-stack kits.
Pay once, own the code.

Auth, database, and payments already connected — so you ship product, not setup. Or take every kit in the Bundle.

Everything Bundle — $149See full pricing

Get the free AI configs pack

Pre-tuned AI configs for Cursor, Claude, and Lovable — drop them in and your AI tool instantly understands your project.

No spam. Unsubscribe any time.

Prefer the free SDK? Star it on GitHub →