LLM Policy as Code: Version-Controlled Governance for Model and Agent Access

DVARA — Tue, 07 Jul 2026 09:32:44 +0000

Ask a team "which models is your application allowed to call, and under what conditions?" and the honest answer is usually "let me check the code." The rules — which models are approved, which tools an agent may invoke, what happens when a request is too large or comes from the wrong region — are scattered across if statements in a dozen services. No one can review them in one place, no one can test a change safely, and no one can say what a rule would have done before it ships.

LLM policy as code fixes that the same way infrastructure as code fixed server configuration: move the rules out of application code and into a declarative, version-controlled language that a single control point enforces on every call.

What is LLM policy as code?

LLM policy as code is the practice of expressing your governance rules — who can call which models and tools, under which conditions — in a declarative, version-controlled format, and enforcing them centrally at a gateway on every LLM and agent (MCP) request, instead of hard-coding them in each application.

It's the same idea behind Terraform for infrastructure, Open Policy Agent for authorization, and Kubernetes admission control for clusters: the policy is a reviewable artifact, not tribal knowledge. The difference is the domain — an LLM policy matches on AI-native attributes (model, token budget, requested tools, data-residency region) that a general-purpose API gateway or IAM system can't see.

Why governance in application code fails

Rules embedded in app code have four problems, and they compound:

You can't review them. "What's allowed?" has no single answer — you'd have to read every repo that calls a model.
You can't test them. Changing a rule means a deploy and hoping nothing breaks.
You can't roll them back. A bad rule is another deploy to undo, under pressure, with no record of the previous state.
You can't audit them. There's no trail of who changed which rule, when, or what decision it produced.

Policy as code turns all four from "read the source" into "read the policy" — a diffable, testable, reversible, auditable object.

What an LLM policy looks like

A policy is a small YAML document: a set of rules, each with an id, a priority (lower number wins), a conditions block that matches request attributes, and exactly one action. Here's a model allowlist:

version: "1"
rules:
  - id: only-approved-models
    priority: 10
    conditions:
      model:
        allowlist: [gpt-4o, gpt-4o-mini, claude-sonnet-4-5]
    action: DENY
    deny_message: "Model not on the approved list"

Rules evaluate in priority order. The first matching DENY returns immediately; a softer WARN_AGENT action collects a warning and lets the call continue.

The conditions you can match on are the ones that matter for AI traffic: model (allow/denylist), max_tokens, tools and MCP server/tool/args, data_residency, time_of_day, and budget utilization.

When the simple form isn't enough

For rules that need OR, NOT, or arithmetic across fields, a rule can carry a CEL (Common Expression Language) expression: instead of conditions::

version: "1"
rules:
  - id: gpt4o-outside-eu-or-large-requests
    expression: |
      request.model == "gpt-4o" &&
      (context.region != "EU" || request.message_count >= 50)
    action: DENY
    deny_message: "gpt-4o restricted outside EU or for >= 50 messages"

CEL is the same sandboxed expression language Kubernetes admission policies, Envoy, and Cilium use — deterministic and type-checked at submit time. One expression replaces three rules.

The lifecycle is what makes it safe to change

Writing rules as code is only half the value; the other half is changing them without fear:

Author — the policy starts as a Draft, affecting nothing.
Dry-run — simulate it against a real request and see the exact decision before it touches live traffic.
Shadow — run the candidate in production in parallel, recording what it would have done with divergence stats, while changing nothing.
Promote — activate it; conflict detection surfaces contradictory rules, and it hot-reloads across the fleet.
Version & roll back — every change snapshots a version; revert instantly.

Shadow mode is the part teams underrate — the difference between "we think this rule is safe" and "we watched it run against a week of real traffic."

Global and tenant scope, audited on every call

Policies apply platform-wide and per-tenant; both are evaluated on every request, and the decision — allowed, denied, or warned, and by which rule — is recorded on every LLM and MCP call. That record is what turns "we have policies" into "here's proof of what our policies did."

Where it runs

The rules are enforced at the gateway in front of your model and tool calls — one control point every request already passes through, with full visibility into the AI semantics (model, tokens, tools, region, budget). A denied request never leaves your perimeter.

That's the core of DVARA's approach: Policy-as-Code for LLM and agent traffic as a first-class, version-controlled surface — author it in YAML, dry-run and shadow-test it, promote with conflict detection, roll back in one click. Read the full pillar guide → https://dvarahq.com/policy-as-code-llm

DEV Community: DVARA