Infrastructure as Code Patterns

Infrastructure as code patterns for AI agents are four recipes (split a Terraform monolith, gate the plan, adopt drift, harden CloudFormation or Pulumi) run by Claude Code, Codex or Cursor under plan-only cloud credentials. A machine-checked plan gate, not a human reading HCL, blocks every delete or replace until a named owner approves it.

This page is for developers who own a service’s infrastructure and tech leads who decide what an agent may touch in a cloud account. You inherit a Terraform repository with one 900-line main.tf, hardcoded CIDR blocks, a provider pinned two majors back, and a terraform plan that wants to replace the production RDS instance. The agent can split that file in minutes. The question is how you know the split destroys nothing, when the plan is 400 lines long and nobody wants to read it.

What you’ll walk away with from these infrastructure recipes

• A permission setup in which the agent can run terraform plan but has no credentials that could apply
• A short plan-gate.sh that fails on any delete or replace, so review starts from a short list instead of the whole plan
• Copy-paste prompts for a module split with moved blocks, a plan review, drift adoption with import blocks, and a CloudFormation hardening pass
• A table of gates (format, lint, policy, test, plan) that proves the change without reading every line
• Recovery steps for stuck locks, drift, accidental replacements, provider major upgrades and a stuck CloudFormation rollback

Fence the agent before the first prompt

The control that holds is the credential, not the prompt. An agent that has only a plan role cannot apply, whatever it decides to run. Set this up once per repository, in this order.

1. Create a plan-only identity. On AWS, attach ReadOnlyAccess plus access to the state bucket: read on this stack’s state key, and s3:PutObject / s3:DeleteObject on the *.tflock key only. That is enough for terraform plan with S3 native locking. ReadOnlyAccess also grants s3:GetObject on every bucket in the account, including other stacks’ state files, so add an explicit Deny on s3:GetObject for any state key that is not this stack’s. Apply runs in CI under a different role that the agent never sees. The same split works on Azure (Reader plus the state storage account) and Google Cloud (Viewer plus the state bucket). Cloud MCP servers covers read-only identities per cloud.

2. Deny the destructive commands in the tool. This is a typo-catcher on top of the credential, not a replacement for it.

   Claude Code

   In .claude/settings.json (committed, so the whole team gets it):

   {
     "permissions": {
       "allow": ["Bash(terraform fmt *)", "Bash(terraform validate *)",
                 "Bash(terraform plan *)", "Bash(terraform show *)", "Bash(tflint *)"],
       "ask":   ["Bash(terraform state *)", "Bash(terraform import *)"],
       "deny":  ["Bash(terraform apply *)", "Bash(terraform destroy *)",
                 "Bash(terraform force-unlock *)", "Bash(terraform state rm *)"]
     }
   }

   Deny rules are evaluated before ask and allow. They match the command string, so sh -c 'terraform apply' is a different spelling: see permissions and sandboxing for why the sandbox and the credential are the real boundary.

   Codex

   # Terminal, repo root: approvals on request, writes limited to the workspace
   codex -a on-request -c default_permissions=":workspace"

   Permission profiles are beta in Codex 0.157.1 and are what OpenAI now prefers over --sandbox; do not combine the two. Codex passes environment variables whose names contain KEY, SECRET or TOKEN to commands unless shell_environment_policy says otherwise, so start Codex from a shell that holds only the plan role.

   Cursor

   Keep Cursor’s agent on a run mode that asks before terminal commands (see Cursor’s Run modes page under Agent security), and start Cursor from a shell or profile that holds only the plan role. Whichever mode you pick, the plan-only credential is the boundary; the run mode only catches typos.

3. Write the conventions down once. Put them in AGENTS.md (Codex reads it; Claude Code reads it when the repository has no CLAUDE.md, from v2.1.277 on the latest channel) or CLAUDE.md, and in a Cursor project rule:

   ## Infrastructure rules
   - Terraform >= 1.11. S3 backend with `use_lockfile = true`. No new DynamoDB lock tables.
   - Pin providers to the current major (`~> 6.0` for hashicorp/aws) and commit .terraform.lock.hcl.
   - Renames and module moves use `moved` blocks. Never `terraform state mv` in a PR.
   - Adopt existing resources with `import` blocks, not `terraform import`.
   - No hardcoded CIDRs, regions, account IDs or secrets: variables and a secrets manager.
   - You may run fmt, validate, tflint, plan and show. You never run apply or destroy.

Recipe 1: split a Terraform monolith without destroying anything

A module split changes every resource address. Without moved blocks, Terraform reads that as “destroy the old address, create the new one”, which on a database means data loss. With them, the correct plan for a pure refactor is zero changes: that single number is your acceptance criterion.

Claude Code

# Terminal, repo root. Manual mode so every edit is shown before it lands
claude --permission-mode manual

Paste the prompt below. Claude Code edits the files, runs terraform plan and reads its output in the same session, so the “zero changes” loop closes without you copying anything.

Codex

Save the prompt below as prompts/split-monolith.txt, then run:

codex -a on-request -c default_permissions=":workspace" "$(cat prompts/split-monolith.txt)"

Keep the prompt in the repository so the next split uses the same wording. If the sandbox blocks network access, Codex asks before it runs terraform plan outside it; approve plan, never apply.

Cursor

Open Agent in Plan Mode, paste the prompt, and approve the module boundaries before it writes files. Switch to Agent to execute, and run terraform plan in the integrated terminal when it asks.

Copy-paste prompt: split main.tf into modules with zero plan changes

Refactor main.tf into three local modules: modules/network (VPC, subnets,
NAT, route tables), modules/data (RDS, ElastiCache) and modules/compute
(ASG, ALB, launch template). Rules:
1. Before writing files, list every resource with its current address and
   its new address, and the variables each module needs. Wait for my OK.
2. For every address change, add a `moved` block in moved.tf. Do not use
   terraform state mv.
3. Move hardcoded CIDRs and the region into variables.tf with the current
   values as defaults, so the plan does not change.
4. Run terraform fmt -recursive, terraform validate, then
   terraform plan -out=tfplan -input=false.
5. Done means the plan reports "No changes". If it does not, show me each
   resource the plan would change and why, fix it, and plan again.
Never run terraform apply.

If the plan still shows changes, the cause is almost always one of three things: a missing moved block, a default that differs from the old literal, or count turned into for_each (which changes the index from [0] to ["name"] and also needs a moved block). Ask the agent to name which one for each resource.

Recipe 2: turn the plan into a gate you don’t read line by line

A 400-line plan is where review fails, because the one -/+ on a database hides among 60 tag updates. Reverse the order: a script extracts the destructive actions from the machine-readable plan, and a human reviews only that list.

#!/usr/bin/env bash
# scripts/plan-gate.sh: exit 2 when the plan deletes or replaces anything
set -euo pipefail
terraform plan -out=tfplan -input=false -lock-timeout=60s
terraform show -json tfplan > plan.json
jq -r '.resource_changes[]?
  | select(.change.actions | index("delete"))
  | "\(.change.actions | join("/"))\t\(.address)"' plan.json > destructive.txt
jq '[.resource_changes[]? | {address, actions: .change.actions,
  replace_paths: .change.replace_paths}]' plan.json > plan-summary.json
jq -r '[.resource_changes[]?.change.actions | join("/")] | group_by(.)
  | map("\(.[0]): \(length)") | .[]' plan.json
if [ -s destructive.txt ]; then
  echo "Delete or replace needs a named approver:"; cat destructive.txt; exit 2
fi

In terraform show -json, a replacement appears as ["delete","create"] or ["create","delete"], so matching on delete catches both. Run the script in the agent session and again in CI. In CI, write destructive.txt as a job output; when it is non-empty, the apply job targets a protected environment whose required reviewer is the service owner, and apply runs only from the saved tfplan that was reviewed.

The plan and the state hold secrets in plaintext

tfplan, plan.json and the state file contain sensitive values (database passwords, generated keys) unredacted; the sensitive flag only hides them in the CLI output. Add tfplan, plan.json and plan-summary.json to .gitignore, never upload plan.json or tfplan as a public CI artifact, and scope the plan role’s s3:GetObject to this stack’s state key. That is why the gate writes plan-summary.json (addresses, actions and the attribute paths that force a replacement, no values): the agent reads that file and destructive.txt, not plan.json.

Copy-paste prompt: review a plan before anyone approves it

Run scripts/plan-gate.sh, then read destructive.txt and plan-summary.json.
Do not open plan.json, tfplan or the state: they hold secrets. Produce:
1. The action summary the script printed.
2. For every line in destructive.txt: the attribute that forces it
   (from replace_paths and the provider docs), whether it loses
   data or causes downtime, and a way to avoid it (moved block,
   lifecycle { prevent_destroy = true }, create_before_destroy, or an
   attribute that can change in place).
3. Any update to a security group, IAM policy or KMS key, listed separately.
End with GO or NO-GO and one sentence of reason. Do not run apply and do
not edit any .tf file in this step.

Add lifecycle { prevent_destroy = true } to stateful resources (databases, buckets holding data, KMS keys) as part of Recipe 1. Terraform then refuses any plan that destroys them, which turns the most expensive mistake into a plan error.

Recipe 3: adopt console drift with import blocks

Someone added a security group rule in the console during an incident, and now every plan wants to remove it. Do not let the agent overwrite the drift with an apply: the rule may be what is holding the incident back.

Run terraform plan -refresh-only to see exactly what changed outside Terraform. Then decide per resource: adopt it, revert it in the console, or change the configuration to match. For adoption, Terraform 1.5 and later write the import as code, so it is reviewed like any other change.

Copy-paste prompt: reconcile drift after an incident

Run terraform plan -refresh-only -input=false and list every drifted
attribute. For each resource the console created that is not in state,
write an `import` block in imports.tf and run
terraform plan -generate-config-out=generated.tf to draft its config.
Then move each generated resource into the right module, remove computed
and default-valued arguments, and re-run plan until the only actions are
imports. Put each drifted item in one of three buckets (adopt, revert in
the console, change config to match) with a one-line reason. Do not run
terraform import, terraform state commands or apply.

A cloud MCP server makes this faster: with read access, the agent lists the real resources itself instead of asking you to paste console output. Connect it read-only, as cloud MCP servers shows.

Recipe 4: harden a CloudFormation template or Pulumi stack

The same discipline applies with a different preview command. For CloudFormation, aws cloudformation deploy --no-execute-changeset creates a change set the agent can read without executing it. For Pulumi, pulumi preview --diff is the plan for a human, and pulumi preview --json is the one for the gate: filter the steps whose op is delete, replace, create-replacement or delete-replaced into destructive.txt, the same way plan-gate.sh does. The gate is the same: list replacements, block until an owner approves.

Copy-paste prompt: production-readiness review of a CloudFormation template

Review infrastructure.yaml for production. Check that every RDS instance
and EBS volume has DeletionPolicy: Snapshot and UpdateReplacePolicy:
Snapshot, storage encryption and Multi-AZ; that security groups reference
each other instead of 0.0.0.0/0 on internal ports; and that no secret is a
plaintext parameter (move DatabasePassword to Secrets Manager with a
dynamic reference). Output the fixes highest risk first, each with the
exact YAML change. Then create a change set with
aws cloudformation deploy --no-execute-changeset and list every resource
whose Replacement is True or Conditional. Do not execute the change set.

How do you verify agent-written infrastructure without reading every line?

Stack the checks so each one catches a class of error mechanically, and a human looks only at what survives. Run them in this order, cheapest first, in the agent session and again in CI.

Gate	Command	Catches	Fails the build when
Format and syntax	terraform fmt -check -recursive and terraform validate	Invented arguments, type errors, bad references	any error
Lint	tflint --recursive	Invalid instance types, deprecated syntax, unused declarations	any error
Static policy	checkov -d .	Public buckets, unencrypted storage, open security groups	a failed check not on the reviewed skip list
Behaviour	terraform test	A module that no longer does what its contract says	any failed run
Plan policy	conftest test plan.json	Your own rules applied to the actual planned values	any deny
Destruction	scripts/plan-gate.sh	Deletes and replacements	any line in destructive.txt

Versions checked on 2026-09-26: Terraform 1.16.4, hashicorp/aws provider 6.66.0, tflint 0.64.0, checkov 3.3.19, conftest 0.70.1. A plan policy for conftest is a few lines of Rego over plan.json:

policy/no_public_ssh.rego

package main
import rego.v1

deny contains msg if {
  some rc in input.resource_changes
  rc.type == "aws_security_group_rule"
  rc.change.after.type == "ingress"
  "0.0.0.0/0" in rc.change.after.cidr_blocks
  rc.change.after.from_port <= 22
  rc.change.after.to_port >= 22
  msg := sprintf("%s opens SSH to the internet", [rc.address])
}

Who signs off. The agent may declare the checks green. It may not approve. A pull request that passes every gate and shows zero lines in destructive.txt needs one reviewer on the diff. A pull request with any destructive line needs the service owner to approve that list by name, and apply runs from the reviewed tfplan in CI. Attach the gate output to the pull request as its evidence bundle, so the reviewer reads six results and a short list instead of the HCL.

Ground the agent in the registry, not its memory

A common source of broken HCL is provider arguments the agent remembers from an older major version. Two additions fix that, and the full setup lives on infrastructure MCP servers.

HashiCorp’s Terraform MCP server with no token registers only its registry tools, which look up current provider and module documentation. That is read-only by construction:

Claude Code

claude mcp add terraform -s project -- docker run -i --rm hashicorp/terraform-mcp-server:1.3.0

Codex

codex mcp add terraform -- docker run -i --rm hashicorp/terraform-mcp-server:1.3.0

Cursor

In .cursor/mcp.json:

{ "mcpServers": { "terraform": {
  "command": "docker",
  "args": ["run", "-i", "--rm", "hashicorp/terraform-mcp-server:1.3.0"] } } }

HashiCorp’s agent skills (hashicorp/agent-skills, MPL-2.0) carry the conventions: refactor-module for Recipe 1, terraform-search-import for Recipe 3, terraform-test and terraform-style-guide for the gates. Install the plugin in Claude Code, or individual skills with the skills CLI (1.7.0) for Codex and Cursor:

# Claude Code
claude plugin marketplace add hashicorp/agent-skills
claude plugin install terraform@hashicorp
# Codex, Cursor and other agents: pick skills one at a time
npx skills add hashicorp/agent-skills/plugins/terraform/skills/refactor-module

The whole plugin loads 16 skills and costs about 2,150 always-on tokens in every session (claude plugin details terraform@hashicorp, 2026-09-26); each skill adds 0.5k–7k more when it fires. For the wider field, see infrastructure MCP servers. Do not also install terraform@claude-plugins-official: it registers a second terraform MCP server pinned to the older 0.4.0 image. Use a skill when you want conventions, and the MCP server when the agent needs live registry data.

When agent-driven Terraform breaks

The state lock will not release

A killed CI job or an interrupted plan leaves a lock, and every run fails with Error acquiring the state lock. Confirm in CI that no apply is running. Then a human with the apply role runs terraform force-unlock LOCK_ID, with the ID from the error. With use_lockfile = true, the lock is an S3 object next to the state named <key>.tflock; with the deprecated dynamodb_table setting it is a DynamoDB item. The agent’s deny list blocks force-unlock on purpose: unlocking during a real apply corrupts state.

A one-line change wants to replace half the VPC

A renamed resource, a count to for_each switch, or a changed name tag on a launch template can cascade into replacements. plan-gate.sh shows the list. Recover by adding moved blocks for renames, reverting the attribute that forces replacement, or splitting the change. Use -target only to diagnose, never as the way the change ships: Terraform itself warns it is for exceptional cases.

The agent upgrades a provider major version with the refactor

Moving hashicorp/aws from ~> 5.0 to ~> 6.0 changes arguments and defaults. Mixed into a refactor, it makes the “zero changes” check meaningless. Ship the upgrade as its own pull request: terraform init -upgrade, commit .terraform.lock.hcl, run the gates, and have the agent explain each changed resource against the provider’s upgrade guide, fetched through the Terraform MCP server.

The plan fights reality after an incident

The plan wants to delete a rule nobody wrote in code. Stop, and run Recipe 3. Never tell the agent to “make the plan clean” without the refresh-only view first: it will remove the console change, which can reopen the incident.

CloudFormation is stuck in UPDATE_ROLLBACK_FAILED

Ask the agent to read aws cloudformation describe-stack-events and name the resource that blocked the rollback, and why. Fix the cause outside the stack if you can. Otherwise a human runs aws cloudformation continue-update-rollback with that resource in --resources-to-skip, and then brings the resource back in line with the template.

Where to go next with infrastructure as code

The prerequisite for these recipes is a harness that holds: permissions and sandboxing. The next step is putting the gates and the apply step in a pipeline.

CI/CD pipeline patterns Run plan-gate.sh on every pull request and apply only from the reviewed plan.

Infrastructure as code with AI assistants The full workflow: framing constraints, generation, security review and cost policy.

Infrastructure MCP servers Terraform and Kubernetes MCP servers, read-only, with their context cost.

Kubernetes orchestration patterns Drive workloads on the cluster you just provisioned with the same review discipline.