Dry run: does the rule decide correctly?
In Flightdeck, try a sample model and workspace against the policy. Check a request that should be denied and one that should proceed. No provider call is made.
Policy-as-CodeMake the rule clear.
Make the rule clear.
Test what it will do.
DVARA’s AI governance platform checks configured policies at the gateway. Write the rule once, test its decision, and keep model-access controls out of scattered application code.
One rule. Follow the decision.
Illustration only—not a live policy test. Shadow and the managed lifecycle are Enterprise features. Assume this is the only policy and no other control rejects the request.
The rule
version: "1"
rules:
- id: deny-legacy-models
priority: 10
conditions:
model:
denylist: [mock/legacy-gpt-35]
action: DENY
deny_message: "Legacy models are not approved."
The denylist matches the retired model exactly. DENY supplies the refusal. The policy’s status is set outside this YAML.
- Requestmock/legacy-gpt-35
- DVARA policy · ActiveDenied
- Stopped before the providerLegacy models are not approved.
Use each test for a different question
Shadow: what would it change?
Shadow policies evaluate alongside Active policies on real requests, without changing the live policy decision. Review recorded differences before promoting.
Active: does the gateway enforce it?
After the gateway receives the updated configuration, send real allowed and denied requests. Verify the response and available audit evidence; saving a policy does not prove propagation.
Draft, Shadow, Active, and Archived are statuses, not a mandatory sequence. Shadow and the Flightdeck lifecycle are Enterprise features.
Follow the Flightdeck workflow →Choose how you manage the rules
Open Source
Load Active policies from file configuration. Core conditions cover models, maximum tokens, and requested tools. There is no Flightdeck or central policy lifecycle.
Use file-based policies →Enterprise
Manage policies in Flightdeck with drafts, dry runs, Shadow evaluation, history, and rollback. Additional conditions cover residency, time windows, budget utilization, and MCP-specific checks.
Explore Flightdeck →See capability availability for the distribution boundary and Pricing for production and activation terms.
Keep the enforcement boundary explicit
A model policy governs traffic through the LLM Gateway. MCP conditions apply to tool calls through the MCP Gateway. Agent-to-agent handoffs use a separate A2A policy model.
Calls that bypass DVARA bypass its checks. Use network and credential controls when every call must pass through the gateway.
Understand A2A governance →FAQ
Before you activate a policy
Does a request need an allow rule?
No. This policy engine allows a request when no DENY rule matches. A model allowlist condition matches models outside that list, so pair it with DENY when only listed models should proceed. Other gateway controls can still reject the request.
Does the Flightdeck dry run call a model?
No. It evaluates the supplied policy against a sample request and shows a decision, reason, and elapsed time. It is not a replay of real traffic or a test of every gateway control. Test real requests separately.
Can a workspace override a platform denial?
No. Platform-wide and workspace policies both apply to the workspace. Applicable rules run in priority order; lower numbers run first. The first matching DENY stops policy evaluation. Warning rules do not override a denial.
Do conflicts prevent activation?
No. Flightdeck conflict checks provide warnings, not an activation gate. Read them before relying on the policy. Rules using CEL expressions need manual review rather than assuming the static conflict check proves them safe.
Does this rule also govern agent handoffs?
No. A2A uses a separate policy model for source agents, target agents, and skills. Its first matching ALLOW or DENY rule decides. Use the A2A guide for those rules rather than copying this model policy.
Start with one rule you can explain.
Choose a model restriction. Test both outcomes. Then decide where it should apply.