What is policy as code (PaC)?

Instead of relying on humans to check compliance or remember security rules, those rules exist as executable logic that runs every time a developer or system proposes a change or request. If someone submits a change, a policy engine automatically evaluates the change against the coded rules and either permits, denies or flags it.

This process moves policy management practices away from static documents toward a live, continuously enforced control surface embedded in the software delivery pipeline.

Code-based rules help ensure that the same policies are applied everywhere, in a repeatable and scalable way. Policy engines can run automated checks in seconds during builds or deployments, shrinking feedback cycles and helping DevOps teams avoid late-stage security or compliance surprises.

PaC enables enterprises to improve their overall cybersecurity posture and maintain compliance with industry and regulatory standards. Furthermore, treating policies like code aligns with a broader “everything as code” transition, which turns things such as infrastructure requests into reviewable code files around which development teams can collaborate.

In DevOps terms, a policy is a clear, enforceable rule about how IT infrastructure and applications must be configured, accessed or run. More precisely, policies dictate what actions are allowed, required or forbidden so that systems keep running in their ideal state. 

For example, “all storage buckets must be encrypted” or “no public service can expose port 22” are policies, because they specify concrete constraints on system behavior.

With PaC, policies are written in a structured programming language, so policy engines and automation tools can parse and evaluate them deterministically. This way, policies become executable guardrails that systems and engineers must satisfy, rather than guidelines that people might interpret differently.

Policy as code tools enable developers to write executable code into runtime environments and continuous integration/continuous delivery (CI/CD) pipelines, so every change is automatically checked for adherence.

Technically, most PaC setups follow the same core steps:

• Developers write policy in the form of code files. They can use a range of high-level imperative and declarative languages, including Python, YAML, JavaScript Object Notation (JSON) or Rego, which is typically used alongside the Open Policy Agent (OPA), an open source policy engine. Each policy file declares the inputs that it cares about (“resource.kind,” “metadata.labels,” for example) and encodes conditions—also called “predicates”—and outcomes (allow/deny, severity, messages).

• The code is submitted to a version control system, such as Git or GitHub, and goes through the same workflows as application code, including pull requests, code review and rigorous syntax testing.

• A policy engine reads the code file, parses it and turns it into internally comprehensible data structures and instructions. These structures and instructions are then converted into a compact, low-level instruction format (bytecode) for fast evaluation.

• A caller—the piece of code that asks the policy engine for a decision—normalizes data inputs. The caller processes different input formats, including HashiCorp Configuration Language (HCL) files and JSON templates from IaC tools, YAML manifests from Kubernetes and cloud platforms, HTTP requests from API calls and app data and telemetry data from runtime and production environments. It cleans and reshapes the raw input into one standard structure, so policies can read the inputs in a consistent way.

• The caller hands the normalized data back to the policy engine, which starts running policy code against the data inputs.  

• The policy engine walks through the rules and checks each rule’s predicates against the input to understand which predicates apply. One can think of the policy engine as asking, “What does this rule say about this input?”

• The policy engine takes the outcomes from all rules and combines them into a single policy decision—a process called decision aggregation—and creates a list of messages. Messages provide more details (which rule was violated and which object violated it) about failed code and sometimes offer suggestions for how to fix it.

• The policy engine returns the decision, including relevant messages, tags and severity information. If the decision is “deny,” the policy engine blocks all pull requests and code merges and stops the deployment until developers remediate the policy violation. If the decision is “allow,” the engine creates a build artifact (a compiled, packaged and tested code file) and deploys the code. If there are warnings, the code is allowed to pass, but the engine includes the warnings in log files or comments. 

Policy checks can occur at any point in the software development lifecycle (SDLC), from code integration to live production and monitoring.

Because policies are code, they can also be treated like any other software artifact.

Development teams can write automated tests that feed sample inputs into policies and verify the decisions they return to accelerate feedback cycles when policies change.

When policies are encoded, developers can factor out common logic into reusable modules or functions. Multiple higher-level policies can then call upon shared policies instead of duplicating conditions everywhere.

Developers can also rename, restructure or split large policies into smaller ones without changing their behavior, just like refactoring a big app function into smaller ones.

These capabilities enable teams to apply existing software engineering practices to governance logic, which helps them maintain security and compliance requirements as IT architectures scale and evolve.

Let’s say Company X wants to implement an “HTTPS-only” policy where every web service must use HTTPS, not plain HTTP. To codify the policy, a platform engineer writes a simple rule that says:

• If a service’s protocol is HTTP, the change should be rejected.
• If a service’s protocol is HTTPS, the change is allowed.

The engineer puts this policy file in a “policies” folder inside the same code repository as the application and opens a pull request to add the policy. That pull request triggers an automatic syntax check of the policy file and a code review by another engineer. Only after the policy passes the necessary tests is it merged into the main branch.

In the continuous integration (CI) pipeline, all policy files are loaded to the policy engine from the “policies” folder. The policy engine reads the policy, converts it into an internal representation and compiles it into a compact, low-level form. This compact form enables the engine to quickly answer “allow or deny?” for every service the pipeline checks.

Regardless of the file’s format, a CI job takes the existing configuration file, extracts the important fields (name, protocol, port) and builds a simple JSON description of each service.

The caller requests a decision from the policy engine by sending the standardized service description as an input and indicating that the policy package for “HTTPS-only” should be applied.

The policy engine then evaluates the input against the rules. It checks the service’s protocol field. If the protocol is HTTP, that means the input matches the “deny” condition in the policy. The engine indicates that the change should be denied and creates a message telling the developer that the service must use HTTPS instead of HTTP. If the service uses HTTPS, none of the deny conditions are met, and the engine indicates that the change is allowed.

Then, the policy engine summarizes rule evaluations into a single decision object for the service. Decision objects typically specify whether the overall decision is “allow” or “deny” and how severe the issue is (high, medium, low). They also include a list of messages explaining why the input was denied and any warnings the engine found in the assessment process. If everything is compliant, the decision object says that the change is allowed and comes with only informational notes (or no messages at all).

Finally, CI tools enforce the decision. If the decision is “deny,” the change fails to merge into the main code branch. The engineer sees an error message saying that the service must use HTTPS and undergo specific modifications. If the decision is “allow,” the artifact is packaged and deployed, and the CI pipeline continues as normally.

Policy as code grew out of a broader “everything as code” movement in modern DevOps and cloud engineering.

Originally, infrastructure as code (IaC) was the big shift. Instead of system administrators clicking through user interfaces or following runbooks, teams described servers, networks and other resources in declarative code files. These files are stored in version control systems and applied through automated pipelines.

As enterprises saw the benefits, the approach spread to other components of IT architectures. Application configuration moved toward code-based approaches. CI/CD pipelines became scripts that live in code repositories. Monitoring and alerting rules started living in code, too. Together these practices became known as “everything as code.”

The central idea of “everything as code” is that, if some part of the system can be described, it should be described as code and managed the same way as software applications.

PaC is essentially the application of that philosophy to rules, governance and compliance. Traditionally, policies lived in PDFs and wikis or were decided by committee, and they were enforced by humans. This process worked when release cycles were slow and infrastructure was relatively static.

As cloud-native and microservices architectures took over, and teams started deploying code several times daily, manual processes could not keep up. PaC addressed this challenge by expressing policies in machine-readable formats, so they can be versioned in Git, reviewed like code files, tested in CI and enforced automatically in pipelines or at runtime.

Policy as code is a practice for managing IT policies like software code. Infrastructure as code (IaC) is similar, but with a different focus. It enables engineering teams to define and manage IT infrastructure by using application code.

Instead of manually creating and configuring network assets such as virtual machines (VMs) and load balancers, IaC enables developers to write code to describe the desired state of these resources. An IaC tool then takes that code and creates or modifies the specified resources.

IaC makes infrastructure scaling and automation much easier. If a team needs more servers, they can just change a number in the code (from six instances to nine, for example). Automation tools handle the details of provisioning those extra resources.

At a high level, IaC dictates what infrastructure should exist and how it should be configured, while PaC focuses on the rules and constraints that infrastructure must obey. IaC code creates and configures resources, and PaC code helps ensure that those resources (and the ways they are used) follow defined security requirements, compliance standards and operational guardrails.

In many modern IT architectures and CI/CD setups, IaC and PaC provide complementary benefits. IaC automates provisioning, and PaC adds automated governance on top.

When a developer changes an IaC file, a PaC engine can inspect the new plan or configuration. If everything complies with the established policies, the change is allowed to proceed and the infrastructure is updated. If something violates a rule, the pipeline fails and nothing gets deployed until the issue is fixed.

DevSecOps is about embedding security and compliance into the DevOps lifecycle, instead of bolting them on at the end. It’s a developmental approach where security processes are prioritized and executed during each stage of the software development lifecycle.

PaC supports DevSecOps practices by:

PaC helps teams shift security left by moving security checks into the earliest stages of the development process, rather than waiting to run checks after deployment—when issues can affect users. If a developer introduces a risky configuration or insecure pattern, automated policies can help detect the issue and fail the build.

PaC tools automate enforcement by embedding security rules directly into CI/CD pipelines and runtime systems, so checks happen automatically every time code or infrastructure changes. Instead of relying on humans to remember every security standard and manually review every change, the system consistently evaluates changes to ensure that no step is accidentally skipped.

PaC helps developers maintain deployment speed without sacrificing consistency and safety. It runs the same policy definitions in every environment and at every stage—development, testing, staging and production. This feature enables teams to release frequently because they can trust that the same set of rules is being applied everywhere. It also helps them avoid situations where different environments drift apart or use slightly different interpretations of the rules.

PaC treats application security policies like any other code artifact that lives in a version control system. Development, operations and security teams can all review, discuss and update policies through familiar workflows (code reviews, branching strategies), which makes policy discussions more transparent and more integrated into everyday development work.

Policy as code has a wide range of applications for enterprise IT architectures.

Developers and security professionals are exploring policy as code as a way to create layered guardrail models that span the entire lifecycle of an AI or agentic workflow. While the practice is still emerging, initial investigations have revealed many possible applications of PaC in AI workflows.

PaC can help establish a clear separation between the AI’s reasoning and the system that decides which actions it is actually allowed to execute. The AI tool can propose actions or plans, but a policy engine evaluates those proposals against codified rules before any underlying system is touched.

At the input stage, PaC can help filter or transform user prompts, redact sensitive data, enforce tenant isolation and block known attack patterns. During planning, PaC can require AI agents to produce structured plans and validate each step against allowed tools, actions and risk conditions before execution is permitted.

At execution time, every tool invocation or API call can be checked by the policy enforcement layer. They layer decides whether to allow, deny or modify an action or escalate it to a human being. After execution, policies can drive logging, audit trails, retention rules and post-filters on model outputs to help ensure that responses comply with the necessary requirements.

• Consistency. With PaC, policies are applied in the same way across all environments because the same code runs everywhere. This consistency reduces one-off, “snowflake” configurations and prevents teams from having to remember slightly different manual processes for each environment.

• Efficiency. When policies are codified, they can be enforced automatically in CI/CD pipelines or at deployment time, eliminating the need for manual checks and approvals.

• Automation. PaC enables automated validation and policy testing, which helps teams minimize the impact of human error, catch misconfigurations and address security vulnerabilities before they hit production.

• Visibility. With policies written in code and stored centrally, stakeholders can see exactly what rules are in place instead of relying on scattered documents and people’s memories.

• Scalability. Policy evaluation is automated, so organizations can enforce policies at scale across many services, clusters or accounts without proportional increases in headcount.

• Collaboration. PaC streamlines collaboration around policy code. These shared workflows break down silos, align security and governance with DevOps practices and make policy discussions more concrete and testable.