Explore the state of Policy as Code in 2026, from OPA and Rego to Kyverno, Cedar and AI agent governance and where each approach fits.
TL;DR
The Policy as Code (PaC) ecosystem is split between general frameworks like Open Policy Agent and specialized frameworks like Kyverno for Kubernetes and Dogwood for agents The benefits of PaC outweigh the pain of writing the code, and vendors are increasingly simplifying the code-writing experience.
The transition from manual compliance checklists to automated, machine-readable governance has cemented Policy as Code (PaC) as a foundational pillar of modern software engineering. By decoupling policy logic from business logic, PaC treats security rules and operational guardrails as version-controlled, testable artifacts. It’s how we close the "Authorization Gap" and actually achieve Secure by Design.
The blocker? Engineering leaders love the concept of Policy as Code right up until their platform teams actually have to sit down and write it.
But beneath the surface of this massive industry shift, the ecosystem is undergoing a structural bifurcation. The market has consolidated around a few dominant frameworks, which account for over 80% of open-source PaC adoption. The way we author, evaluate, and enforce these policies is evolving rapidly to meet specific operational needs.
Here is a look at the current state of play for PaC, where it's heading, and how to survive the transition.
The OPA hegemony and the "Rego Tax"
The Open Policy Agent (OPA) is the undisputed heavyweight champion of general-purpose PaC. Its architectural supremacy stems from its domain-agnostic nature. Because OPA evaluates declarative rules against arbitrary JSON or YAML, you can use the exact same engine to block a public S3 bucket in Terraform, prevent a :latest tag in a Dockerfile, or enforce mutually authenticated TLS in an Envoy proxy.
But then your engineering team actually has to write the code, understand payload schemas and maintain the code as schemas evolve.
OPA relies on Rego, a declarative query language deeply inspired by Datalog and Prolog. For software and platform engineers accustomed to imperative languages like Python or Go, Rego requires a massive paradigm shift. You aren't just writing linear execution flows; you're dealing with unification, implicit AND/OR joins, and a complete lack of strict schema validation at authoring time. Meanwhile the very schemas of JSON payloads may change, rendering your Rego backwards incompatible.
The reality is that this complexity creates a severe operational bottleneck. Platform teams consistently report that the "Rego Tax" stalls security initiatives, leading to an over-reliance on a tiny subset of specialized engineers (because who doesn't love debugging why a variable failed to unify at 2 AM?).
The Kubernetes native shift: Kyverno and CEL
The friction of Rego has actively driven market fragmentation, most visibly in the Kubernetes ecosystem. Kyverno established a massive stronghold by rejecting bespoke declarative languages entirely. By allowing cluster admission control policies to be written in native Kubernetes YAML, Kyverno eliminated the learning curve for teams already fluent in Kubernetes manifests.
But the ground is shifting again. The upstream integration of the Common Expression Language (CEL) into Kubernetes 1.30 natively handles stateless, context-free validations directly within the API server at microsecond speeds. This fundamentally commoditizes basic validation. External engines like Kyverno and OPA Gatekeeper are rapidly adapting by adopting CEL for the basics, while moving up the value chain toward complex orchestration tasks like resource generation and image signature verification.
The rise of mathematical certainty: Cedar and Dogwood
While general-purpose engines dominate infrastructure, application-level authorization has entirely different requirements. When a microservice needs to know in real time whether a user can execute an action, OPA's dynamic JSON traversal introduces extensibility risks and latency that high-throughput systems simply cannot tolerate.
Enter AWS Cedar. Cedar completely rejects OPA's dynamic approach in favor of strict, upfront schema enforcement. By compiling against known typed entities, Cedar catches attribute-access errors during policy creation. It's also fast. Benchmark data show that compiled schema-driven engines operate considerably faster than Rego for comparable checks.
More importantly, Cedar brings formal verification to the table. Using SMT solvers and mechanized theorem provers (like Dafny and Lean), you aren't just writing unit tests hoping you caught every edge case; you can mathematically prove that privilege escalation is impossible.
But as we step into the era of autonomous AI agents executing non-deterministic tool calls, stateless point-in-time authorization is no longer enough.
This is why Dogwood (a temporal extension to Cedar) was built. Using Metric First-Order Temporal Logic (MFOTL), Dogwood allows policies to reason about sequences and historical trajectories—ensuring a hallucinating AI agent can't circumvent a $5,000 transfer limit by rapidly issuing three concurrent $2,000 requests.
But should you rewrite everything in Cedar?
No. While Cedar is brilliant for application authorization, it is highly ecosystem-limited compared to OPA. It’s an AWS-specific capability today, and it lacks the broad CNCF footprint and cross-stack versatility (Terraform, CI/CD, Kubernetes) that makes OPA the standard for infrastructure and pipeline governance.
We find Cedar very interesting, but it’s not ready to displace OPA for most of the work that needs to be governed. The good news is that OPA is extensible enough to do the things that other languages are tailored for.
Getting the Best of Both Worlds Without the Friction
The future of PaC dictates a multi-engine architecture. You will likely rely on native CEL for Kubernetes, formally verified engines like Cedar for application authorization, and OPA for broader infrastructure and CI/CD pipelines.
But that still leaves you paying the Rego Tax across your primary delivery pipelines. People love the benefits of "as-code," but they hate the actual "writing the code" part.
This is exactly the friction we are solving at Harness. We build on OPA and Rego because they are the industry standards for scalable governance, but we've removed the cognitive load of using them.
Simplifying OPA
Instead of forcing your team to master Rego syntax, Harness lets developers author policies with a natural-language prompt to Rego experience. You describe the guardrail you want, and Harness generates the Rego.
We pair this with a robust policy testing terminal so you can validate that your rules actually execute properly before enforcing them across your environments. To keep you moving fast, we also provide a massive library of out-of-the-box examples aligned with Autonomous Delivery use cases, including policy packs based on common control frameworks (you can dive into the specifics in our Harness Rego Policy Packs announcement).
Furthermore, we ensure that any AI-generated pipelines automatically comply with these OPA policies. Policy applies to people and agents. Rules are rules.
Bottom line: governance shouldn't be a roadblock to innovation velocity. Automating it with PaC can unblock teams and help teams keep up with the deluge of change AI enables. By layering context-aware AI on top of standard PaC engines, you can establish the secure-by-design guardrails your business demands without burning out your best engineers on bespoke syntax.
