Govern AI like you govern infrastructure — as code.
DVARA's policy engine lets you express who can call which models and tools, under which conditions, in a simple declarative language. Dry-run a policy against real requests, shadow-test it in production with zero risk, then promote it — versioned, diffable, and instantly reversible.
Policy-as-Code ships in every DVARA install — see pricing.
Governance buried in app code can't be reviewed, tested, or rolled back.
When AI rules live in scattered application code, no one can answer “what's allowed?” without reading ten repos. Changing a rule means a deploy; testing one means hoping; and there's no record of who changed what, when, or what it would have done. DVARA moves the rules into one version-controlled engine the gateway enforces on every call.
Test in production. Promote with confidence. Roll back instantly.
Validate syntax and simulate a policy against a real request — see the decision and timing — before it ever touches live traffic.
Run a candidate policy in production in parallel, measure exactly what it would have done with divergence stats, and promote only when you’re confident. Zero risk.
On activation, surface rules that overlap or contradict before they reach production.
Every change snapshots a version (last 10 retained); roll back to any prior version in one click.
A real lifecycle for governance changes, with every status transition versioned.
Match on model, max tokens, requested tools, MCP server/tool, data residency / region, time of day, and budget utilization.
Platform-wide policies apply to everyone; per-tenant policies apply to one tenant. Both are evaluated on every call.
Policy changes propagate across the fleet without a restart — the decision is recorded on every call for audit.
Author, test, promote, govern
- 1
Author
Write the policy in the declarative YAML DSL — readable by security, enforced by the gateway. It starts as a Draft.
- 2
Test
Dry-run it against a real request, then shadow-test it in production in parallel with full divergence tracking.
- 3
Promote
Activate the policy — conflict detection runs — and the change is versioned and hot-reloaded across the fleet.
- 4
Govern & roll back
Every LLM and MCP call is evaluated and the decision recorded; revert to any prior version instantly if needed.
Author and shadow-test policy in DVARA Flightdeck
Common questions about Policy-as-Code for LLMs
Governance rules — which models and tools a caller may use, under which conditions — expressed in a declarative, version-controlled language and enforced centrally at the gateway on every LLM and MCP call, instead of scattered through application code.
Yes. Dry-run validates and simulates a policy against a real request; shadow mode runs a candidate in production in parallel and reports exactly what it would have done — with zero impact — before you promote it.
Model, max tokens, requested tools, MCP server and tool, data residency / region, time of day, and budget utilization, among others.
Yes. Each change snapshots a version (last 10 retained) and you can roll back to any prior version instantly. Conflict detection runs on activation.
Yes. Platform-wide policies apply to all tenants and per-tenant policies apply to that tenant; both are evaluated, and the decision is recorded on every call.
Guides on Policy-as-Code for LLMs
A practical definition, its lineage from Terraform and OPA to Kubernetes CEL, and why AI teams need it now — the concept, start here.
What it means, why governance in app code can’t be reviewed or rolled back, and the YAML + CEL rule model — with the dry-run → shadow → promote lifecycle.
The content half of governance — injection, PII, content, and output checks that scan every request and response, versioned and tuned per tenant instead of hard-coded in prompts.
Make your AI rules real — and reversible.
The policy engine ships in every DVARA install. Start a free 30-day trial, or read how it works.