LLM policy as code is useful when three things travel together: a reviewable rule, one shared enforcement point that sees the AI request before the provider does, and an evidence record that names the rule behind each decision. Drop any one and you lose either consistency or proof.

This post covers the part teams most often get wrong: how enforcement actually behaves.

Conditions describe the violation

A policy condition says when a rule should fire, not what the steady state should be. That distinction catches people out.

In DVARA, a model allowlist condition matches when the requested model is outside the list. The DENY action then blocks that violation. Read every condition as "this is the bad case":

policies:
  - id: approved-models-only
    workspace: default
    status: ACTIVE
    dsl: |
      version: "1"
      rules:
        - id: deny-legacy-model
          priority: 10
          conditions:
            model:
              denylist: [mock/legacy]
          action: DENY
          deny_message: "This model is not approved. Use mock/approved instead."

Four rules prevent most mistakes:

• Conditions inside one rule are ANDed. Put independent reasons to deny in separate rules, so each denial tells the caller exactly what to fix.
• Model names are exact and case-sensitive. They are not prefixes or globs, so list every approved dated model name.
• A max_tokens rule checks an explicit request value. If the request omits max_tokens, the condition does not match, and no default is injected.
• Empty conditions are refused. A policy that looks active but checks nothing is worse than no policy.

The caller needs a contract, not a stack trace

When the rule fires, the Gateway stops the request before provider dispatch and returns the message the rule's author wrote:

{
  "error": {
    "message": "This model is not approved. Use mock/approved instead.",
    "type": "policy_violation",
    "code": "policy_denied",
    "trace_id": "01K4V5R9X21MDN8W5A6E7ZQ3TC"
  }
}

That is HTTP 403 with a stable code, a trace ID, and a fix. Write denial messages for the caller, not the policy author. "Use mock/approved instead" is useful; "rule 10 failed" is not.

Deny and warn are different controls

DENY stops the matching request. Use it when a violation must never reach the model provider.

WARN_AGENT lets the call continue and attaches a governance warning to the result and the audit trail. It suits a migration period, such as moving callers off a preview model.

A warning is not a softer spelling of enforcement. If nothing consumes the warning, the control is only observational. Decide who reads it, and what they do, before relying on it.

Evidence is what makes it auditable

With the local audit file configured, the denied call is recorded as POLICY_DENIED, with the policy ID, rule ID, workspace, reason, and chain-integrity fields. The open-source audit file is tamper-evident through HMAC signing and hash chaining. Someone with filesystem access can still delete it, but changes become detectable rather than silent.

Two limits are worth stating plainly:

• A central rule governs only traffic that passes through the Gateway. Restrict direct provider credentials and network paths, or the bypass becomes the real policy.
• LLM policy is not application authorization. A tool rule can stop an application from offering cancel_order to a model. Whether the signed-in human may cancel a given order is still the order service's decision.

Start with one rule and one observable result

Deny one model. Send one allowed and one denied request. Confirm the error contract and the audit record. Expand only once the team can explain the behaviour and the rollback path.

The full guide covers the rest: what policy should and should not govern, the open-source and Enterprise boundary, and a rollout sequence that avoids outages. Read LLM Policy as Code: Rules, Enforcement, and Rollout.