# Cursor Agent for Terraform: A Practical Project Workflow

URL: https://agentvera.dev/en/blog/cursor-agent-for-terraform/ · Published: 2026-11-01

A practical guide to using Cursor Agent in Terraform projects, including setup rules, plan-first prompts, testing, and multi-agent workflows.

**In short:**

- Cursor Agent is effective for Terraform when you give it a plan-first loop and explicit repo rules.
- AGENTS.md or .cursor/rules should encode Terraform commands, folder conventions, and state/apply limits.
- Review every terraform plan and git diff before apply, especially for provider upgrades and state changes.

Cursor Agent is a practical fit for Terraform work because it operates inside the repo, reads HCL directly, and can run `terraform fmt`, `terraform validate`, and `terraform plan` before you review changes. Start `cursor-agent` in the project folder and give it explicit Terraform guardrails in `AGENTS.md` or `.cursor/rules`. For base agent setup, see [Cursor Agent](/en/agents/cursor-agent/).

## A plan-first tool for infrastructure as code

Terraform is largely declarative: most changes are edits to `.tf` files, variable blocks, outputs, and provider configurations. Cursor Agent can make those edits consistently and check them with the same `terraform` binary you already use. It is not just a code generator; because it runs in the project directory, it can run `terraform plan` and show you the resource diff before anything is applied. That closes the loop that matters in infrastructure work: proposal, validation, plan, review.

The concrete benefits are:
- Module boilerplate: variables with types and defaults, outputs, `versions.tf`, and provider requirements follow your project conventions.
- Cross-file changes: it can add a resource, update an IAM policy document, and add a new output without losing track of dependencies.
- Safe local iteration: `terraform validate` and `plan` run in the terminal, so the agent can fix mistakes immediately.
- Consistent style: you can enforce `terraform fmt` and naming rules through AGENTS.md.

The main prerequisite is a clear project contract. Without it, an agent may race ahead into `apply`, state changes, or provider upgrades. With the setup below, the same strengths work in your favor.

## Put Terraform guardrails in AGENTS.md

Create or update `AGENTS.md` in the repo root, or use `.cursor/rules` if you prefer rule files. The goal is to encode the commands you expect the agent to run, the folder layout, and the Terraform-specific safety limits. Keep the file short; agents follow explicit, current instructions better than long prose. If you need the terminal workflow, the [How to use Cursor CLI: a step-by-step guide](/en/blog/how-to-use-cursor-cli/) is useful.

A realistic starting point:

```markdown
# Terraform repo rules

- Terraform CLI: ~> 1.8
- Providers are pinned in `versions.tf`. Do not change provider source or version without asking.
- Folder layout:
  - `modules/<name>/` contains `main.tf`, `variables.tf`, `outputs.tf`
  - `environments/<env>/` contains `main.tf`, `backend.tf`, `terraform.tfvars`
- Lint and validation:
  - Run `terraform fmt -check` and fix any formatting.
  - Run `tflint --recursive` if available.
  - Run `terraform validate` before any plan.
- Plan and apply:
  - Always run `terraform plan -out=plan.tfplan` and show the diff.
  - Never run `terraform apply` unless the user explicitly requests it after reviewing the plan.
- State and backend:
  - Do not edit state files or run `terraform state` commands without an explicit request.
  - Remote state/backend configuration changes require user confirmation.
```

This tells the agent where modules live, how to check its work, and where the hard stops are.

## The daily loop: small tasks, plan, review

Use the same loop for most Terraform tasks: plan the change in one sentence, let the agent edit, run validation, review the plan, then decide on apply.

Steps:
1. Give the agent a bounded task: one module, one resource, or one refactor.
2. Ask it to run `terraform fmt -check`, `terraform validate`, and `terraform plan` before considering the task done.
3. Read the plan output in the terminal. Check for unexpected replacements, deletions, or changes to remote state.
4. Review `git diff` for the `.tf` and lock file changes.
5. If the plan is acceptable, run `terraform apply` yourself or ask the agent to apply with explicit confirmation.

Example prompts that fit this loop:

- Add a `tls_private_key` resource and a sensitive output to `modules/bootstrap`; update the input variables for `algorithm` and `rsa_bits`; run validation and plan.
- Create a new module `modules/s3_website` with variables for `bucket_name` and `index_document`, and outputs for `website_endpoint` and `bucket_arn`.
- Refactor `environments/prod` to use `terraform.tfvars` instead of inline variable defaults; run plan and confirm no resource changes are proposed.
- Update the Lambda execution role policy to include `logs:CreateLogGroup` and `logs:PutLogEvents`; run validate and plan.
- Change the AWS provider version constraint in `versions.tf` from `~> 5.0` to `~> 5.30`; run `terraform init -upgrade` and plan; report any resources that would be replaced.

## Where Cursor Agent helps and where to verify closely

Well-suited tasks:
- Adding or updating resources within an existing module: create an S3 bucket, enable versioning, add tags, attach a policy.
- Generating standard module scaffolding with inputs, outputs, and provider requirements.
- Refactoring variable naming, defaults, and type constraints across environments.
- Updating IAM policy documents and security group rules with JSON/HCL conversions.
- Writing `terraform test` assertions for validation rules and plan checks.

Pitfalls to watch closely:
- State and backend edits: the agent may try to change backend configuration or run `terraform state mv/rm` without enough context.
- Provider upgrades: changing provider versions can force replacements; require a plan and explicit review.
- Multi-environment drift: a generic task may update `dev` correctly but miss `prod` conventions; pin the environment.
- Output and sensitive data: the agent may print private keys or passwords unless you mark outputs `sensitive` and instruct it to avoid echoing values.
- Lock file changes: `terraform init -upgrade` can alter `.terraform.lock.hcl`; review that diff separately.
- Dynamic blocks and `count`/`for_each`: the agent may introduce patterns that look valid but change resource indexes and cause replacements.

In general, keep tasks small and ask for the plan diff. The agent is good at Terraform syntax, but it cannot know your risk tolerance for infrastructure changes unless you encode it.

## Validate and plan before you trust a change

Terraform has built-in validation and plan commands that should be part of every agent task. Add `tflint` or `checkov` for policy checks if they are already in the project. Do not let the agent treat `terraform apply` as a test.

Use this table as a verification checklist:

| Check | Command or action | Why it matters |
|---|---|---|
| Formatting | `terraform fmt -check` | Keeps HCL style consistent and diffs readable |
| Syntax and references | `terraform validate` | Catches invalid resource arguments and missing variables |
| Resource changes | `terraform plan -out=plan.tfplan` | Shows adds, changes, and replacements before apply |
| Static analysis | `tflint --recursive` | Finds deprecated arguments, provider issues, and common mistakes |
| Lock file review | `git diff .terraform.lock.hcl` | Confirms provider version changes are intentional |

After the agent runs the first three, always read the plan output yourself. If the task includes policy changes, ask the agent to run `checkov -d .` or your existing scanner and fix high-severity findings first. Terraform `terraform test` can be useful for module validation, but it does not replace a real plan against a target environment.

## Parallel Terraform work with AgentVera

AgentVera lets you run Cursor Agent alongside other CLI agents in separate terminals, which is useful when Terraform work splits into independent modules or environments. Because each agent can use its own git worktree, they won’t overwrite each other’s `.tf` files or lock changes; plan diffs remain isolated. Automatic code review after each turn catches risky resource or state edits, and checkpoints let you undo a bad agent turn and replay it step by step before any apply. See [Best tools to run AI coding agents in parallel (2026)](/en/blog/best-tools-parallel-ai-coding-agents/) for a broader comparison.

## Final word

Cursor Agent works well with Terraform when the repo has clear rules and the loop stays plan-first. Keep AGENTS.md short and specific, make the agent show a plan for every change, and review `git diff` before apply. For parallel modules or environments, use AgentVera worktrees and automatic review to keep infrastructure changes isolated and reversible.

## Frequently asked questions

**How do I start Cursor Agent in a Terraform project?** Run cursor-agent in the root of the Terraform repository. Make sure AGENTS.md or .cursor/rules contains your Terraform commands and safety rules before you ask for changes.

**Can Cursor Agent run terraform plan and apply for me?** Yes, it can run terraform commands in the project directory. But you should instruct it to run plan first and require explicit approval before apply, then review the plan and git diff yourself.

**What should I put in AGENTS.md for Terraform?** Include the required Terraform and provider versions, module/environment folder layout, validation and plan commands, and rules that prevent automatic apply or state changes. A short, concrete file works better than long guidance.

**How do I keep Cursor Agent from making destructive changes?** Use small, scoped prompts and require terraform plan -out=plan.tfplan before any apply. Ask the agent to mark outputs sensitive, avoid state commands without permission, and review provider upgrades carefully; for parallel work, use separate git worktrees.

---

**About AgentVera.** AgentVera is a desktop app for macOS, Windows and Linux, built by Solviera Teknoloji. It runs 18 AI coding agents (Claude Code, Codex, Gemini CLI, Copilot, Cursor, Antigravity, opencode, Hermes, Qwen Code, Kimi Code, Kiro, Amp, Droid, Goose, Vibe, Crush, Aider, Cline) side by side, per project, in real terminals with the user's own CLI installs and logins. The free plan has unlimited agents. Download: https://agentvera.dev/en/download/ · Pricing: https://agentvera.dev/en/pricing/