Terraform Introduces tfpolicy, an HCL-based Policy-as-Code Framework

Sergio De Simone · rss · 2026-07-29 source ↗ Reader 🖥️

practical · expository — A short news report relaying HashiCorp's own framing of a new product (tfpolicy); it argues implicitly for adopting the tool by contrasting it favorably with existing policy-as-code approaches, but does so mostly by quoting HashiCorp rather than building an independent case.

Structure

Key terms

• tfpolicy
  HashiCorp's specific new HCL-based, declarative policy-as-code framework built directly into Terraform's own workflow, distinct from the generic category 'policy as code' and from HashiCorp's older Sentinel product.
• relationship-aware / contextual policy evaluation
  Evaluating policy rules against how resources relate to each other and against external data-source lookups, rather than validating each resource's attributes in isolation at plan time.
• post-deployment evaluation
  Checking policy compliance against the actual, already-provisioned infrastructure state, not just the planned change set — catching violations only visible after resources exist.

Propositions

• explicittfpolicy integrates policy creation and enforcement directly into Terraform's native HCL workflow, eliminating the need for a separate policy language or tool.conf: high
• explicitExisting policy-as-code solutions such as Sentinel and OPA operate as separate validation layers that fail to incorporate contextual information — such as relationships between resources that change over the infrastructure lifecycle.conf: high
  refinesGoverning AI in the Cloud: A Practical Guide for Architects · p9 — p9 credits policy-as-code engines like OPA/Rego and Sentinel with evaluating contextual rules (data age, environment, approvals) at runtime; this document narrows the claim by pointing out a specific context type — relationships between resources across the infrastructure lifecycle — that HashiCorp says those same engines structurally miss, which is exactly what tfpolicy is built to add.
• explicittfpolicy evaluates policies both before and after deployment, against actual provisioned infrastructure state rather than only planned changes, catching violations that only become visible once resources exist.conf: high
  extendsAchieving Compliance as a Platform Engineering Team by Helping Developers · p3 — tfpolicy's before-and-after-deployment evaluation is a concrete product realization of the generic prevention-then-detection governance sequencing pattern, extended so 'detection' can catch violations from actual provisioned state rather than only pre-existing drift.
• explicittfpolicy extends policy enforcement to the software supply chain by controlling which providers and modules can be downloaded, preventing accidental use of unapproved dependencies.conf: high
• explicittfpolicy's full capability set (relationship-aware evaluation, post-deployment checks, supply-chain controls) is available only within the managed HCP Terraform product; the standalone open-source Terraform CLI supports only local policy validation and testing.conf: high
• implicitBy continuing to support Sentinel while positioning tfpolicy as the preferred framework, and by gating tfpolicy's full functionality behind the managed HCP Terraform product, HashiCorp is steering governance-conscious customers toward its paid platform rather than toward vendor-neutral alternatives like OPA.conf: medium

Arguments

Questions addressed

• ✅ How can platform teams enforce infrastructure governance without maintaining a separate policy language and toolchain alongside Terraform?
  By embedding policy directly in Terraform's own HCL workflow (tfpolicy) instead of a separate DSL (Sentinel) or external engine (OPA).
• ✅ How can policy evaluation account for context that changes across the infrastructure lifecycle — e.g. relationships between resources — rather than validating resources in isolation at plan time?
  Via relationship-aware policy rules and data-source lookups, plus post-deployment evaluation against actual provisioned state.
• ⭕ Does concentrating both infrastructure definition and policy enforcement in the same HCL/HCP Terraform product create a governance vendor-lock-in risk, given that full tfpolicy capability requires the managed HCP Terraform service?

Gaps

• incompleteThe article reports no independent benchmarking, security audit, or production case study of tfpolicy; every functional claim traces back to HashiCorp's own announcement and quotes, with no outside verification that relationship-aware or post-deployment evaluation performs as described.
  Read next: Look for independent write-ups, HashiCorp's own tfpolicy documentation/examples, or user reports once tfpolicy exits public beta.
• incompleteNo detail is given on migration cost or fidelity for organizations with substantial existing Sentinel policy libraries, beyond noting that HashiCorp is introducing an AI agent that can 'convert' Sentinel policies — with no discussion of what such conversion misses or gets wrong.
  Read next: HashiCorp's tfpolicy/Sentinel migration guide and the linked agent-skills repository (github.com/hashicorp/agent-skills) for what the conversion agent actually handles.

Related documents

• Achieving Compliance as a Platform Engineering Team by Helping Developers
• Governing AI in the Cloud: A Practical Guide for Architects