Infrastructure as code was supposed to make cloud changes reviewable, repeatable and auditable. In 2026 a new author has joined the pull request: the AI agent. Coding assistants and autonomous agents now generate Terraform and OpenTofu modules, propose fixes for failed plans, explain drift and, in some organizations, open and update infrastructure pull requests without a human typing a line of HCL. Vendor tooling has moved quickly to support this, with Model Context Protocol (MCP) servers that give agents structured access to module registries, workspaces, plans and policies.
The opportunity is real: faster delivery, fewer copy-paste errors, better documentation and more consistent use of approved patterns. So is the risk. An agent that misunderstands a request can open a security group to the internet, delete a stateful resource or create an expensive cluster in seconds. This article explains what is changing, where the risks sit, and a layered guardrail model that lets you benefit from agentic infrastructure as code without handing over the keys.
What Changed in 2025–2026
Three developments turned AI-assisted infrastructure from autocomplete into something closer to delegation.
- Agents gained structured context. MCP servers for infrastructure tools give agents authoritative information instead of relying on a model’s general training. HashiCorp’s local Terraform MCP server reached general availability in 2026, and at HashiConf in October 2026 the company announced a remote MCP server in public preview that connects agents to HCP Terraform without local installation. HashiCorp describes agents using it to discover approved modules, generate code, analyze plans in natural language and read workspace information.
- Agents gained the ability to validate. According to HashiCorp’s June 2026 description of real-world patterns, the Terraform MCP server can run validation, speculative plans and linting, interpret the results and suggest fixes. That closes the loop: an agent can iterate until a change passes checks.
- Policy as code is catching up. HashiCorp made its HCL-based Terraform policy framework generally available in October 2026, with checks before and after deployment and tooling to convert existing Sentinel and OPA policies. Similar policy engines, including Open Policy Agent, Checkov and cloud-native guardrails, are available across ecosystems.
Industry analysts have noted the strategic direction. Futurum Group, reviewing HashiCorp’s 2025 announcements, described a push toward “agentic infrastructure” and cautioned that technical capability alone will not create the operational trust enterprises need before handing infrastructure decisions to agents. That caution is the right starting point.
Where Agents Add Value, and Where They Add Risk
It helps to separate infrastructure work into tasks by blast radius.
Low-risk, high-value tasks
- Explaining existing code, modules and plans in plain language for reviewers and new team members.
- Drafting new configurations from approved modules in a private registry.
- Upgrading provider versions and identifying breaking changes across many repositories.
- Writing and testing policies, documentation, examples and unit tests for modules.
- Summarizing drift and suggesting whether to reconcile code or infrastructure.
Higher-risk tasks
- Changing network exposure, identity and access policies or encryption settings.
- Modifying or replacing stateful resources such as databases, storage buckets and message queues.
- Importing unmanaged resources into state, where mistakes can cause later destroys.
- Creating high-cost resources such as GPU clusters or large data warehouses.
- Applying changes directly to production without a human approval.
The guardrail model below lets agents do most of the first list freely, do the second list only with strong controls, and never bypass human approval for production changes until your evidence says it is safe.
Let agents write and explain infrastructure freely, but make the pipeline, not the prompt, decide what is allowed to reach production.
A Layered Guardrail Model for Agentic IaC
No single control is enough. Use layers so that a failure in one is caught by the next.
Layer 1: Golden patterns and approved modules
Agents are only as safe as the building blocks they reuse. Publish opinionated, versioned modules for common needs, such as a network, a database, a Kubernetes cluster or a static website, with secure defaults baked in. Point agents at your private registry through MCP or documentation, and instruct them to compose approved modules rather than writing raw resources. HashiCorp’s guidance makes the same point: grounding agents in organizational context reduces the risk of relying on a model’s general knowledge.
Layer 2: Identity and least privilege for agents
- Give each agent its own identity, never a shared human or administrator credential.
- Scope agent permissions to planning and pull request creation by default. Plans run with read-only cloud credentials; applies run only in the pipeline with separate credentials.
- Use short-lived, federated credentials rather than static keys, and log every action against the agent identity.
- Restrict which workspaces, accounts, subscriptions or projects an agent can see at all.
Layer 3: Policy as code before and after deployment
Encode the rules that matter in a policy engine and run them on every plan, whoever wrote the code. Typical policies cover allowed regions, mandatory tags, encryption, public network exposure, approved instance types, cost thresholds and protection of stateful resources against deletion. Run policies again after deployment, or use continuous compliance scanning, to catch changes made outside the pipeline.
Layer 4: Pipeline gates and human review
- All agent changes arrive as pull requests with the plan output attached.
- Automated checks run formatting, validation, linting, security scanning, policy evaluation and cost estimation.
- Any plan that destroys or replaces a stateful resource, widens network exposure or changes identity policy requires explicit human approval from an owner.
- Production applies always require a named human approver, at least until you have a track record that justifies relaxing this for narrow, well-tested change types.
Layer 5: Observability, audit and rollback
- Record which agent and which prompt or task produced each change, and keep the conversation or reasoning summary with the pull request.
- Monitor for drift and unexpected resources, and alert on changes made outside the pipeline.
- Practice rollback: know how to revert a change through code and how to restore stateful resources from backup.
Step-by-Step: Introducing Agents Into Your IaC Workflow
- Assess readiness. Agents amplify whatever process you have. If your modules are inconsistent, your state is scattered and your pipeline lacks policy checks, fix those first.
- Start read-only. Let agents explain code, plans and drift. Measure whether reviewers find the explanations accurate.
- Enable drafting in non-production. Allow agents to open pull requests against development environments using approved modules, with all automated checks on.
- Add policy authoring. Let agents help write and test policies, reviewed by your security team. This often produces quick wins.
- Expand to production pull requests. Allow agents to propose production changes, with mandatory human approval and stricter policies for sensitive resources.
- Automate narrow changes. Only after months of evidence, consider letting agents auto-merge specific low-risk change types, such as tag corrections or patch-level provider upgrades, with policy checks still enforced.
- Review regularly. Track metrics such as agent pull request acceptance rate, policy violations caught, incidents linked to agent changes and time saved.
Designing Modules and Repositories Agents Can Use Well
Agents perform best when the codebase is explicit about intent. Many of the practices that help agents also help human engineers, so this work pays off twice.
- Document every module input and output. Clear descriptions, types, validation rules and examples let an agent choose correct values instead of guessing. Validation blocks that reject unsafe inputs, such as a CIDR range of 0.0.0.0/0 for an administrative port, act as a guardrail inside the module itself.
- Keep modules small and composable. Large, multi-purpose modules with dozens of optional flags are hard for anyone to use correctly. Smaller modules with sensible defaults are easier for agents to compose.
- Mark stateful resources. Use lifecycle protections such as prevent_destroy on databases and critical storage, and deletion protection settings offered by cloud providers, so that an accidental replacement fails loudly.
- Provide repository instructions. Many coding agents read a repository-level instruction file. Use it to state conventions: which modules to use, naming and tagging rules, how to run checks locally and which changes always need a human owner.
- Separate environments clearly. Distinct workspaces, state files and credentials for development, staging and production make it harder for an agent, or a person, to change the wrong environment.
Measuring Whether Agents Are Helping
Agent adoption should be judged on evidence, not enthusiasm. Agree on a small set of measures before the pilot starts and review them monthly with platform, security and finance stakeholders.
- Lead time for infrastructure requests: the time from a request to a merged, applied change, compared with the period before agents were introduced.
- Acceptance rate: the share of agent-authored pull requests merged without major rework.
- Policy catch rate: how many violations policy checks catch in agent changes, and whether that number falls as modules and instructions improve.
- Change failure rate: incidents, rollbacks or emergency fixes linked to agent-authored changes, tracked separately from human-authored ones.
- Cost signals: unexpected spend from resources created by agent changes, surfaced by cost estimation in the pipeline and by FinOps reporting.
If change failure rate or unexpected cost rises, pause the expansion of agent autonomy and strengthen the relevant layer before continuing. The goal is a steady, evidence-based widening of what agents can do.
Pitfalls to Avoid
- Giving agents administrator credentials “just for the pilot.” Pilots have a way of becoming production. Start with least privilege.
- Trusting a clean plan. A plan that applies successfully can still be wrong: insecure, expensive or not what was asked. Policy and human review exist for this reason.
- Skipping state hygiene. Imports and refactors generated by agents can produce confusing state moves. Review moved and removed blocks carefully.
- Prompt injection through code and documentation. Agents that read repository files, issues or module documentation can be misled by malicious content. Treat inputs as untrusted and keep tool permissions narrow.
- Vendor lock-in through tooling. Some agent features are tied to a specific platform. Keep your modules and policies portable, especially if you run both Terraform and OpenTofu.
- No ownership. Every agent change needs a human owner who is accountable for it, just as with human-written code.
A Hypothetical Worked Example
A hypothetical retail company runs its AWS and Azure infrastructure through Terraform, with about 200 workspaces and a private module registry. Its platform team receives many small requests from product teams: new environments, additional storage, database parameter changes.
- Month 1. The team connects an AI coding agent to the module registry and documentation through an MCP server, with read-only access to plans. Reviewers use agent summaries of plans; they report that summaries speed up review but occasionally miss implicit replacements, so the team adds a rule that the agent must list every resource marked for replacement.
- Month 2. Product engineers can ask the agent to draft environment changes in development workspaces. All changes arrive as pull requests with policy and cost checks. Policy violations, such as missing tags or public buckets, are caught and fixed by the agent before review.
- Month 3. The security team uses the agent to draft new policies for encryption and network exposure, which they review and test before enforcing.
- Month 4 onward. Agents can open production pull requests. Changes to databases, identity and networking require approval from the platform team; tag-only changes can merge after automated checks.
The example is illustrative, but the sequence matters: expanding agent autonomy only as each layer of control proves itself.
Outlook: Toward Governed Autonomy
Infrastructure platforms are converging on a model in which developers and agents consume approved patterns through governed self-service portals, with policies evaluated continuously and infrastructure graphs providing context about relationships and risk. HashiCorp’s Terraform Developer Portal and Infragraph announcements point in this direction, and cloud providers are building similar agent governance into their own control planes. Over the next few years, expect agents to handle a growing share of routine infrastructure changes, while humans focus on defining patterns, policies and exceptions. The organizations that benefit most will be those that invest now in clean modules, strong policy as code and pipelines that treat every author, human or agent, the same way.
Conclusion
AI agents are already writing infrastructure code. The question is whether they do it inside a governed system or around it. Build on approved modules, give agents their own least-privilege identities, enforce policy as code before and after deployment, keep human approval for high-risk and production changes, and audit everything. With those layers in place, agentic infrastructure as code becomes a productivity gain rather than a new source of incidents.
How Hanoi Technology Can Help
Hanoi Technology helps platform teams build approved module libraries, policy-as-code pipelines and safe workflows for AI-assisted infrastructure changes.