Terraform Policy as Code: Inside HashiCorp's New tfpolicy Framework

On 16 July 2026, HashiCorp introduced tfpolicy — a new policy-as-code framework built natively into Terraform, now in public beta on HCP Terraform. Unlike Sentinel and Open Policy Agent (OPA), which run as a separate layer in a separate language, tfpolicy lets you write governance rules in HCL — the same language you already use for your Terraform configuration — and enforce them at three points in the workflow: provider/module download, plan time, and after infrastructure is actually deployed. This guide covers why that last part matters, how tfpolicy compares to Sentinel and OPA, and how to start using it.

Why Terraform Needed a Native Policy Layer

Code review does not scale as a governance strategy once more than a couple of teams are applying Terraform. Someone eventually ships a public storage bucket, an oversized VM the budget cannot absorb, or a provider version nobody vetted for supply-chain risk — not out of carelessness, but because no automated gate existed to catch it before apply. Policy as code closes that gap: rules committed to version control, evaluated automatically, and enforced consistently regardless of which engineer wrote the configuration.

• ●Security guardrails — block public storage, require encryption, restrict inbound security group rules
• ●Cost controls — cap VM sizes, restrict regions, flag unbudgeted resource types
• ●Tagging and naming standards — enforce mandatory cost-center or owner tags on every resource
• ●Supply-chain restrictions — allowlist approved providers and modules before they are even downloaded
• ●Compliance mapping — codify CIS, SOC 2, or internal audit requirements as automated checks

The Established Options: Sentinel and OPA

Sentinel is HashiCorp's original policy-as-code language, built specifically for the Terraform (and Vault, Consul, Nomad) ecosystem — but it is a paid feature, available only inside HCP Terraform's Team & Governance tier or Terraform Enterprise. It is not usable with plain open-source Terraform CLI. Open Policy Agent (OPA), by contrast, is fully open source and general purpose — you write rules in Rego and evaluate them against a terraform plan converted to JSON, typically via Conftest in a CI pipeline. That flexibility comes at a cost: Rego is a declarative query language unrelated to HCL, so teams pay a real learning-curve tax to adopt it.

What's New: Introducing tfpolicy

tfpolicy removes the second-language problem. Policies are written in HCL using policy, locals, and enforce blocks that follow the same patterns as everyday Terraform configuration — no context-switching between an infrastructure file and a policy file in a different syntax. It can also evaluate resource relationships rather than one resource in isolation (for example: "every IAM role must have at least one policy attached"), pull in external data through provider data sources during evaluation, and — its most distinctive capability — evaluate policies after deployment, checking provider-computed values like generated ARNs or resource IDs that simply do not exist at plan time.

# require_iam_policy_attached.tfpolicy.hcl — illustrative structure
policy "require_iam_role_policy_attached" {
  resources = core::getresources("aws_iam_role")

  enforce {
    condition = length(each.value.attached_policies) > 0
    message   = "Every IAM role must have at least one policy attached."
  }
}

Three Enforcement Points: Init, Plan, and Apply

• ●Setup (terraform init) — provider and module policies evaluate before anything is even downloaded, cutting off supply-chain risk at the source rather than catching it after the fact
• ●Plan time — the familiar pre-apply gate: resource attributes, relationships between resources, tags, naming, and restricted regions or instance types
• ●Apply time (post-deployment) — evaluates real, provider-computed values that only exist once resources are created, such as generated ARNs or assigned IDs; this is the check Sentinel and OPA cannot perform, since both operate purely against the plan

tfpolicy vs Sentinel vs OPA — Which Should You Use?

Migrating Existing Sentinel Policies

HashiCorp published a tfpolicy agent skill for AI coding agents that can write and test tfpolicy configurations, and convert existing Sentinel policies into the new format. If your organization already has a Sentinel policy library, that conversion path is the fastest way to try tfpolicy without hand-rewriting every rule from scratch.

We cover Checkov, Terrascan, tflint, and the rest of the open-source quality-gate stack in our Terraform ecosystem guide — those tools solve a different problem (linting, generic security scanning, cost estimation) and continue to run alongside tfpolicy or Sentinel rather than being replaced by them.

Getting Started Checklist

1. 1Confirm your organization has opted into the tfpolicy public beta inside HCP Terraform
2. 2Write policy files using policy, locals, and enforce blocks, and commit them to a VCS repository
3. 3Test policies locally with the tfpolicy CLI against sample plans before attaching them to a real workspace
4. 4Organize policies into policy sets scoped to a specific project, workspace, or tag — start with one low-risk workspace
5. 5Run new policies in advisory mode first, then switch to hard enforcement once you trust the results
6. 6Migrating from Sentinel? Try the tfpolicy agent skill to convert existing rules instead of rewriting them by hand

See the full curriculum on the DevOps course page, or test your current Terraform knowledge with the free Terraform TF-003 mock exam.

Ready to Start Your Cloud Journey?

Live batches Mon–Sat — Azure 9–10 AM IST (starts 3 august 2026) · AWS 10:30–11:45 AM IST (starts 31 august 2026). Hands-on labs, exam prep, and community support.

Keep Reading