HashiCorp has introduced Terraform policy (tfpolicy), a new policy-as-code framework built directly into Terraform. Now available in public beta on HCP Terraform, tfpolicy lets platform teams write governance rules in HCL, the same language they already use to define infrastructure, rather than reaching for a separate policy tool and a separate syntax.
The launch addresses a problem that’s grown alongside Terraform itself. As infrastructure estates expand across hybrid cloud environments, platform teams are managing systems spanning public cloud providers, SaaS platforms, on-premises infrastructure, and internal platforms, often with multiple teams contributing changes via Terraform. That sprawl has pushed teams toward multiple tools and disconnected policy workflows just to maintain consistent governance.
Why the Old Model is Straining
Policy as code isn’t new. HashiCorp’s own Sentinel and the open-source Open Policy Agent (OPA) have handled this job for years, enabling organizations to codify compliance requirements and automate security checks. Both work by treating policy as a separate evaluation layer that sits atop an infrastructure plan, either passing or blocking it.
That separation was useful when it was introduced, but it comes with a tradeoff. A 2025 academic review of policy enforcement in Terraform workflows noted that Sentinel is deeply integrated into the Terraform Enterprise ecosystem and offers fine-grained, context-aware policy controls. In contrast, OPA is a general-purpose engine that connects to Terraform via separate tooling such as Conftest and custom CI/CD pipelines. Either path means learning a second language and maintaining a second toolchain alongside the Terraform code itself.
Industry analysis of policy rollouts points to a related issue: policies embedded directly in Terraform files are difficult to manage consistently across many modules and teams, and policy logic often blurs with infrastructure code, violating the separation of concerns. Teams end up choosing between a bolted-on external engine or scattered inline checks, and neither option fully closes the gap.
What tfpolicy Changes
HashiCorp built tfpolicy directly on Terraform and its provider ecosystem, so policies can evaluate infrastructure across any provider Terraform already supports, without a separate policy language to learn or a separate system to operate. That’s the core pitch: one language, one workflow, less context-switching.
The more interesting part is what tfpolicy can evaluate that older frameworks generally can’t:
- Resource relationships. Instead of checking resources one at a time, tfpolicy can look at how they connect. HashiCorp’s example: requiring every IAM role to have at least one policy attached, a rule that only makes sense when you can see the relationship between two resources at once.
- Data source lookups. Policies can pull in external context at evaluation time, such as checking that an EC2 instance uses only AMIs from an approved inventory, rather than relying on values hardcoded into the policy itself.
- Provider and module download controls. tfpolicy can block unapproved providers or modules before they’re used in a workflow, a step toward treating the software supply chain, not just the deployed infrastructure, as part of governance.
- Post-deployment evaluation. Not every issue shows up in a plan. tfpolicy can check policies against the infrastructure after it’s provisioned, catching issues such as provider-generated ARNs or identifiers that only exist once a resource is live.
That last point matters more than it might sound. Most policy engines are gatekeepers: they run before an application and either let it through or don’t. tfpolicy extends governance into the infrastructure’s actual lifecycle, checking the real state rather than only the planned state.
Where This Fits
tfpolicy isn’t replacing Sentinel or OPA outright; HashiCorp still supports both. But for teams already standardized on Terraform, it removes a real barrier to adoption: the need for a second team or a second skill set just to write policy. HashiCorp is also positioning it as approachable for AI-assisted workflows, releasing an agent skill for writing and testing tfpolicy files and converting existing Sentinel policies.
Mitch Ashley, VP and practice lead for software lifecycle engineering and AI-native software engineering at The Futurum Group, sees this as more than a convenience play. “Embedding policy evaluation into Terraform’s provider ecosystem, including checks against live infrastructure after provisioning, shifts policy from a pre-apply gate to a continuous property of the deployment lifecycle,” Ashley said. “Resource-relationship and data-aware checks let governance reason about connected, live systems instead of static plans alone.”
That shift raises a real question for platform teams already running a separate policy engine. “Platform teams on Terraform now have to weigh whether a bolted-on policy engine still earns its complexity once native, lifecycle-aware checks live in the same toolchain,” Ashley said. “Competing governance tools will need to match that depth or become redundant overhead.”
The bigger trend here isn’t really about Terraform. It’s about governance moving closer to the tools people already use, instead of living in a separate system they have to context-switch into. Academic researchers studying policy-as-code adoption have flagged the steep learning curve of dedicated policy languages as a real barrier to consistent enforcement — folding governance into HCL is a direct answer to that friction.
tfpolicy is now available in public beta via HCP Terraform. Documentation and getting-started guidance are available through HashiCorp’s developer portal.
