Skip to main content
Version: 1.7.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 one place to control AI activity without asking every application team to build the same policy, data-protection, approval, and audit features.

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.

Production deployments should require a DVARA API key. The development default allows keyless requests, which are anonymous and do not receive normal workspace attribution.

What DVARA 1.7 governs​

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.

Its native endpoint supports the core initialize, ping, tools/list, and tools/call operations. See Native MCP for supported protocol operations and transports.

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 and current protocol scope.

Core capabilities​

  • Policy controls — define YAML rules that deny or warn on configured model, tool, time, budget, and data-residency conditions. CEL expressions are available when a rule needs more flexible logic. Policies support versioning, 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 REDACT detections; the default action is LOG. Optional detectors and tokenization require their documented services or key-management setup.
  • Guardrails — inspect input and output for prompt injection, prohibited content, sensitive-data exposure, and grounding problems. Individual detectors and external classifier integrations are configuration-dependent.
  • Tamper-evident records — store HMAC-signed, hash-chained audit records designed to reveal later modification. These records support security and compliance review, but symmetric HMAC signing is not independent third-party proof.
  • Cost controls — attribute 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 — use DVARA Flightdeck to manage workspaces, access, policies, credentials, approvals, costs, and audit records.

Deployment and licensing in 1.7​

DVARA 1.7 runs as two applications backed by PostgreSQL:

  • DVARA Gateway serves the LLM (/v1), MCP (/mcp), and A2A (/a2a) planes from one process.
  • DVARA Flightdeck provides the platform Console, workspace Portal, and control-plane services.
  • PostgreSQL stores centralized configuration, workspaces, usage, and audit data.

Gateways can connect directly to PostgreSQL or consume signed configuration bundles. With signed bundles and a local event spool, a gateway can continue serving during a temporary Flightdeck outage.

An installation without a licence runs in the Development posture. The LLM plane and its governance features remain available for evaluation, development, and testing. A commercial licence provides production rights and support and activates the MCP and A2A planes. See Licensing for activation, grace-period, and expiry behavior.

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.

Run DVARA​

Start with the Quickstart to run DVARA 1.7 locally and make a governed request.

After that, use these references as needed:

Last updated on