Skip to main content
Version: 1.8.0

What is DVARA?

DVARA is an AI governance platform built for runtime enforcement. For traffic routed through DVARA, it can apply configured controls to model calls, tool calls, and agent-to-agent interactions before dispatch, then record the decision and outcome.

This gives platform and security teams a consistent control point for AI activity, without asking every application team to rebuild the same policy, data-protection, approval, and audit capabilities.

The Open Source distribution gives one application team a file-configured governance point for model traffic. The Enterprise platform adds DVARA Flightdeck so platform and security teams can manage governance across workspaces and a gateway fleet.

How DVARA handles a request​

  1. Your application sends a request to DVARA. Common OpenAI-compatible clients usually need a new base URL and a DVARA API key.
  2. DVARA checks the request. Depending on your configuration, it can authenticate the caller, evaluate policy, inspect sensitive data, run guardrails, and enforce rate or budget limits.
  3. An allowed request goes upstream. DVARA selects a configured provider and applies retry, timeout, circuit-breaker, and fallback behavior where configured.
  4. DVARA checks and records the result. Configured response controls run as the call completes. When audit recording is enabled, the record captures the decision and outcome.
API key required

Every /v1/* request requires a DVARA API key. The key identifies the workspace whose policies, data-protection controls, limits, and audit attribution apply to the request.

What DVARA governs​

The traffic type determines which controls and distribution are available:

TrafficControlsOpen SourceEnterprise
Model calls
Includes model-native tool arguments		Policy, configured PII and guardrails, rate limits, routing, and auditIncludedIncluded
MCP tool callsTool policy, PII, approvals, loop detection, session controls, and auditNot includedLicensed plane
A2A messages and tasksMessage and task policy, configured PII, and audit; approvals and loop controls where supportedNot includedLicensed plane

Model calls​

The LLM plane exposes common OpenAI-compatible APIs for chat, responses, embeddings, files, and batches. It routes requests to 14 registered provider integrations, including OpenAI, Anthropic, Bedrock, Azure OpenAI, Gemini, Mistral, Groq, and Ollama.

The Responses API covers common text, image-input, structured-output, and streaming use cases. It does not implement every OpenAI Responses feature. See Providers and the API reference for the exact surface.

Tool calls​

The MCP plane governs calls from agents to tools. It can apply tool allowlists, policy checks, PII scanning, prompt-injection checks, loop controls, human approval, and audit recording.

MCP is part of the Enterprise platform and is not included in the Open Source distribution. From 1.8.2 it runs with or without a licence. Its native endpoint supports the core initialize, ping, tools/list, and tools/call operations. See Native MCP for protocol and transport details.

Agent-to-agent calls​

The A2A plane governs messages and tasks sent between agents. It includes task lifecycle operations, streaming, agent-card verification, policy checks, PII controls, approvals, and audit records.

See Native A2A for the supported operations.

Core capabilities​

  • Policy controls — evaluate YAML rules for model, maximum output tokens, and offered-tool conditions. The Enterprise platform adds time, budget, data-residency, and MCP conditions, plus CEL expressions, version history, dry-run, and Shadow evaluation.
  • Sensitive-data protection — detect configured PII in requests and, when response scanning is enabled, responses. A workspace can LOG, BLOCK, or irreversibly REDACT detections; the default action is LOG. Enterprise TOKENIZE creates recoverable provider-bound request tokens and requires its documented token-store and key setup.
  • Guardrails — include deterministic request and response checks for prompt injection and unsafe content. Enterprise classifiers, external plugins, and grounding checks run only when their required service or model is configured. JSON Schema response enforcement is documented separately under structured outputs.
  • Tamper-evident records — Open Source can write an optional local HMAC-signed, hash-chained audit file. Enterprise adds persistent search, verification, export, and reporting. Symmetric HMAC signing reveals changes; it is not independent third-party proof.
  • Cost controls — the Enterprise platform attributes calculated usage costs by workspace, API key, model, and provider after model pricing is configured. Budgets can alert or reject requests; model downgrade requires separate downgrade rules.
  • Central management — the Enterprise platform uses DVARA Flightdeck to manage workspaces, access, policies, credentials, approvals, costs, and audit records across a gateway fleet.

Choose a deployment​

Start with DVARA Open Source​

Choose Open Source when you want to govern model traffic without running a database or control plane. One gateway.yaml file defines your workspaces, API keys, routes, and policies. The Gateway applies LLM policy, configured PII and guardrail checks, per-instance rate limits, and optional local tamper-evident audit recording. It reads the file at startup, so a configuration change requires a restart.

Operate centrally with the Enterprise platform​

Choose the Enterprise platform when you need to manage multiple teams or a Gateway fleet from one place. The minimum deployment is the DVARA Gateway, Flightdeck, and PostgreSQL. Flightdeck manages workspaces and configuration; each Gateway enforces those controls on the request path.

From 1.8.2 only Flightdeck connects to PostgreSQL. Each Gateway enrols with Flightdeck, serves a signed configuration bundle from it, and writes evidence to a local spool that it ships to Flightdeck. See How the gateway runs without a database. With a durable snapshot of the last verified bundle, a Gateway can continue serving during a temporary Flightdeck outage. A new Gateway with no snapshot can start then only if another Gateway or a shared cache holds a copy of the bundle.

Who DVARA is for​

DVARA is useful when AI activity has operational or compliance consequences:

  • Security and compliance teams that need defined controls and reviewable records for AI traffic.
  • Platform teams that need consistent access, policy, cost, and data-protection controls across application teams.
  • Product teams building agents that can call tools, change data, contact customers, or interact with other agents.

DVARA supplies runtime controls and evidence. It does not make a system compliant by itself. Compliance also depends on the system's scope, configuration, operating procedures, evidence handling, and independent assessment.

Choose your next step​

Use these references after your first governed request: