Terraform Plans as an Agent's Proposal Format

Plans are diffs that humans already know how to review. The agent that emits plans instead of applying changes, and the apply-on-approve flow that closes the loop.

Why plans, not applies

The plan-as-proposal pattern leans on tooling humans already know how to read. The plan is the agent’s proposed action; the apply is the human-approved execution.

• Structured diff. A Terraform plan is a typed diff humans already know how to review and tooling already knows how to display.
• Natural review gate. Letting the agent emit plans instead of applies inserts a review step without inventing new infrastructure for it.
• Reversible until apply. The agent can re-run with different parameters and nothing has happened in production yet.
• Existing CI alignment. The same plan flows through the same pipeline humans use, so audit, approval, and apply paths are unchanged.

The propose-then-apply flow

The flow has four steps and one rule: nothing is inserted between approval and apply. The plan that gets approved is the plan that gets applied.

• Plan generation. The agent runs terraform plan -out through a code wrapper. The plan file is stored, not just the textual summary.
• Channel summary. Plan summary posted to the team’s review channel: resources to add, change, destroy. Includes the plan-file ID.
• Human review. Reviewer approves or rejects. Approval triggers terraform apply against the stored plan.
• Auditable apply. The applied plan is the same plan that was approved. Nothing was inserted between approval and apply; the audit trail is one row, not three.

Constraints on what the agent can plan

Capability is constrained by allowlists, not by trust in the model. Allowlists scale; trust does not.

• Module allowlist. The agent can only operate on modules the team has explicitly opted in. New modules require an explicit add.
• Resource type allowlist. Plans target known resource types; novel resource types require human authoring outside the agent.
• Destroy operations. Heavily restricted. Most agent plans should add or change, not destroy. Destroys require a separate sign-off path.
• Blast-radius cap. Plans changing more than N resources at once are blocked at proposal time and routed to a human.

Safety properties

Three properties keep the pattern safe. Drop any one and the audit trail starts lying.

• Plan TTL. Plan files expire on a TTL. Stale plans cannot be applied; the agent re-plans against current state before applying.
• Single-use apply. Applying a plan invalidates it. Re-running the same apply requires a new plan, which means a new approval.
• Dry-runnable by humans. Every plan is human-runnable before approval. Visibility before consent is the contract.
• Plan signing. Each stored plan is hash-signed. Tampering between approval and apply is detected and the apply refuses.

When this pattern wins

The pattern fits a specific niche: changes too narrow for a full Terraform PR but too wide for an ad-hoc shell command.

• Routine but careful. Adding a new monitor, scaling a worker pool, opening a port to a known service. The risk is low but a typo still hurts.
• Mid-scope changes. Too narrow for a PR review, too wide for a kubectl tweak. The plan-as-proposal sits in the middle and earns its overhead.
• Audit-required changes. Plans, approvals, and applies are all logged. The change is reproducible from the trail months later.
• Cross-team coordination. When the change touches a resource owned by another team, the plan summary is the artefact they review without joining the agent run.