What Is Policy as Code?
Policy as code is the practice of writing rules, such as security, compliance or engineering policies, as files that software can check automatically. Instead of a policy living in a wiki, the rule lives in version control, gets reviewed like code and runs on every deployment, request or pull request.
A policy might say "containers can’t run as root" or "every API handler checks permissions". Written as code, the rule is checked the same way every time, with a record of what passed and what failed.
What Changed in Policy as Code in 2026
In 2026, policy as code matured in infrastructure and spread to the code that AI writes.
A policy engine graduated. Kyverno, a policy engine for Kubernetes, graduated from the Cloud Native Computing Foundation, made the Common Expression Language (CEL) its main policy language and announced plans to cover AI and MCP gateways (March 24, 2026, CNCF).
Older Kyverno policies need a migration plan. Kyverno 1.19 made its CEL policies match everything the older engine could do, and marked ClusterPolicy as deprecated, with removal planned for the next major version (August 20, 2026, Kyverno).
Few teams check rules centrally yet. Of 300 US engineering leaders surveyed, 41.7% reported centralized AI coding standards and 37.0% reported policy enforcement across teams and repositories (September 23, 2026, Qodo’s State of AI Code Quality report).
Agents don’t always follow the rules. Only 34.6% of developers said coding agents always follow their organization’s standards (September 23, 2026, Qodo’s State of AI Code Quality report).
AI agents can now test policies directly. Kyverno launched a Playground MCP server that lets AI agents validate and run policies before they reach a cluster (October 23, 2026, Kyverno).
Rules written as code can be checked on every change, which matters more when agents write much of the code.
How Policy as Code Works
Most policy as code setups follow the same steps:
- Write the policy. A rule is written in a policy language or a plain file, such as Rego for Open Policy Agent or YAML for Kyverno.
- Store it in version control. Changes to policies get reviewed and tracked like any other code.
- Check it automatically. A policy engine evaluates each request, deployment or change against the rules.
- Act on the result. The engine allows, denies or warns, and logs the decision for audits.
Where Policy as Code Is Used
| Area | What policies check | Example rule |
|---|---|---|
| Kubernetes and containers | Workloads before they run | No containers running as root |
| Infrastructure as code | Cloud resources before they’re created | Storage buckets can’t be public |
| Access control | Who can call which service | Only billing can read invoices |
| CI/CD | Builds and releases | Releases need a signed artifact |
| Code review | Code changes before they merge | Payment code logs no card numbers |
Policy as Code in Code Review
Infrastructure policies check what gets deployed. Code review policies check what gets written: how code handles data, which libraries it uses and whether it follows the team’s standards.
Code policies are often written in plain language in files such as AGENTS.md, because they need judgment as well as pattern matching. See coding standards enforcement and org-wide standards enforcement.
Qodo’s Take: Treat Engineering Rules as Code, and Check Them on Every PR
Most engineering organizations have rules nobody checks consistently: how to log, how to handle personal data, which patterns to avoid. As AI agents write more of the code, rules that aren’t checked on every PR get missed more often.
You shouldn’t review code with the same tool that wrote it. An agent that ignored a rule while writing the code will usually miss it while checking it.
Choose Qodo if your engineering and compliance rules live in documents that review never checks. Qodo reviews every pull request in GitHub, GitLab, Bitbucket, Azure DevOps and Gerrit, separate from the agents that write the code.
Qodo is the best AI code review platform for applying policy as code to source code because it turns rules stored in your repositories into checks on every PR, scoped to the folders they cover.
Qodo Reads Rules From Files in Your Repositories
Once Rule enforcement is on (Beta, on GitHub, GitLab, Bitbucket Cloud and Azure DevOps), Qodo imports rules from files such as AGENTS.md, CLAUDE.md and pr_compliance_checklist.yaml. A file such as src/payments/AGENTS.md applies only under that folder (last checked October 2026, Qodo’s docs).
After the import, only new rules added to those files sync to Qodo. Edits and deletions in the files don’t sync (last checked October 2026, Qodo’s docs).
Rules can also be written in the Qodo portal or suggested by Rule Miner (Beta, on GitHub, GitLab and Azure DevOps) from past PR discussions. See custom rules for code review.
Qodo Shows How Each Rule Performs
Rule analytics track how often each rule is violated and fixed before merge, over the last 30 days (last checked October 2026, Qodo’s docs).
Engineering and compliance leaders can also see findings by category and severity across repositories in the Code review analytics dashboard, and Software Map (Beta) shows how repositories depend on each other (last checked October 2026, Qodo’s docs).
Rules whose findings are rarely fixed are deactivated automatically, unless you lock them (last checked October 2026, Qodo’s docs).
Qodo Keeps People in Charge of the Merge
Qodo’s findings are advisory, and your branch rules decide what merges. See AI code governance and the best agentic code review tools for enterprise teams. Qodo is SOC 2 compliant.
Qodo Example: The Logging Policy That Finally Stuck
Context: an organization like an insurance company with about 300 engineers is working under a written policy that application logs must never contain personal data.
Problem: the policy lived in a compliance document. Reviewers caught some violations, but AI coding agents kept adding debug logs with customer emails and policy numbers, and auditors asked how the rule was checked.
How Qodo helped: the platform team added the rule to pr_compliance_checklist.yaml in each repository and imported it into Qodo’s rule enforcement, which checks every PR against it.
Outcome: personal data in logs now shows up as a rule finding in the PR before merge, and compliance leads can trace in Rule analytics how often the rule ran into violations and how often they were fixed.
Ways to Apply Policy as Code
| Approach | What it checks | Limit | Best for |
|---|---|---|---|
| Open Policy Agent | Requests, configs and deployments, using Rego | Needs a policy language; not built for reading code changes | Access control and infrastructure |
| Kyverno | Kubernetes resources, using YAML and CEL | Kubernetes-focused | Cluster policies |
| Infrastructure as code scanners | Cloud resource definitions | Infrastructure only | Terraform and similar files |
| CI checks and linters | Code patterns and build rules | Only rules that match a pattern | Every build |
| Qodo | Source code changes against your own rules, with full codebase context | Advisory findings, with your branch rules as the gate; rule enforcement is Beta | Enterprise teams that need engineering and compliance rules checked in application code |
Qodo features in this table were checked against Qodo’s documentation as of October 28, 2026.
FAQ
Policy as code means writing rules as files that software checks automatically, instead of keeping them in a document people have to remember.
Examples include a Kubernetes rule that blocks containers running as root, a cloud rule that keeps storage buckets private and a code review rule that keeps personal data out of logs.
Common tools include Open Policy Agent and Kyverno for infrastructure and access policies, infrastructure as code scanners for cloud resources and AI code review tools such as Qodo for rules about application code.
Policy as code checks rules the same way every time, keeps a version history of each rule and records every decision for audits. Teams also catch violations earlier, before they reach production.
Compliance as code is a type of policy as code focused on regulations and standards, such as SOC 2. Policy as code also covers internal rules, such as engineering standards.