11 from Terraform MCP server GA: the Apply Gate your auditor will ask about
The apply gate: an agent may plan, a named person applies
By Vladimir Mikhalev Docker Captain · CNCF Ambassador · IBM Champion
The code an agent writes is rarely the problem. The record of who let it apply is.
Read-only is the right default for almost every team today. The steps below are what has to exist before the flag flips for any workspace, and the flag flips per deployment, never for the organization.
- 1
Pin what the server can reach
Name the toolsets explicitly (
--toolsets=registry,registry-private, or--toolsfor single tools), leaveENABLE_TF_OPERATIONSunset, and scopeTFE_TOKENto the fewest workspaces that work. On an HTTP deployment setMCP_ORGANIZATION_ALLOWLISTto the smallest set of organizations. The deliverable is a written list of what the agent can see before it can change anything. Owner: platform engineer. - 2
Know what the flag unlocks
It is not one capability:
auto_approveandis_destroyruns,action_run, and the deletes (delete_workspace_safely,force_unlock_workspace,delete_project,delete_team). Read the list against the installed version before deciding, because it grows. - 3
Gate every workspace an agent may apply against
Attach a Sentinel policy set to it (
attach_policy_set_to_workspaces, checked withlist_workspace_policy_sets). No policy set attached, no agent apply on that workspace. Owner: security or platform lead. - 4
Keep the approval with a person
Auto-apply stays off on every workspace the agent reaches, so a run it queues waits for a named approver in HCP Terraform or Terraform Enterprise.
- 5
Keep two records
The platform's audit trail answers who triggered and who approved each run. The server's metrics, with
OTEL_METRICS_ENABLED=true, answer how often the agent called a tool and how it failed:mcp_tool_calls_total,mcp_tool_errors_total,mcp_tool_duration_seconds. - 6
Flip the flag only where the first five exist
One deployment, the workspaces it is scoped to, and a date to read both records back.
What the flag changes (server reference, read 14 November 2026, v1.4.1)
| Tool | Flag unset (the default) | With the flag |
|---|---|---|
create_run | plan_and_apply with auto-apply off, refresh_state, plan_only, allow_empty_apply | Adds auto_approve and is_destroy |
action_run | Not registered | Apply, discard or cancel a run |
delete_workspace_safely, delete_project, delete_team | Not registered | Delete |
force_unlock_workspace | Not registered | Force-unlock a locked workspace |
Where to check it
The vendor's own reference and code, read at the version named.
- HashiCorp, Terraform MCP server is now generally available, 11 June 2026.
- The server reference: the environment variables and their defaults, the destructive tools, the run types, and the telemetry metrics.
- dynamic_tool.go at v1.0.0 and create_run.go at v1.0.0:
create_runpicks the safe variant unless the flag is true;action_runis registered only with it. - The changelog: the organization allowlist reaching the tool layer, and each destructive tool added behind the flag.
Read-only this week. The apply gate opens when the record can answer for it.
The long version is the post Terraform MCP server GA. HashiCorp, the GA announcement and the server reference; ISMS.online on SOC 2 CC8.1.