Infrastructure-as-Code Meets Agentic AI

Infrastructure-as-Code gave cloud teams a way to describe their systems as text. Agentic AI gives those same teams a way to act on that text — continuously, contextually, and at a speed no on-call rotation can match. The organizations pulling ahead in 2026 are not the ones with the most Terraform modules; they are the ones that have wired reasoning agents directly into the IaC lifecycle, closing the loop between drift detection, cost anomaly, security exposure, and remediation.

The shift from declarative to adaptive infrastructure

Infrastructure-as-Code solved a real problem: configuration drift, snowflake servers, and undocumented tribal knowledge about how production actually got into its current state. Tools like Terraform, Pulumi, AWS CDK, and Crossplane made infrastructure reproducible, reviewable, and version-controlled. But IaC on its own is fundamentally static. A Terraform plan describes a desired end state; it says nothing about how the environment should behave between applies, how it should respond to a cost spike at 2 a.m., or how it should react when a dependency in a shared module suddenly exposes an unintended security group rule to the internet.

That gap — between the declared state and the live, constantly drifting reality of cloud infrastructure — is where most operational toil lives. Engineers spend their time not writing new modules but chasing drift, triaging cost alerts, reconciling tags, and manually verifying that a "temporary" firewall rule opened during an incident got closed again. Agentic AI targets exactly this gap. An agent with read access to your state files, your cloud provider APIs, your observability stack, and your ticketing system can continuously compare declared state to actual state, reason about the delta, and either propose or execute a corrective action within policy guardrails.

This is a genuine architectural shift, not a rebrand of existing automation. Traditional automation (Ansible playbooks, Lambda-triggered remediation, Config Rules with SSM documents) is deterministic: if condition X, run action Y. Agentic systems introduce a reasoning layer that can synthesize multiple weak signals, weigh trade-offs described in natural language policy, and select from a broader action space than any single hard-coded runbook. The distinction matters operationally: deterministic automation breaks the moment reality deviates from the anticipated pattern; an agent with tool access and a capable model can handle the long tail of conditions nobody wrote a rule for.

Reference architecture: the closed control loop

A production-grade agentic IaC architecture has five layers, and skipping any of them is where most pilot projects fail. The layers are: state and inventory, observation and telemetry, reasoning, action, and governance. Each layer has to be independently addressable because the failure modes are different at each one — a reasoning bug is a different class of incident than a stale inventory cache, and both are different from an over-permissioned action executor.

State and inventory layer

This is your source of truth: Terraform/OpenTofu state files (ideally in a remote backend with locking, such as S3 + DynamoDB or Terraform Cloud), Pulumi state, Crossplane resource graphs, and a live-scanned CMDB that continuously re-reads actual cloud API responses rather than trusting the last apply. The critical design point is that agents must never reason purely off the declared state; they need a reconciled view that merges declared state with live-scanned actual state, with every delta tagged, timestamped, and attributed to a cause (manual change, drift, out-of-band automation, or a failed apply).

Observation and telemetry layer

Metrics, logs, traces, cost and usage reports (AWS CUR, Azure Cost Management exports, GCP Billing export to BigQuery), CSPM/CNAPP findings, and vulnerability scan results all feed into this layer. The key requirement is normalization: an agent reasoning across AWS, Azure, and on-prem VMware needs a common schema for "this resource is over-provisioned" or "this resource has a critical CVE," not three different vendor-specific payload shapes it has to special-case in its own logic.

Reasoning layer

This is where the LLM-driven agent lives. It ingests the reconciled state, current telemetry, and a policy corpus (written largely in structured natural language plus machine-checkable constraints), and produces a ranked set of candidate actions with a rationale and a confidence score. Critically, the reasoning layer should be composed of narrower, task-specific agents — a cost-optimization agent, a security-remediation agent, a reliability agent — coordinated by an orchestrator, rather than one monolithic agent trying to hold all context at once. This mirrors how an AI-native operations stack is typically composed: specialized reasoning components with a shared context layer, not a single undifferentiated model call.

Action layer

Actions are executed through the same IaC tooling humans use — a `terraform plan`/`apply` cycle, a Pulumi update, a Crossplane composition patch, or a cloud-native API call wrapped in a tested module — never through improvised, unversioned scripts the agent writes on the fly. This is the layer where policy-as-code (OPA/Rego, Sentinel, Kyverno) gates every proposed change before it touches production.

Governance layer

Every agent action is logged with the same rigor as a human-initiated change: who (or which agent) proposed it, what evidence supported it, what policy check it passed, who approved it (if approval was required), and what the observed outcome was. This audit trail is not optional instrumentation; it is what makes autonomous remediation defensible to auditors, regulators, and your own incident review process.

FinOps: from monthly reports to continuous, autonomous cost control

Cloud cost management has historically been a lagging discipline: a FinOps team pulls a Cost and Usage Report, builds a dashboard, and presents last month's overspend in a review meeting three weeks after the money was spent. Agentic AI collapses that latency from weeks to minutes by treating cost as a first-class signal in the same reconciliation loop that watches for drift and security exposure.

Concretely, a cost-reasoning agent needs three inputs continuously: the current resource inventory (from the state layer), the unit economics of each resource type (on-demand vs. reserved vs. spot pricing, savings plan coverage, committed-use discounts), and a mapping of resources to cost centers via tagging or a service catalog. With those three inputs, the agent can do far more than alert on an anomaly — it can propose and, within guardrails, execute a specific remediation: rightsizing an EC2 instance whose CPU utilization has sat below 8% for fourteen days, converting an idle NAT Gateway to a shared one, deleting orphaned EBS volumes and unattached Elastic IPs, or shifting a batch workload to spot capacity with a documented interruption-handling strategy already present in the IaC module.

The important discipline here is that every cost action the agent takes must be expressed as an IaC change, not an imperative API call outside the codebase. If an agent resizes an instance by calling the EC2 API directly, the Terraform state now disagrees with reality, and the next `terraform plan` will either revert the optimization or produce a confusing diff for the next engineer who touches that module. The correct pattern is: the agent opens a change against the IaC repository (a pull request with the resized instance type, or a Terraform variable override), runs it through the existing CI pipeline including `terraform plan`, gets it policy-checked, and only then applies it — either automatically for pre-approved low-risk categories, or via human approval for anything touching production-tier workloads.

A worked example: rightsizing loop

Consider a fleet of 340 EC2 instances backing an internal analytics platform. A cost agent ingests 14 days of CloudWatch CPU, memory (via the CloudWatch agent), and network utilization, cross-references against the Terraform module defining the instance type, and identifies 47 instances running at less than 15% average CPU on `m5.2xlarge` when `m5.large` would clear the 95th-percentile peak with 30% headroom. Rather than resizing directly, the agent generates a Terraform variable diff, runs `terraform plan` in a scratch workspace, attaches the projected monthly savings (calculated from the provider's pricing API, not a static table), and opens a PR tagged for the platform team. Because this workload has no PCI or SOX classification and the change matches a pre-approved risk tier, the policy engine auto-merges after a 4-hour objection window and a canary batch of 5 instances is resized first, monitored for 24 hours, before the remaining 42 are rolled out. Total time from anomaly detection to full remediation: under 48 hours, versus the multi-week cycle a manual FinOps review would take.

Reliability engineering: agentic remediation inside the SRE toolchain

Site reliability engineering has always had an uneasy relationship with automation. Runbook automation reduces mean-time-to-resolution for known failure modes, but it is brittle against novel ones, and over-aggressive auto-remediation has caused its own share of outages when a script "fixed" a symptom while masking a root cause that then compounded. Agentic AI changes the risk calculus by adding a reasoning step between detection and action: instead of "alert fires, run script," the sequence becomes "alert fires, agent gathers context, agent proposes a diagnosis with supporting evidence and a confidence score, agent selects an action proportional to both the confidence and the blast radius, action executes with a rollback plan pre-staged."

This matters most for the incidents that don't fit a pre-written runbook. A classic example: a service degrades not because of a single obvious cause but because of an interaction — a recent deploy increased connection pool size, which combined with a database failover event to exhaust connections on a downstream dependency neither team was watching closely. A rule-based system needs someone to have anticipated this exact interaction. A reasoning agent with access to deployment history, the service dependency graph, database failover events, and connection pool metrics can correlate these signals in real time and propose the correct fix — temporarily capping the connection pool via a config change already defined in IaC — without a human having pre-written that specific runbook.

Auto-remediation risk tiers

Not all remediation should be autonomous, and the maturity model matters. A practical tiering scheme most SRE organizations converge on:

• Tier 0 — observe only: the agent detects and explains, takes no action. Used for new failure signatures until enough history exists to trust the pattern.
• Tier 1 — propose with approval: the agent drafts the exact remediation (a PR, a scaling change, a config rollback) and requires a human click to execute. This is where most organizations should start.
• Tier 2 — auto-execute with rollback: low-blast-radius, well-understood actions (scaling a stateless service, restarting an unhealthy pod, rotating a credential nearing expiry) execute automatically, with an automatic rollback trigger if health checks don't recover within a defined window.
• Tier 3 — auto-execute, no rollback path needed: reserved for actions that are inherently safe and idempotent, such as re-tagging a resource or refreshing a stale cache entry.

Promotion from Tier 1 to Tier 2 should require a documented track record — typically a minimum number of successful human-approved executions of that exact action class with zero false positives — not a subjective comfort level. This is the same discipline used for canary rollout of application code, applied to the automation itself.

Reliability agents also change how post-incident review works. Instead of an engineer manually reconstructing a timeline from scattered logs, the agent that participated in triage has already produced a structured record: what it observed, what it hypothesized, what evidence it weighed, what it recommended or did, and what the outcome was. This becomes the first draft of the postmortem, which a human then reviews, corrects, and finalizes — a meaningful reduction in the multi-hour effort postmortems typically require, and a more accurate one, because it's assembled from real-time evidence rather than reconstructed memory.

Security: continuous exposure management over point-in-time scanning

The security implications of agentic IaC cut both ways, and this section deserves the most caution of any in this article. On the defensive side, an agent with continuous visibility into IaC repositories, live cloud state, and vulnerability feeds can close the gap between "a misconfiguration exists" and "a misconfiguration is fixed" from the industry-typical weeks to hours. On the offensive side, giving an autonomous system write access to production infrastructure is exactly the kind of high-privilege, high-blast-radius capability that attackers, insider threats, and simple agent errors can exploit catastrophically if governance is weak.

The mature pattern is to treat infrastructure security posture the same way continuous threat exposure management treats the broader attack surface: continuous discovery, continuous validation, and prioritized, evidence-based remediation, rather than periodic point-in-time audits. Applied to IaC specifically, this means an agent continuously diffs every Terraform/Pulumi/CloudFormation template against a security baseline (CIS Benchmarks, NIST 800-53 mappings, or a custom internal baseline), continuously re-scans live infrastructure for drift away from that baseline, and prioritizes findings not by raw CVSS score but by actual exploitability and blast radius in your specific environment — an internet-facing S3 bucket with a public-read ACL and PII in it is a different priority than the same misconfiguration on an internal, VPC-only test bucket with synthetic data.

Concrete hardening workflow

A security remediation agent operating on IaC should follow a workflow with four checkpoints, each of which produces an artifact a human can audit after the fact:

1. Detection: the agent identifies a security group, IAM policy, storage bucket, or KMS configuration that violates policy — either newly introduced in a pull request (shift-left, via a pre-merge check) or drifted in live infrastructure (shift-right, via continuous scanning).
2. Impact assessment: the agent determines what is actually exposed — which workloads use the affected resource, what data classification applies, whether the resource is internet-reachable, and whether there is any evidence of exploitation in logs (unusual access patterns, anomalous API calls from the affected principal).
3. Remediation proposal: the agent generates the corrected IaC diff — the tightened security group rule, the scoped-down IAM policy, the bucket policy with public access blocked — and runs it through the same CI/CD pipeline as any human change, including a plan step that shows exactly what will change.
4. Execution and verification: for high-severity, high-confidence findings on non-production resources, execution can be automatic; for anything touching production or carrying ambiguity, a human approves. After execution, the agent re-scans to confirm the finding is actually resolved and did not introduce a new one.

This loop is where identity infrastructure deserves particular attention, because IAM misconfigurations are consistently among the highest-impact cloud security findings and among the hardest for humans to reason about at scale — a single overly broad trust policy or an unused role with `AdministratorAccess` sitting dormant for a year is invisible in a spreadsheet but obvious to an agent that continuously correlates role usage against granted permissions. Programs built around identity and privileged access management increasingly rely on this kind of continuous, automated least-privilege enforcement rather than periodic access reviews, because the rate of IAM policy change in a modern cloud account — new roles, new service accounts, new federated identities — outpaces any quarterly review cycle.

The alert-triage side of this is equally important. Security teams drowning in CSPM and CNAPP findings need automated correlation and prioritization before any remediation conversation is even useful — the same problem AI-driven alert triage solves for detection telemetry applies directly to infrastructure findings: thousands of raw findings collapse into a much smaller number of prioritized, deduplicated, root-caused issues an agent (or a human) can actually act on in a shift.

Wiring agents to infrastructure: MCP, tool access, and the blast-radius problem

The practical mechanism by which an agent reasons over Terraform state and cloud APIs matters as much as the model doing the reasoning. Most production deployments now standardize on the Model Context Protocol (MCP) or an equivalent tool-calling abstraction, where the agent is given a defined, auditable set of tools — `read_terraform_state`, `plan_change`, `query_cost_explorer`, `list_security_findings` — rather than raw shell or API access. This is a deliberate constraint, not a limitation: it means every action the agent can possibly take is enumerable in advance, testable in isolation, and revocable independently of every other tool.

The blast-radius problem is the central engineering challenge here. An agent that can call `terraform apply` on any workspace in the organization is a single point of catastrophic failure — a reasoning error, a prompt injection via a maliciously crafted commit message or a poisoned data source, or simply a hallucinated action plan could take down production. The mitigation is layered scoping: agents get workspace-scoped credentials (an agent working on the cost-optimization loop for the analytics account has no credentials for the payments account), action-scoped permissions (an agent that can propose a Terraform plan cannot also approve and merge it — four-eyes review applies to agent-authored changes exactly as it does to human ones for anything above Tier 1), and time-scoped credentials (short-lived STS tokens rather than long-lived static keys, refreshed per task rather than per session).

Prompt injection deserves specific mention because IaC-adjacent data sources are unusually rich attack surfaces for it: a Terraform module pulled from a public registry, a GitHub issue comment, a cost anomaly description auto-generated from a tagged resource name an attacker controls — all of these can carry text an unguarded agent might interpret as instructions rather than data. The defense is architectural, not prompt-level: treat all external content (module source, issue text, resource metadata) as untrusted data passed to the model, never as instructions, and enforce that the action layer only accepts structured, schema-validated tool calls rather than free-text commands, so even a successfully injected instruction has no path to execution outside the pre-defined tool surface.

Policy-as-code: the actual guardrail, not the model's judgment

A recurring mistake in early agentic infrastructure projects is over-trusting the model's judgment as the safety mechanism. It isn't, and it shouldn't be treated as one. The safety mechanism is policy-as-code, enforced deterministically outside the model, on every single proposed action regardless of how confident the agent's reasoning appears. Open Policy Agent (Rego), HashiCorp Sentinel, and Kyverno (for Kubernetes-native environments) all serve this role: they take a proposed Terraform plan, Pulumi update, or Kubernetes manifest change and evaluate it against a hard-coded ruleset before it can proceed, independent of anything the LLM concluded.

Effective policies for agentic pipelines typically cover: resource-level guardrails (no security group may allow 0.0.0.0/0 on ports outside an approved list; no S3 bucket may disable encryption; no IAM policy may grant a wildcard action on a wildcard resource), cost guardrails (no single change may increase projected monthly spend beyond a defined threshold without human sign-off; no instance family outside an approved list may be provisioned), and blast-radius guardrails (no change may simultaneously affect more than N resources or more than one availability zone without staged rollout). These policies should live in version control alongside the IaC they govern, be tested with the same rigor as application code, and be the actual point of enforcement — not a description of intent that the agent is merely asked to respect.

Implementation roadmap: getting from zero to a working closed loop

Organizations that succeed with this approach almost never start by pointing an agent at production with write access. The realistic path runs through five phases, and skipping ahead is the most common cause of pilot failure and subsequent loss of stakeholder trust.

Phase 1: reconciled visibility

Before any agent reasons about anything, you need a single, continuously reconciled view of declared versus actual state across every cloud account and every IaC tool in use. This alone typically surfaces a large volume of pre-existing drift — resources created outside IaC, manual hotfixes that were never backported into modules, and orphaned resources from decommissioned projects. Fixing this baseline drift manually, once, is a prerequisite; an agent reasoning against a baseline that's already 20% drifted will spend its early cycles fighting noise rather than catching new issues.

Phase 2: observe-only agents

Deploy the reasoning agents (cost, reliability, security) in Tier 0 — detection and explanation only, no action. This phase exists to build the evidence base for how good the agent's reasoning actually is against your specific environment, and to tune away false positives before any action capability is granted. Expect this phase to run for four to eight weeks minimum, and track precision (of the things the agent flagged, how many were real issues) as the primary metric, not recall.

Phase 3: propose-with-approval

Grant the agent the ability to generate the actual remediation artifact — the Terraform PR, the scaling change, the IAM policy diff — but require human approval before execution. This is where most organizations should expect to stay for the majority of their use cases; Tier 1 alone typically eliminates 60-80% of the manual toil in triage and drafting even without any auto-execution, because the human's job shifts from "diagnose and write the fix" to "review and approve the fix."

Phase 4: tiered auto-execution

Promote specific, well-evidenced action classes to Tier 2 auto-execution, one action class at a time, each with its own rollback trigger and its own minimum track record requirement before promotion. Resist the temptation to promote broadly just because one action class performed well — a strong track record on cost rightsizing tells you nothing about the safety of auto-executing a security group change.

Phase 5: continuous expansion and audit

Once a stable set of Tier 2/3 actions is running, the ongoing work is expanding coverage (new resource types, new cloud providers, new policy domains) and maintaining the audit and governance rigor as volume grows. This is also where periodic red-team exercises against the agent pipeline itself become valuable — deliberately testing whether a malicious PR, a poisoned data source, or a misconfigured policy can trick the pipeline into an unsafe action.

Metrics that actually matter

Vanity metrics plague this space — "number of agent actions taken" or "hours saved" figures that are easy to inflate and hard to verify. The metrics worth tracking rigorously are outcome-based and falsifiable:

• Mean time to remediate (MTTR) by finding category — measured from detection to verified resolution, split by cost, security, and reliability findings, so degradation in one category doesn't hide behind improvement in another.
• Drift half-life — the median time a given piece of infrastructure spends out of compliance with its declared state before reconciliation, tracked over time to confirm the loop is actually tightening.
• False positive rate by agent — the proportion of agent-flagged findings that a human reviewer rejects as not-a-real-issue; rising false positive rates are the earliest warning sign of model or data drift in the reasoning layer.
• Auto-execution rollback rate — how often a Tier 2/3 auto-executed action triggers its rollback path; a rate persistently above the pre-promotion baseline is a signal to demote that action class back to human approval.
• Realized versus projected savings — every cost remediation should have its projected savings validated against the actual next billing cycle, not just trusted at proposal time; systematic over- or under-projection indicates a pricing-model bug in the agent's cost calculations.
• Coverage — the percentage of your total resource inventory actually within the reconciliation loop's visibility; a 95% MTTR improvement on 30% of your estate is a much smaller win than the headline number suggests.

These metrics should be reviewed with the same cadence and rigor as SLO error budgets, because that's functionally what they are — a budget for how much autonomy the organization is extending to its automation, and evidence for whether that extension is earning its keep.

Organizational and cultural considerations

The technical architecture is only half the challenge. The harder, slower work is organizational: engineers need to trust the agent's reasoning enough to act on its recommendations, but not so much that they stop scrutinizing them — a failure mode known in other automated domains as automation complacency. The practical countermeasure is to keep the agent's reasoning trace visible and legible at every tier, not just at Tier 0 or 1; even a Tier 3 auto-executed action should produce a readable explanation, because the day an engineer needs to understand why something happened is precisely the day they've lost the habit of reading agent output closely.

Team structure also shifts. Platform and SRE teams increasingly need someone playing an "agent operator" role — not a data scientist, but an engineer who understands both the IaC domain and enough about how the reasoning layer is prompted, evaluated, and tuned to debug it when it misbehaves. This role sits closest to where integrated NOC/SOC operating models are heading generally: the distinction between "the person who watches the dashboard" and "the person who tunes the automation watching the dashboard" is collapsing into a single, more technically demanding role.

Finally, procurement and vendor evaluation criteria need updating. When evaluating a platform's agentic capabilities, the questions that matter are not "does it use AI" but: What is the tool-call surface the agent is constrained to? How is provenance tracked for agent-authored changes? What is the default risk tier for each action class, and can it be configured per environment? How is prompt injection from untrusted data sources mitigated architecturally? What does the audit trail actually contain, and can it be exported for a compliance review? Vendors who can't answer these concretely are selling a demo, not an operable system.

Frequently asked questions