HashiCorp's tfpolicy pulls policy-as-code back inside Terraform

For the first time in the Terraform stack, the policy layer and the infrastructure layer speak the same language. HashiCorp released tfpolicy, a native policy-as-code framework for Terraform, in public beta on HCP Terraform, per DevOps.com's report on July 20. Rules are written in HCL, the same syntax teams already use for their main.tf files. For pipelines that have been running policy checks as a separate step against a separate DSL, the change collapses one language and one runtime out of the plan-and-apply loop.

What actually shipped

Per HashiCorp, tfpolicy is not a bolt-on. It lives inside Terraform's provider ecosystem, so a policy can reason about any provider a plan touches. The evaluation surface goes beyond static plan inspection. Policies can look at resource relationships between connected pieces of infrastructure, pull in external data sources for context, gate provider and module usage, and evaluate deployed infrastructure after an apply, in addition to the planned state. HashiCorp also shipped an agent skill for writing and testing tfpolicy rules, plus a conversion tool aimed at existing Sentinel policies.

Sentinel is not deprecated. HashiCorp says it remains supported for organisations already on it. That matters for platform teams sitting on an existing Sentinel corpus with no appetite for a translation project on a beta target.

Why a native HCL layer changes the pipeline shape

The operational read is straightforward. In today's typical Terraform CI job, a plan is generated, then handed to a separate tool: Sentinel via HCP, OPA or Conftest via a container step, Checkov via a scanner call. Each brings its own DSL, its own binary version, its own error format and its own place to break at 3am. Collapsing the policy step into the same runtime as the plan means one fewer language to onboard reviewers on, one fewer version pin to babysit, and one fewer place for a diverging policy binary to fail a merge.

The reliability question sits on the other side of that trade. A native layer in beta is a single point of failure that runs in the same runtime as your applies. If tfpolicy misfires on an edge-case module, the failure lands inside the same job that would otherwise ship the change. Sentinel already runs in-line for HCP customers, so this shape is not new for them. For teams graduating from a separate OPA sidecar, the blast-radius picture shifts.

How the current stack handles the same problem

Policy-as-code for Terraform is a busy space, and each tool solves a slightly different piece.

• Sentinel. HashiCorp's original policy engine, embedded in HCP Terraform and TFE. Mature and well-understood, but the DSL is Sentinel-specific and lives outside the HCL your infra team writes.
• OPA and Rego. The CNCF policy engine that most Kubernetes-heavy shops already run. Rego is powerful once you have it, and the reason platform teams keep re-writing OPA tutorials is that it takes a while to internalise. For teams standardising a single policy engine across Kubernetes, cloud and Terraform, OPA is still the pragmatic pick.
• Conftest. OPA under the hood, aimed at CI use. You point it at plan JSON and get pass or fail. Easy to bolt on, but you inherit Rego's ergonomics.
• Checkov and tfsec/Trivy. Rule-library scanners for baseline hygiene: public storage bucket, unencrypted disk, missing tag. Weak once you need custom logic that reasons across resources, strong as a zero-config baseline.
• Kyverno for Terraform. A newer effort to bring Kyverno-style policies to plan JSON. Interesting if your team already speaks Kyverno in the cluster, otherwise premature.
• Buddy. As a general-purpose CI platform, Buddy is one place to wire any of the above into a pipeline: run a terraform plan, hand the output to Sentinel, OPA/Conftest, Checkov or now tfpolicy, and gate the merge on the result. If your policies already live inside HCP Terraform's own workflow, the HCP-native path is a better fit than adding an outside orchestrator. Buddy earns its keep for shops with heterogeneous stacks where the Terraform job is one of several CI stages, not the only one.

The framing choice for a platform team is less about which policy tool is best and more about where policy failure has to be legible. If your on-call rotation reads Terraform for a living, HCL policies are one fewer context switch during triage. If your platform standard is OPA everywhere, tfpolicy is another dialect to translate.

What to watch during the beta

Two beta-specific questions matter for anyone tempted to migrate now. First, coverage: HashiCorp lists live-infrastructure evaluation as a capability, and per the DevOps.com report the framework is public beta on HCP Terraform, which is where any answer to "does this scale to my provider surface area" will shake out. Second, the Sentinel-to-tfpolicy converter is exactly the tool that has to be right before a serious migration. Converters that get 80% of a corpus across and leave the other 20% quietly semantically different are the classic 3am surprise. Both need mileage before a policy team should move its blocking gates over.

For teams still on OPA or Conftest, there is no forcing function today. The upside is a native HCL policy layer that lands in the same runtime as the plan. The cost is a beta on HCP Terraform, and a rewrite. That trade is worth revisiting when tfpolicy leaves beta.