Top 12 Policy as Code (PaC) Tools in 2026

Policy as code (PaC) takes the same principles that transformed infrastructure management, declarative definitions, version control, testing, and automation, and applies them to organizational rules and guardrails.

Policies are written in code-like languages, stored in Git, and enforced automatically in pipelines or runtime environments. This includes both “decision engines” that evaluate policies at runtime and “static analyzers” that scan IaC before deployment.

In this article, we’ll explore some of the most widely used policy-as-code tools and platforms from general-purpose engines, cloud-native frameworks, and provider-specific solutions.

Policy as code (PaC) is the practice of writing governance, security, and compliance rules as machine-readable files that tools can automatically evaluate and enforce. It replaces static policy documents with automated checks in CI/CD, infrastructure provisioning, and runtime.

Common uses include blocking public S3 buckets, enforcing required tags, validating Kubernetes resources on admission, or failing Terraform plans that violate controls. You’ll often combine multiple layers: static checks in PRs, admission policies in clusters, and org-level guardrails in your cloud accounts.

Read more: What is Policy as Code (PaC) & How Do You Implement It?

Policy-as-code tools let teams define rules declaratively, integrate them into CI/CD pipelines, and audit changes through version control. They help enforce consistent security, compliance, and operational policies across environments. 

We will review the tools in the following categories:

Tool category	Stage	What you’re checking	Tools in this list
Misconfig scanning	Pre-commit / PR	IaC files before they reach main	Checkov
Terraform / IaC enforcement	IaC pipeline (plan / apply)	The proposed change against org rules	Spacelift, HashiCorp Sentinel
K8s admission control	Cluster admission	Kubernetes resources at creation	Gatekeeper, Kyverno, VAP
Cloud-provider guardrails	Cloud org	Permission boundaries across accounts	AWS SCPs, Azure Policy, GCP Org Policy
App authorization	Runtime authz	Who can do what inside your app	AWS Cedar
General policy engine	Cross-layer engine	The decision engine the others build on	Open Policy Agent

A typical setup looks like Checkov in CI, Spacelift gating the apply, Gatekeeper at admission, and SCPs as the last-line guardrail. Each layer catches the things the layer below it can’t see. The question isn’t “which one of these tools do I pick” but “where do I have a gap”.

Open Policy Agent (OPA) is an open-source, general-purpose policy engine that enables policy as code for cloud-native environments. It decouples policy decision-making from services by providing a unified way to define and enforce rules across microservices, Kubernetes, APIs, CI/CD pipelines, and infrastructure.

OPA uses a high-level declarative language called Rego to express policies. Once written, these policies can be applied consistently across a wide variety of systems, ensuring compliance, governance, and security requirements are met without embedding logic directly into application code.

OPA can run as a sidecar, daemon, or library and integrates with existing services via REST APIs, making it suitable for both real-time enforcement and offline analysis. OPA also integrates with Envoy/Istio via the official OPA-Envoy plugin and Istio’s CUSTOM external authz action, enabling fine-grained, policy-driven service authorization.

Open Policy Agent key features

• Unified policy engine for Kubernetes, microservices, CI/CD, data, and APIs
• Rego language for expressive, declarative policy definitions
• Decoupled decision-making via APIs, allowing consistent enforcement across systems
• Native Kubernetes integration (via Gatekeeper) for admission control and compliance
• Extensible integrations with Terraform, Envoy, Istio, and CI/CD pipelines
• Policy testing and validation to catch misconfigurations before deployment
• Community-driven ecosystem with wide adoption across cloud-native tools

Best for: Teams adopting cloud-native platforms and microservices who need a flexible, vendor-neutral way to enforce compliance, security, and governance policies.

Website: https://www.openpolicyagent.org

Adoption signals: ~11.8k GitHub stars, CNCF graduated project

Related: Conftest

For teams that want OPA’s policy model without standing up a server, Conftest is a small open-source CLI from the same project. It evaluates Rego policies against structured config files: Terraform plan JSON, Helm charts, Kustomize output, Kubernetes manifests, and Dockerfiles. 

The same Rego rules teams write for OPA proper run unchanged in Conftest, and it ships as a single binary that drops into a CI pipeline in a few lines of YAML. 

Gatekeeper is a Kubernetes-native policy controller that extends Open Policy Agent (OPA) to enforce custom admission policies within clusters. Built specifically for Kubernetes, it lets platform teams define, audit, and enforce constraints on cluster resources using Kubernetes Custom Resource Definitions (CRDs) and Rego policies.

Unlike OPA’s general-purpose scope, Gatekeeper is optimized for Kubernetes governance. It provides a framework to codify rules such as restricting container images, enforcing naming conventions, or ensuring labels and annotations are applied consistently. These policies are evaluated at admission time, preventing non-compliant workloads from being created.

Gatekeeper also supports audit functionality, allowing teams to identify violations across existing cluster resources. This dual focus on prevention and detection keeps compliance and security standards consistent in dynamic Kubernetes environments.

Gatekeeper supports an enforcementAction on constraints (e.g., deny, dryrun) and can integrate with Kubernetes ValidatingAdmissionPolicy (VAP). CEL-based policies enforced through Gatekeeper reached GA in v3.18, and VAP management through Gatekeeper is in beta as of v3.20, with sync-vap-enforcement-scope enabled by default in v3.22 (February 2026).

Gatekeeper key features

• Kubernetes-native integration via CRDs for defining policies and constraints
• Admission control enforcement to block non-compliant workloads at creation
• Cluster-wide auditing to surface policy violations in existing resources
• Template-based system for reusing and sharing common policies
• Configurable enforcementAction (including dry-run) to phase in policies
• Community-driven policy library with prebuilt constraints for common use cases

Best for: Kubernetes-focused teams seeking to implement policy enforcement and compliance at the cluster admission level, while benefiting from OPA’s flexibility.

Website: https://open-policy-agent.github.io/gatekeeper

Adoption signals: ~4.2k GitHub stars, part of the CNCF graduated OPA project

Kyverno is a Kubernetes-native policy engine that manages configuration, security, and compliance using familiar Kubernetes manifests. Policies are defined in YAML, so teams don’t need to learn a new language. This makes Kyverno approachable for Kubernetes operators who want governance built directly into their existing workflows.

Beyond validation, Kyverno can mutate and generate resources, automatically injecting labels, enforcing security contexts, or creating supporting objects. It also integrates smoothly with GitOps and CI/CD pipelines, offering policy testing and version control. 

With a strong focus on usability and a library of prebuilt policies, Kyverno helps teams standardize deployments and enforce best practices with minimal overhead.

Kyverno key features

• Kubernetes-first design with policies defined as standard resources
• Validation, mutation, and generation capabilities in a single tool
• No need for a new policy language: rules are written in YAML
• Policy testing framework for CI/CD and GitOps pipelines
• Prebuilt policy library covering security, compliance, and best practices
• Dynamic configuration with variable substitution and context-aware rules

Best for: Kubernetes operators and platform teams who want straightforward policy management using native Kubernetes patterns, without introducing new languages or abstractions.

Website: https://kyverno.io

Adoption signals: ~9k GitHub stars, CNCF graduated project (March 2026)

Kubernetes ValidatingAdmissionPolicy (CEL) is a built-in admission control mechanism that lets users define policies using Common Expression Language (CEL) without requiring external controllers. Introduced as a native alternative to OPA/Gatekeeper or Kyverno, it provides lightweight validation for Kubernetes resources directly within the API server.

This feature enables teams to enforce rules such as restricting image registries, validating labels, or ensuring field values meet specific patterns. Since policies are part of the Kubernetes API, they’re simple to manage and integrate naturally with standard workflows.

ValidatingAdmissionPolicy reached General Availability in Kubernetes v1.30 (admissionregistration.k8s.io/v1), with validationActions supporting Deny, Warn, and Audit.

ValidatingAdmissionPolicy (CEL) key features

• Native Kubernetes integration with no extra components to install
• CEL-based policies for lightweight, high-performance validations
• Enforce or audit modes to block or just record policy violations
• Lower operational overhead compared to external policy engines
• Good fit for simple validation rules directly in clusters

Best for: Kubernetes-only teams who want lightweight, object-scoped admission checks without running an external policy controller. For complex cross-object logic or external data lookups, OPA/Gatekeeper or Kyverno remain better fits.

Website: Kubernetes Admission Controllers

Adoption signals: Built into Kubernetes (CNCF graduated); GA since v1.30 (April 2024)

HashiCorp Sentinel is a policy-as-code framework integrated into the HashiCorp Cloud Platform (HCP) Terraform and other HashiCorp products. It provides fine-grained governance and compliance controls by letting teams define rules that must pass before infrastructure changes are applied.

Sentinel uses a purpose-built language that allows for conditional logic, iteration, and policy composition. With its deep integration into Terraform Cloud and Enterprise, Sentinel can evaluate proposed infrastructure changes in plan and apply phases, ensuring compliance checks are part of the standard workflow.

While more opinionated than general-purpose policy engines, Sentinel fits organizations already standardized on the HashiCorp ecosystem. It allows central governance teams to define guardrails while still giving developers flexibility within approved boundaries.

HashiCorp Sentinel key features

• Deep integration with HCP Terraform and other HashiCorp tools
• Custom policy language designed for infrastructure governance
• Enforcement levels (advisory, soft-mandatory, hard-mandatory) to control policy strictness
• Evaluation during Terraform plan and apply for proactive compliance checks
• Extensible imports for accessing Terraform data, cloud provider metadata, and external APIs
• Strong enterprise focus with centralized governance and team-based workflows

Best for: Organizations using HCP Terraform or Terraform Enterprise that need consistent, enforceable governance built directly into their infrastructure-as-code pipelines.

Website: https://developer.hashicorp.com/sentinel

Spacelift is an infrastructure orchestration platform purpose-built for infrastructure as code workflows. It offers a policy-as-code framework powered by Open Policy Agent, enabling teams to enforce governance, security, and compliance across Terraform, OpenTofu, Terragrunt, Pulumi, CloudFormation, Ansible, and Kubernetes deployments.

With Spacelift, policies are written in Rego and applied to different decision points in the workflow, such as triggering/push events, plan/run approvals, and task execution. This flexibility allows platform teams to create guardrails without slowing down developer productivity. Policies can be version-controlled, tested, and reused, ensuring governance evolves alongside infrastructure.

By combining policy as code with automation and collaboration features, Spacelift helps organizations manage multicloud environments with confidence. It integrates into Git-based workflows, supports drift detection, and provides real-time visibility into infrastructure changes while ensuring every step respects defined policies.

Spacelift’s approach emphasizes practical governance: enforcing the right checks at the right time without introducing unnecessary friction.

Spacelift key features

• OPA/Rego policies tied to specific pipeline events, not generic webhooks
• Multi-IaC support across Terraform, OpenTofu, Terragrunt, Pulumi, CloudFormation, Ansible, and Kubernetes
• Policies, drift detection, and self-service Golden Paths in one platform
• Spacelift Intelligence: AI-powered Infra Assistant and natural language provisioning via Intent
• Real-time visibility and audit trails for every infrastructure change

Best for: Teams looking for a modern infrastructure orchestration platform with built-in policy-as-code capabilities, AI-assisted provisioning, and governed self-service, especially in multicloud and hybrid environments.

Spacelift ratings and reviews:

• G2: 4.9/5 (11 reviews)

Website: https://spacelift.io

Check out this video where we dive into common use cases of Spacelift policies and how teams are using them to achieve security and cost control of their infrastructure:

Checkov is an open-source static analysis tool for IaC that brings policy-as-code to security and compliance scanning. It analyzes Terraform, CloudFormation, Kubernetes, Helm, Pulumi, and serverless frameworks to detect misconfigurations before deployment. By shifting policy enforcement left into development pipelines, Checkov helps teams catch issues early and reduce risk in cloud-native environments.

Policies in Checkov are written in Python or YAML and can be customized to enforce organizational standards. With a large library of built-in checks for common compliance frameworks (CIS, NIST, PCI-DSS, HIPAA), it offers immediate value out of the box while remaining flexible for custom rules. 

Checkov plugs into CI/CD systems and version control with a single binary, making it straightforward to adopt as part of day-to-day developer workflows.

Checkov key features

• Multi-IaC support: Terraform, CloudFormation, Kubernetes, Helm, Pulumi, Serverless
• Policy as code with customizable Python or YAML rules
• Built-in library for CIS, NIST, PCI-DSS, HIPAA, and other standards
• Shift-left security with CI/CD and Git integrations
• Rich reporting for visibility into misconfigurations and violations

Best for: Teams looking to strengthen IaC security and compliance with lightweight, flexible scanning directly in developer workflows.

Website: https://www.checkov.io

Adoption signals: ~8.7k GitHub stars, maintained by Prisma Cloud / Palo Alto Networks

Trivy is an open-source security scanner from Aqua Security that covers IaC misconfigurations, container images, file systems, and Git repos in a single binary. It picked up most of tfsec’s user base after Aqua consolidated tfsec into Trivy in 2023, and it now scans Terraform, CloudFormation, Helm, Kubernetes manifests, Dockerfiles, and more for policy violations.

Policies are written in Rego, so teams already using OPA can reuse rules across CI scanning and runtime enforcement. Trivy ships with built-in checks for common compliance frameworks (CIS, NIST, PCI-DSS) and integrates with the major CI systems and Kubernetes admission controllers.

Trivy key features

• One binary for IaC scanning, container scanning, and SBOM generation
• Rego policies, reusable across the rest of your OPA stack
• Built-in CIS, NIST, and PCI-DSS rule packs
• CI integrations for GitHub Actions, GitLab, Jenkins, and others
• Kubernetes admission controller mode for cluster-side enforcement

Best for: Teams who want a single open-source scanner across IaC, containers, and dependencies, and who already use Rego elsewhere.

Website: https://trivy.dev/

Adoption signals: ~35.2k GitHub stars, maintained by Aqua Security

Azure Policy is Microsoft’s native governance service that enables organizations to enforce compliance and security standards across Azure resources. When combined with as code workflows, policies can be defined, versioned, and deployed just like application or infrastructure code, bringing governance into CI/CD and GitOps pipelines.

Policies are authored in JSON and can be grouped into initiatives for broader compliance objectives. With integrations into tools like Azure DevOps, GitHub Actions, and Terraform, teams can embed Azure Policy evaluations into their delivery pipelines. This ensures every deployment is validated against organizational rules before reaching production.

Azure Policy supports remediation tasks for policies with DeployIfNotExists or Modify effects, allowing automatic correction of non-compliant resources.

Azure Policy (as code) key features

• Native Azure integration for real-time enforcement and remediation
• Policy as code with JSON definitions stored in Git for version control
• Initiatives to bundle multiple policies under compliance goals
• CI/CD and GitOps support via Azure DevOps, GitHub Actions, Terraform, and Bicep
• Built-in policy library covering security, cost, and compliance frameworks
• Remediation tasks to automatically fix non-compliant resources

Best for: Teams operating heavily in Azure who want governance and compliance fully aligned with their infrastructure-as-code and DevOps workflows.

Azure Policy ratings and reviews:

• G2: 4.3/5 (20 reviews)

Website: https://learn.microsoft.com/azure/governance/policy

AWS Service Control Policies (SCPs) are a governance feature of AWS Organizations that let administrators define fine-grained permission boundaries across accounts. They act as guardrails, ensuring that no IAM user or role within member accounts can exceed the restrictions set at the organizational level. In practice, SCPs make it possible to centrally enforce compliance and security requirements across multi-account AWS environments.

SCPs are written as JSON policies, similar to IAM policies, but are applied at the organization, organizational unit (OU), or account level. This allows platform teams to encode rules such as disallowing unapproved regions, blocking the use of certain services, or restricting resource configurations. 

By managing SCPs in source control, organizations can treat them as code: versioning, testing, and deploying policy changes alongside infrastructure code.

Note: SCPs do not grant permissions; they define the maximum available permissions. IAM identity or resource policies must still allow an action.

For teams adopting policy-as-code practices, SCPs provide a native AWS mechanism for ensuring consistent governance without external tools. They are especially useful for enterprises running multiple AWS accounts, offering centralized control that complements other security frameworks like IAM and Config Rules.

AWS Service Control Policies (SCPs) key features

• Centralized governance across AWS Organizations
• JSON-based policies similar to IAM for consistency
• Enforce guardrails by denying access to specific actions, services, or regions
• Integration with policy-as-code workflows through version control and IaC pipelines
• Scales across multi-account AWS setups for enterprise governance

Best for: Organizations with multi-account AWS environments that need strict, centrally enforced guardrails aligned with policy-as-code practices.

Website: AWS User Guide

Google Cloud Organization Policy is a native governance framework that lets administrators define constraints across Google Cloud resources. By setting organization-wide rules, teams can enforce security, compliance, and cost controls consistently across projects and folders. These policies act as guardrails, restricting what resources can be created or how they can be configured.

Policies are expressed as constraints (e.g., restricting resource locations, blocking external IPs, enforcing CMEK encryption) and can be applied hierarchically at the organization, folder, or project level. For Kubernetes, Google’s Policy Controller (built on OPA Gatekeeper) extends these capabilities to cluster admission control and auditing, with prebuilt bundles and console integration. This lets you unify cloud constraints and Kubernetes policies under a PaC model.

Google Cloud Organization Policy key features

• Centralized governance at org, folder, and project levels
• Constraints to enforce security, compliance, and cost rules
• Policy Controller (Gatekeeper-based) for Kubernetes policy enforcement
• Policy-as-code workflows via Terraform, Config Connector, and GitOps
• Audit and visibility into policy violations across resources

Best for: Enterprises operating in Google Cloud that want a unified, code-driven way to enforce constraints across both cloud resources and Kubernetes clusters.

Website: Organization Policy Overview and Policy Controller

AWS Cedar is a policy language created by AWS for defining fine-grained, context-aware authorization rules. It underpins Amazon Verified Permissions, which externalizes authorization decisions so policies can be managed separately from application code.

Policies are written in a declarative, human-readable format and support attribute- and context-based access control. Managed as code in version control, Cedar enables teams to apply policy-as-code practices to authorization while ensuring consistency and auditability.

AWS Cedar key features

• Purpose-built policy language for fine-grained authorization
• Integration with Amazon Verified Permissions for centralized management
• Attribute- and context-based access control (ABAC/CBAC)
• Readable, auditable policies stored and managed as code
• APIs for real-time authorization decisions across applications

Best for: Teams building applications on AWS that need scalable, centralized, and code-driven authorization with fine-grained access control.

Website: AWS User Guide

Cedar is AWS-stewarded, open-sourced in 2023, and now production-grade inside Amazon Verified Permissions. Community adoption outside the AWS ecosystem is still early, which is the main thing to weigh before standardizing on it for app authorization across a non-AWS stack.

Comparing the same intent across policy languages is one of the clearer ways to see where each of these tools fits. The example below expresses a single rule, “don’t let internal data become public,” in the five policy languages covered in this article.

Each tool operates at a different layer of the stack, so the resulting policy is shaped by what that layer can see and act on. The Terraform-focused languages evaluate infrastructure definitions before deployment, the Kubernetes-focused languages evaluate workloads at admission, and Cedar evaluates authorization requests at runtime. 

This is why most teams adopting policy as code rely on more than one tool: the same intent has to be enforced at the point where the corresponding risk actually appears.

Rego (OPA, Conftest, Spacelift, Trivy)

The following Rego policy, evaluated against a Terraform plan, identifies S3 bucket ACL resources configured for public read access.

package main

deny contains msg if {
  resource := input.resource_changes[_]
  resource.type == "aws_s3_bucket_acl"
  resource.change.after.acl in {"public-read", "public-read-write"}
  msg := sprintf("S3 ACL '%s' is publicly readable", [resource.name])
}

Sentinel (HCP Terraform)

The equivalent Sentinel policy, evaluated during the Terraform plan phase, applies the same check using Sentinel’s native syntax.

import "tfplan/v2" as tfplan

s3_acls = filter tfplan.resource_changes as _, rc {
  rc.type is "aws_s3_bucket_acl"
}

public_acls = filter s3_acls as _, rc {
  rc.change.after.acl in ["public-read", "public-read-write"]
}

main = rule {
  length(public_acls) is 0
}

Kyverno (Kubernetes admission)

Kyverno operates on Kubernetes resources rather than Terraform plans, so the equivalent rule targets a comparable risk in its domain: a Kubernetes Service exposing internal workloads through a public LoadBalancer.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: deny-public-loadbalancer
spec:
  rules:
    - name: block-loadbalancer
      match:
        any:
          - resources:
              kinds: [Service]
      validate:
        failureAction: Enforce
        message: "Public LoadBalancer Services are not allowed"
        pattern:
          spec:
            type: "!LoadBalancer"

Kubernetes CEL (ValidatingAdmissionPolicy)

The same Kubernetes-level intent expressed using CEL, evaluated by the API server directly without an external admission controller.

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: deny-public-loadbalancer
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
      - apiGroups: [""]
        apiVersions: ["v1"]
        operations: ["CREATE", "UPDATE"]
        resources: ["services"]
  validations:
    - expression: "object.spec.type != 'LoadBalancer'"
      message: "Public LoadBalancer Services are not allowed"

Cedar (Amazon Verified Permissions)

Cedar enforces policy at the authorization layer rather than at IaC plan time or Kubernetes admission. The following policy denies any request to apply a public ACL to an S3 bucket at the point the API call is made.

forbid (
  principal,
  action == Action::"s3:PutBucketAcl",
  resource is S3::Bucket
) when {
  context.requested_acl == "public-read" ||
  context.requested_acl == "public-read-write"
};

Policy as code brings governance, security, and compliance into the same workflows as infrastructure and application code. A real policy as code setup spans layers, combining a CI scanner, a pipeline-stage engine, and a cloud-org guardrail. Kubernetes shops add an admission controller. Application teams add an authorization engine. The right shortlist depends on where bad changes still slip through your delivery chain, not on which Rego dialect you prefer.