tfpolicy: HashiCorp's quiet successor to Sentinel

No vendor stands up and says the product your governance runs on is legacy now. The pattern is gentler than that. A new thing ships "built for" the platform, the old thing is "still supported", and a migration tool appears near the bottom of the post. On 16 July, HashiCorp's tfpolicy announcement managed all three in one page.

The short version: tfpolicy is policy as code for Terraform, written in Terraform's own configuration language, in public beta in HCP Terraform now. If your organisation runs Terraform at any scale, someone on your platform team has already read that announcement. This piece is about what the people who own the budget should take from it.

Policy as code, minus the second language

Policy as code means writing your rules as executable checks instead of wiki pages: every storage account blocks public access, and nobody deploys a module the platform team hasn't approved. The check runs on every change, before the change happens. It is the difference between a standard and a hope.

On HashiCorp's platform that has meant Sentinel since 2017, or Open Policy Agent. Both work. Both carry the same tax: the rules are written in a language your team uses for nothing else. Sentinel is HashiCorp's own policy language, and OPA uses one called Rego. In practice the tax means one or two people can write policy, every request queues behind them, and governance moves at the speed of a side project.

tfpolicy removes the tax. Policies are HCL, the same language as Terraform itself, kept in files ending .policy.hcl that live in version control like everything else. From the reference documentation, a complete policy that stops anyone using an outdated version of an approved module:

module_policy "git::github.com/org/terraform-aws-vpc" "example" {
  enforce {
    condition     = core::semverconstraint(meta.version, ">= 2.0.0")
    error_message = "The official VPC module must be at version 2.0.0 or higher."
    info_message  = "VPC module version ${meta.version}."
  }
}

Every Terraform engineer you employ can read that today. That is the whole pitch, and it is a good one.

The framework also does things Sentinel found hard. Per the announcement, policies can follow relationships between resources, pull in outside context through data lookups, block unapproved providers and modules before they are even downloaded (a supply-chain control as much as a configuration check), and re-check infrastructure after deployment against values that only exist once a resource is real.

How to read the announcement

Sentinel is not deprecated. HashiCorp confirmed to trade press that Sentinel and OPA remain supported, and nothing in the announcement sets an end date. Read strictly, nothing you run today changes.

Now read it the way you would read a supplier's roadmap. The new capabilities land in tfpolicy and not in Sentinel. The same release includes an AI agent skill whose listed jobs are writing and testing tfpolicy files "or converting existing Sentinel policies". Vendors do not fund conversion tooling out of a product they intend to keep investing in.

None of this says rip Sentinel out. tfpolicy is a beta, and betas are for sandboxes. What it does say is that new Sentinel investment now carries a shelf-life question, and that question belongs in this quarter's planning rather than in the eventual GA post.

If you own a Sentinel estate

Organisations bought Terraform Enterprise and the upper HCP Terraform tiers partly for Sentinel. If that is you, nothing breaks tomorrow. The exposure is stranded investment: a policy library measured in years of platform-team time, readable by a shrinking pool of people, on a framework whose vendor has visibly moved its attention elsewhere.

Four questions for your platform lead, none of which needs a long meeting:

How many Sentinel policies do we run, and how many are mandatory rather than advisory? The mandatory ones are load-bearing. They are the part of any migration that has to be right.
Who can change them? If the answer is one name, that was a risk before July too.
What does the converter produce from a copy of our library today? An afternoon's experiment that prices the migration before anyone commits to it.
What would we want GA to look like before we move? Write the criteria down now, while nobody is excited: which paid tier it lands in, and how much of the library converts cleanly.

If you never adopted policy as code

Plenty of estates run Terraform with no policy layer at all, and the honest reason is the one above: nobody wanted to staff a second language for a part-time job. That reason has gone, so the decision is live again.

Check one thing before anyone gets excited: where enforcement runs. The tfpolicy CLI validates and tests policies locally. Enforcement on every run, the part that makes it governance rather than advice, is a feature of HCP Terraform, the paid managed platform. HashiCorp has been owned by IBM since February 2025, pricing is per managed resource, and the free tier was reshaped this spring (the legacy free plan retired on 31 March 2026; the current one covers 500 managed resources). tfpolicy is a useful capability and also a reason to be on the platform where it runs. Both things are true. Budget with both in mind.

The layer a plan check cannot see

tfpolicy evaluates the plan, which means it evaluates what goes through the pipeline. It has no view of the firewall rule someone opened in the portal on a Friday afternoon, because that change never generates a plan.

Two layers, two jobs. tfpolicy gates what goes through the pipeline. Azure Policy audits what exists, however it arrived. The portal path is why the second layer is not optional.

That is why plan-time policy pairs with the runtime layer instead of replacing it. On Azure the runtime layer is Azure Policy, which watches everything in the estate regardless of how it arrived, and which you already own: a built-in catalogue of roughly 5,000 rules that costs nothing to run and is switched off in most estates. Gate the pipeline with one, audit the estate with the other. An estate with only the gate is blind to the portal. An estate with only the audit finds out about mistakes after they deploy instead of before.

This week, in four moves

Ask for the Sentinel numbers. How many policies run, how many are mandatory, who can maintain them, and when they last changed. Stale mandatory policies are their own finding.
Pause net-new Sentinel work unless something regulatory forces it. Most new rules can wait for a clearer picture, and a fair share of them belong in Azure Policy anyway.
Run the converter against a copy of the library and report what survived. One afternoon turns the migration from a debate into a number.
Not on HCP Terraform? Do nothing here yet. Check the runtime layer instead: if Azure Policy is not assigned across your estate, that gap is bigger than anything in this post.

One more thing worth filing away. tfpolicy ships platform-first, with the open CLI getting the local-testing satellite version. Whether that becomes the shape of Terraform releases under IBM is a fair question to raise at renewal time.

More useful tidbits coming — one a week.