What is policy as code for production?

Policy as code means expressing operational, security, and compliance rules as version-controlled, machine-executable code rather than documents, checklists, or manual review processes. In production, it means a policy engine evaluates every action, human or agent, against a defined rule set before it executes, not after. The result is governance that is consistent, auditable, and enforceable at the speed of automation.

From linting to enforcement

Most policy-as-code tools in common use today, including OPA with Conftest and Checkov, evaluate configuration files before a deploy reaches production. That gate catches misconfigurations in Kubernetes manifests, Terraform plans, and Dockerfile instructions before they cause problems.

What it does not catch is a live action that was never expressed in a config file. A human operator running an ad-hoc kubectl delete in a production namespace, or an AI agent deciding to restart a degraded service, produces no config file for a pre-deploy linter to evaluate. The action exists only at execution time. Runtime enforcement means the policy engine sits in the execution path, not just the delivery path, so it can refuse or scope the action before it runs.

The distinction matters most as AI agents take on more operational work. An agent that can restart services, roll back deployments, or modify firewall rules is not submitting a pull request. Its decisions land directly in production. Pre-deploy linting has no surface area on those decisions.

Core concepts

Declarative policies. You define what is allowed, not the procedural steps to check whether it is allowed. A policy written in Rego states that a restart action requires the requesting identity to hold a specific role and the target service to have fewer than three restarts in the past hour. The engine evaluates that against the current state; the calling system does not need to encode the logic itself.

GitOps fit. Because policies are code, they live in source control alongside the systems they govern. Every change goes through a pull request, gets reviewed, and is recorded in commit history. When an auditor asks what the restart policy was on a given date, the answer is a git log entry, not a Confluence page someone may or may not have updated.

OPA and Rego. Open Policy Agent is the most widely deployed general-purpose policy engine. Rego, its declarative query language, evaluates structured input, typically JSON representing a request and its context, against a policy document and returns a decision. OPA integrates with Kubernetes admission controllers, API gateways, CI pipelines, and custom application authorization layers.

Policy bundles. OPA can load policy bundles from a remote source, which means a central policy repository can push updates to every enforcement point without redeploying application code. This matters in large environments where enforcement points span clusters, cloud accounts, and services.

Runtime enforcement for AI agents

When an AI agent decides to restart a service or roll back a deploy, the action passes through a policy gate before it executes. The gate checks four things: identity (which agent or user is requesting the action), scope (which services or resources are in bounds), blast radius (how many systems would be affected), and reversibility (can the action be undone without manual intervention).

A gate that passes all four criteria allows the action. One that fails on blast radius might scope the action down to a single instance rather than blocking it entirely. One that fails on identity returns a denial with a reason code the agent can surface in its explanation.

This is the operational difference between governance and logging. Logging tells you what an agent did. A policy gate decides what an agent can do. In a post-incident review, the difference is between explaining a failure and preventing one.

See the Runtime Policy Patterns for the twelve enforcement primitives that cover identity binding, blast radius limits, time-boxed access, and reversibility gates. NOFire uses these primitives as the foundation for its agent action authorization layer.

What to enforce at runtime versus build time

Build-time enforcement is the right place for configuration correctness and IAM drift. If a Terraform module opens a security group to 0.0.0.0/0, Checkov catches it before terraform apply runs. If a Kubernetes deployment is missing resource limits, a Conftest policy blocks the deploy. These checks are fast, cheap, and well-supported by existing tooling.

Runtime enforcement is the right place for anything that does not flow through a CI pipeline. That includes:

• Ad-hoc remediation commands run by on-call engineers under pressure
• AI agent actions generated in response to live incidents
• API calls made by automated runbooks that predate your policy infrastructure
• Privilege escalations that happen in a live session, not a config file

The practical answer for most teams is both layers. Build-time checks reduce the surface area that reaches production. Runtime enforcement covers the residual, which in practice is where the highest-consequence actions live.

A common maturity path: start with OPA in dry-run mode at the runtime layer to observe what actions would have been blocked, tune policies until the false-positive rate is acceptable, then switch to enforce mode. Treat the dry-run period as a calibration exercise, not a permanent state.

See the Runtime Policy Patterns to go deeper on the specific primitives and how to sequence them for an AI-assisted SRE workflow.