"Only a few veterans understand our infrastructure changes, creating severe person-dependency." "We want to make things easier with AI, but letting it touch production is honestly terrifying." An IT team at manufacturing Company A that consulted us recently faced this exact dilemma. Although Terraform code existed, only a single employee who was scheduled to leave could read diffs from plan.
The development that holds the potential to simultaneously solve both person-dependent IaC and the fear of letting AI touch infrastructure is InfoQ's June 2026 report on the General Availability (GA) of Terraform MCP Server. Powered by HashiCorp's official Model Context Protocol server, AI assistants can now query and operate Terraform infrastructure using natural language.
From our perspective providing custom development supporting infrastructure for mid-sized and small enterprises, this means we have entered a phase where we can answer through design the most common client inquiry: "We want to delegate IaC to AI, but we need safe governance." The IaC standardization we have addressed in OpenTofu/Terraform Migration and IaC Governance Development is entering a new dimension: designing governance tailored for interactions by AI agents. This article details the Terraform MCP Governance Design custom package provided by our company.
What Terraform MCP Server can actually do
Terraform MCP Server is not magic that allows AI to arbitrarily remodel your infrastructure. MCP (Model Context Protocol) is an open standard protocol connecting AI agents with external systems, structured as outlined in our Complete Guide to MCP. Terraform MCP Server acts as the dedicated gateway for Terraform. Based on official information (HashiCorp Blog and official documentation), its core capabilities include:
| Feature category | Permissions | Nature |
|---|---|---|
| Registry queries | Fetch provider, module, and policy information; generate recommendations | Primarily read-only |
| Style guide reference | Reference Terraform style guides and module development best practices | Read-only |
| Workspace management | Create, update, and delete HCP Terraform / Terraform Enterprise workspaces; manage variables and tags | Involves writes |
| Run execution | Execute runs such as plan_and_apply (apply after approval) and refresh_state (refresh state only) | Involves writes |
| Stacks support | Deploy and manage Terraform Stacks via natural language | Involves writes |
The key takeaway is that features are clearly bifurcated into read-only and write-enabled operations, and enabled capabilities can be selected using the --toolsets flag. Being able to switch at launch time between querying public registries only versus including operational management serves as the foundation for governance design. Furthermore, HashiCorp explicitly states that secrets are not shared through the MCP server and that AI access is activated only at prompt time (with no persistent connections or background data exchanges), meaning the AI is never constantly peering into your infrastructure behind the scenes.
What makes it dangerous: Accidental applies, excessive privileges, and secrets
Behind the convenience lie three risks that custom development projects must eliminate without fail.
The first is accidental applies. Natural language is inherently ambiguous. There is always a risk that an instruction like "clean up the old staging environment" could be interpreted by an AI as a plan that includes a destroy against a production workspace. Unsafely enabling execution commands like plan_and_apply creates a pathway for production changes that bypass human review.
The second is excessive privileges. If you grant broad permissions to the token or service account used by an MCP server, the AI effectively inherits those exact same permissions. We addressed this dynamic in AWS MCP Servers and IAM Governance Custom Development; with Terraform MCP, the correct mental model is that the API token supplied to MCP defines the AI's exact operational blast radius.
The third is leakage of confidential data. Outputs from plan, variables, and state files contain sensitive data such as IP addresses, connection strings, and internal topology. Feeding these directly into an AI context risks exposing internal configurations to LLMs hosted outside your cloud boundaries.
In summary: accidental applies are prevented by stopping at plan and using approval gates; excessive privileges are mitigated via least privilege and environment isolation; and confidential data leakage is contained through output filtering and environment restrictions. The crucial point is blocking these pathways upfront during initial design rather than retrofitting safeguards later.
Governance design: Designing boundaries rather than merely granting access
The core principle of governance is straightforward. It is not about whether to let AI touch Terraform; it is about establishing fixed boundaries through design. We combine the following five principles.
Start with read-only access
Do not enable execution operations from the start. Restrict --toolsets to read-only operations like registry queries and guide lookups, starting with use cases where the AI explains diffs from plan. This alone significantly resolves person-dependency.
Stop at plan + approval gates
Even when enabling write operations, restrict the AI agent's path to stopping at plan, executing apply only on the CI/CD pipeline side following human approval. The default rule is to block any direct apply path from MCP to production.
# 統制方針のイメージ（実際の構成はクライアント環境に合わせる）
# 環境ごとに「AI エージェントに許す toolset」を分ける
ai_agent_access:
dev:
toolsets: [registry, operations] # 検証環境は plan+apply まで許容
apply: agent_allowed
production:
toolsets: [registry] # 本番は読み取り照会と plan 説明のみ
apply: human_approval_required # apply は CI のレビュー済みパイプライン経由
# 本番での自然言語からの安全な流れ（イメージ）
# 担当者「本番の DB サブネットを 2 つ増やすとどうなる?」
# → AI が該当ワークスペースを照会し plan を生成・差分を日本語で説明
# → 担当者がレビュー、問題なければ PR を承認
# → apply は CI が実行（AI 経路では apply しない）Least privilege and environment isolation
Assign tokens and service accounts to the MCP server with least privilege, separated by environment and intended use. Never share a single high-privilege token across production and staging. This reflects the principle of tightening permissions at each connection point, aligning with agent access design for internal systems.
Audit logs
Track who did what, when, using which natural-language prompt, and against which workspace. Include in your initial setup audit logs that correlate chronological operations between MCP activities and CI-side applies. The key is mapping HCP Terraform / Terraform Enterprise run histories directly to agent prompt histories.
Preventing secrets leakage
Establish clear policies to mask or exclude sensitive values found in variables, state, and plan outputs from the AI context. For production environments, limit even read access, validating AI behavior using dummy data in staging before expanding scope.
Our custom development approach: 4 phases
We structure our projects into four distinct phases. First, in Assessment (approx. 2 weeks), we audit existing Terraform configurations, workspaces, and token permissions to pinpoint areas of person-dependency. Next, in Governance Design (approx. 2 weeks), we establish policies for toolset selection, environment isolation, approval gates, audit logging, and secret masking. In the subsequent PoC (approx. 2–3 weeks), we build out read-only and plan-capped workflows in staging, deliberately feeding ambiguous or hazardous instructions to test agent behavior. Finally, in Phased Rollout (approx. 3–4 weeks), we gradually introduce read queries into production, establish CI approval pipelines, and transition the system into daily operations.
At manufacturing Company A mentioned earlier, during Phases 1 and 2 we pre-emptively introduced a workflow where the AI simply explained plan in Japanese. Team members were suddenly able to inspect diffs previously decipherable only by the departing engineer, resolving person-dependency well before granting apply permissions.
Ideal vs. unsuited scenarios
| Well-suited | Proceed with caution |
|---|---|
| Terraform / IaC already exists (codebase is an established asset) | IaC adoption has not yet started |
| Diff reviews are dependent on specific individuals | Multi-person review workflows are already functioning effectively |
| Currently using HCP Terraform or Terraform Enterprise | State is managed solely via local CLI without historical tracking |
| Staging environments can be cleanly isolated from production | Single production environment with no room for experimentation |
If IaC adoption is still ahead of you, the proper sequence is to start with IaC standardization. MCP is designed to sit atop well-structured IaC; introducing it without that foundation results in weak governance.
Common pitfalls to avoid
Pitfall 1: Enabling all execution commands right away. Opening up --toolsets entirely out of enthusiasm creates an unprotected apply pathway to production. Starting with read-only operations is an ironclad rule.
Pitfall 2: Reusing tokens. Sharing a broadly scoped token between production and staging destroys the principle of least privilege. Separate them by environment.
Pitfall 3: Postponing audit logging. If you cannot trace who authorized what change, you cannot maintain accountability for AI-driven modifications. Integrate logging as a mandatory requirement from day one.
Pitfall 4: Allowing production access without masking secrets. Connection strings in variables and plan outputs will flow straight into the LLM context. Restrict production reads and validate behaviors thoroughly against test data before expanding access.
Conclusion: Designing boundaries rather than merely granting AI access
With the general availability of Terraform MCP Server, the era of AI agents operating IaC via natural language has arrived. However, real value comes not from jumping blindly onto the bandwagon, but from designing deliberate controls: starting with read-only operations, stopping at plan, implementing approval gates, and enforcing least privilege and audit logging. The key to unlocking siloed infrastructure lies in having AI explain diffs, well before handing over apply permissions.
Start small. The first step is enabling read queries and plan explanations in a staging environment. The second step is aligning approval gates and audit logs before expanding into production.
If you are looking to safely delegate IaC to AI without risking production, enable broader teams to review person-dependent Terraform code, or integrate MCP operations into audit logs, please reach out via our contact form.
Sources
- Terraform MCP Server Enables AI Assistants to Interact with Terraform Infrastructure（InfoQ）
- Terraform MCP server is now generally available（HashiCorp）
- Terraform MCP server overview（HashiCorp Developer）
- Build secure, AI-driven workflows with new Terraform and Vault MCP servers（HashiCorp）
- OpenTofu/Terraform Migration and IaC Governance Development (GH Media)
- IaC Standardization with CDK/Terraform Development (GH Media)
- AWS MCP Servers and IAM Governance Custom Development (GH Media)
- Agent Access to Internal Systems via MCP Tunnels (GH Media)
- Complete MCP Guide (GH Media)
