An Agent Converts Sentinel and OPA Policy Into Terraform Policy

TL;DR

• Terraform policy is a declarative framework from HashiCorp for writing rules in HCL that decide whether a Terraform plan may proceed, and HCP Terraform evaluates those rules during a run.
• The same gate accepts three frameworks, Terraform policy, Sentinel and Open Policy Agent, and only Terraform policy sets apply to Stacks as well as workspaces, which is the practical reason a team migrates.
• HashiCorp shipped the Terraform policy agent on 5 November 2026: it converts Sentinel and OPA policies into Terraform policy, and writes a policy file, a test file, supporting configuration and a conversion report for each one.
• The conversion runs in three stages, and the first one ends before any code exists, with plain-language policy goals a person can read and correct.
• Sentinel mock files feed the test generation, so scenarios your existing library already covers do not disappear in the rewrite.
• The announcement states the limit in its own words: passing the generated tests shows a policy meets the generated scenarios, and equivalence with the original is something a reviewer has to establish.
• The recommended rollout runs a converted policy at advisory enforcement while a team reads its behaviour, and moves to mandatory enforcement afterwards.
• Nothing the agent produces is published to HCP Terraform, so the library enters the gate only when someone puts it there.

Policy as code has always had an awkward dependency: the rules are written in a language few people on the team read fluently, which makes the gate powerful during a plan and opaque during a review. HashiCorp's answer, announced on 5 November 2026, is to bring the rules into HCL and to let a model do the translation. The model-led translation deserves the closest attention.

Terraform policy reached general availability with a declarative, HCL-based framework integrated into Terraform. The practical appeal is clear: infrastructure and its governing rules can both be described in HCL, kept in the same repository and reviewed by the same people. Manual conversion requires re-reading, rewriting and testing the policy library, which is the work the agent is designed to accelerate.

What Terraform policy decides

A policy is a rule that checks a plan before it becomes infrastructure. The documentation gives two examples that cover the range: a rule that production infrastructure lands in the correct region, and a rule that blocks new deployments on Fridays to keep production incidents inside working hours. Both are organisational decisions expressed as code. HCP Terraform evaluates them against the plan, and a failed policy can stop the run depending on its enforcement level.

Terraform policy requires Terraform v1.17 or later. Policies live in policy sets, a set can only hold policies written in a single framework, and several sets from different frameworks can apply to the same workspace or Stack. Failed policies can stop the run depending on their enforcement level, and the platform allows an override for identities with the right permissions.

Three frameworks, one gate

Stacks coverage provides a direct technical reason to migrate, and the documentation states the distinction clearly. Terraform policy sets apply to workspaces and Stacks. Sentinel and OPA policy sets support workspaces only. A team that has moved, or is moving, to Stacks keeps its Sentinel library outside the gate it now builds on.

That detail makes deployment coverage and language choice relevant to the migration. A policy framework that cannot see a deployment target is a framework with a hole in it, and the hole widens as more of the estate moves to Stacks.

A conversion that writes its own tests

The agent takes a Sentinel .sentinel file or an OPA .rego file, a list of files, or an entire policy repository, and works from the intent of each policy. HashiCorp describes three stages. The first extracts policy goals and turns them into plain-language requirements, which is a review artefact produced before any code exists. The second generates the .policy.hcl file, a .policytest.hcl file, supporting Terraform configuration and a conversion report. The third runs the generated tests and summarises the results per policy.

That first stage is the design decision worth copying, whatever anyone thinks of the model behind it. A conversion that starts with a readable statement of what the policy is for gives a reviewer something to disagree with early, when disagreement is cheap.

The sentence about equivalence

The announcement contains the caveat that matters, and it is unusually honest for a launch post. Output is generated by a language model, so results can vary between runs. Passing the generated tests shows that a policy meets the generated scenarios, and equivalence with the original Sentinel or OPA policy is a claim the author declines to make.

Read that against how policy libraries age. A Sentinel library is a record of decisions, including awkward ones: exceptions for legacy accounts, regions temporarily allowed during completed migrations, and tag rules tied to undocumented naming conventions. A conversion that works from intent will produce a policy that enforces the intent. Reviewers still need to check how the generated policy handles those exceptions.

Mock files as coverage

One mechanism deserves more attention than the launch post gives it. Where a Sentinel policy comes with mock files, the agent reads them after generating its first test scenarios and adds cases those scenarios did not already cover. Existing mocks are the closest thing a policy library has to a regression suite, and using them as a coverage source is the tactic that makes the generated tests worth running.

The tactic also sets the ceiling. Mocks describe scenarios the team thought about when the policy was written. Behaviour that no mock covers stays invisible, and a converted policy that passes every generated test can behave differently at the one edge the library never encoded.

A rollout that starts at advisory

HashiCorp's own advice is to run tfpolicy test on each converted policy, put the result into HCP Terraform at advisory enforcement, and move to mandatory once the behaviour has been validated. That order exists because a policy that blocks plans is a production incident generator, and a converted policy is new code by any reasonable definition.

The advisory stage only produces value if someone reads what it reports. Running a converted library at advisory and comparing its failures against the old framework's decisions gives the team evidence about the conversion before mandatory enforcement.

Where a converted library drifts

Several failure modes deserve attention before this agent is applied across a policy library. Silent widening lets a converted policy permit a case the original excluded. Silent narrowing can block a deployment that used to pass and prompt the team to relax the rule during the first week. A missing exception leaves a documented carve-out in the old library and causes the new one to enforce the general case against a workload nobody warned about.

These risks define the work that conversion review must cover. They are the reason the review step in the announcement is the load-bearing part, and the reason a policy migration belongs in DevOps pipelines and managed monitoring, where a failed plan stops on its own and the report reaches someone who reads it.

The reasonable reading of 5 November 2026 is that HashiCorp reduced the mechanical cost of a governance migration whose success still depends on human judgment. Using the conversion report as a design document and the advisory period as a validation exercise gives the team a policy library it understands. Relying on a passing test suite as proof of equivalence can leave the gate looking identical from the outside and deciding differently on the day it matters.

Sources

• Migrate Sentinel and OPA policies to Terraform policy faster with the Terraform policy agent, HashiCorp, 2026-11-05, hashicorp.com
• Policy enforcement overview, Terraform documentation, HashiCorp, developer.hashicorp.com

Source: the HashiCorp announcement of 5 November 2026 and the Terraform policy enforcement documentation, read in full. The three-stage workflow, the generated file types, the mock-file behaviour, the equivalence caveat, the advisory-to-mandatory advice and the statement that nothing is published to HCP Terraform come from the announcement; the frameworks, the Stacks limitation, the Terraform v1.17 requirement, the one-framework-per-set rule and the enforcement override come from the documentation.