Why I Don't Let My AI Agent Apply Terraform

Coding agents are good at writing Terraform. The problem is that the same agent that writes main.tf can also run terraform apply. One prompt injection or one confident mistake, and it has changed production.

I built Agentic Boundary Terraform so the agent can do the work up to that point, with deploy credentials kept out of its session. It can read your infrastructure, adapt Terraform, run checks and produce a plan. You review the plan and apply it from your own terminal.

Three layers, with limits

I use three layers to hold that line. The hook and terminal check have limits. The credential boundary depends on giving the agent only cloud permissions that deny infrastructure changes, even if those checks are bypassed:

A hook in the agent

In Claude Code, Codex, Cursor and Windsurf, a guard blocks apply, destroy and -auto-approve, whether the agent runs them from the shell, through an MCP tool, or through wrappers like terragrunt. If the guard can't read a call or crashes, it blocks it. The hook reads command text; it can miss scripts, variables or command names built at runtime.

A terminal-gated apply step

boundary.sh apply needs a real terminal and a fresh plan. You also have to type that plan's fingerprint, after seeing which tools are labelled read or write and which permissions change. The terminal check cannot tell a human from a program, which is why the agent must have only read-only cloud credentials.

Read-only credentials

The agent's session never holds deploy rights. If the first two locks are ever tricked, this one still holds.

Checks before planning

Before planning, the skill runs four checks taken from a pinned release of Agentic-AI-Systems: write-boundary tests, a provider-pin check, OPA policies and terraform validate. Editing those checks inside your project changes nothing, because they come from the pinned release every time. It then reviews the change against a threat model and asks four questions. What could a compromised orchestrator, a prompt-injected model, a leaked approval or a later Terraform change now reach? If any answer is "more than before", it stops.

Evidence and limits

For regulated teams, every change produces an evidence record you can hand to a compliance review. It supports that review; it doesn't certify anything on its own.

It works on AWS, Azure, GCP and Snowflake, and the Limits section of the README lists what it can't see.

Who it helps

• Teams deploying AI agents who want every action that changes state approved by a person.
• Platform and security engineers who want an agent's speed on Terraform without giving it apply rights.
• Regulated teams. Each change produces an evidence record covering the gates passed, the security review, governance, security and privacy checklists, and who approved it. It supports a compliance review but doesn't certify one.

Getting started

You need python3, terraform and conftest installed.

In Claude Code:

/plugin marketplace add somesh-ghaturle/agentic-boundary-terraform-skills
/plugin install agentic-boundary-terraform@agentic-boundary

For Codex, Cursor or Windsurf:

git clone https://github.com/somesh-ghaturle/agentic-boundary-terraform-skills.git
cd agentic-boundary-terraform-skills
python3 install.py codex      # or: cursor, windsurf

Then ask your agent something like "set up the approval-gated agent on GCP in ./infra". It picks a cloud with you, runs the checks, makes a plan if you ask, and stops. You apply it yourself:

skills/terraform-boundary/scripts/boundary.sh apply ./infra dev

Last step: give the agent's session a read-only cloud identity, and keep deploy credentials in your own terminal.

Try it and share feedback

If you want an agent's speed on infrastructure without giving it the final say, try it and tell me where it breaks.