Your data stays inside your perimeter. Your keys stay yours. Every action is attributable and verifiable.
DVARA is self-hosted by default. Your prompts, completions, and audit trail stay inside your perimeter.
- Self-hostedRuns in your VPC, your cloud, or on-prem.
- Your perimeterYour prompts, completions, and audit records stay inside your perimeter.
- BYOKBring your own provider keys — encrypted in your install, or held in your own vault.
- Air-gappedGovernance runs the same with no route back to us.
- Signed auditTamper-evident audit, hash-chained, signed, and verifiable by you.
Scope: LLM, MCP, and agent-to-agent traffic.
Put governance in front of your first production agent in minutes.
DVARA is self-hosted by default. Start it with Docker Compose locally or the Helm chart in your cluster — one route, not both — then point your existing SDKs at it.
One command starts the enforcement point for governed LLM, MCP, and agent-to-agent traffic.
Establish the enforcement point.
Quickstart →Run DVARA in your VPC, your cloud, or on-prem with your own provider keys.
Keep data and keys inside your perimeter.
Helm + Kubernetes →Use the OpenAI-compatible gateway URL with the SDKs you already have.
Govern calls without rewriting the application.
SDK drop-in →Free and self-hosted, production included. A licence adds the MCP and A2A planes with support.
See what a governed request looks like.
Every call returns a decision your system can enforce and an evidence trail your security team can inspect.
policy: PASSPolicy decision- The call carries a policy result your application can act on. PASS means this request matched the policy configured for it, evaluated on the request path before it reached the provider.
pii-scan: CLEANData protection- The data-protection result for this request. CLEAN means the PII filters you configured matched nothing in this call — the filters, and what they block, redact or log, are yours to set per workspace.
audit: SIGNEDSigned evidence- The governed event is written to the audit trail signed and hash-chained, so your security team can inspect what was decided, by which policy, on which call, long after it ran.
cost: $0.0032Cost attribution- The call is priced as it completes and stamped with the workspace, key and model behind it, so this request has a name attached to its spend rather than landing anonymously on a provider invoice.
Keep your models. Add a control plane.
One OpenAI-compatible endpoint governs calls across 14 providers, including hosted and self-hosted models.
DVARA fits the stack your platform team already operates.
Runtime
- OpenAI API
- MCP
- OpenTelemetry
- Prometheus
Deployment
- Kubernetes
- Helm
Security and evidence
- OIDC
- SAML
- OWASP LLM Top 10
- SOC 2/HIPAA/GDPR evidence
One control plane for the risks that stop agents from shipping.
Know who acted
Isolated workspaces with their own policies, budgets and credentials — encrypted at rest or referenced from your vault.
Every request HMAC-signed and hash-chained, so tampering is detectable. SOC 2, HIPAA and GDPR evidence on demand.
AI audit & compliance →Control what can happen
A YAML DSL for model allowlists, token limits, MCP tool restrictions and budget rules — with dry-run, versioning and rollback.
Policy-as-Code for LLMs →Govern MCP tool calls at the argument level, pause high-risk calls for human approval, trace multi-agent chains, and stop runaway loops with a kill switch.
A registry of peer agents, policy on every delegation hop, and a signed audit chain for agent-to-agent traffic.
Protect what leaves
Scan prompts, responses and tool arguments for sensitive data, then block, redact or log per workspace.
PII redaction for LLMs →Regex and ML classifier pre-filters on every call, extensible with your own HTTP scanner plugins.
LLM guardrails & injection protection →Keep operation viable
Real-time cost attribution per workspace, key and model, with hard and soft budget caps enforced before the call runs.
LLM cost attribution →One OpenAI-compatible endpoint in front of 14 providers, with weighted, capability-aware routing and automatic failover.
Prometheus metrics, OpenTelemetry traces on the GenAI conventions, and structured per-request logs for every call.
One control plane. Three enforcement points.
- Identity
- Policy
- PII
- Budget
- Approval
- Audit
The same control plane above — identity, policy, PII, budget, approval and audit — is enforced at each of the three points below. All three run in one gateway process on port 8080: your app reaches LLM providers through the LLM Gateway, your agent reaches MCP tools through the MCP path on that same gateway, and your agent reaches peer agents through the A2A path on it.
Governance that does not become the next bottleneck.
Single-digit millisecond policy overhead in typical configurations
Policy, PII and budget checks run in-process on the request path — no extra network hop to a separate policy service.
How DVARA reports request latency →Active-active multi-region deployment
Run a gateway in each region with its own region identity, used for data-residency routing. Regions share configuration and pick it up on their next poll.
Multi-region deployment guide →Stateless horizontal scaling
Durable state lives in PostgreSQL, so any pod can restart or scale out behind your autoscaler without coordination.
Autoscaling with an HPA →Caching, streaming and provider failover behaviour: Response caching · SSE streaming · Resilience and provider failover
Why a basic gateway is not enough for production agents.
Test policy before it reaches production
- Basic gateway
- Config flags or an allowlist, edited in place and live on save.
- DVARA
- A YAML policy DSL under version control, with conflict detection at load time and a dry-run mode that evaluates a policy against a supplied context before you activate it. Dry-run answers how that context would be decided — it does not exercise your whole traffic mix.
Prove the audit trail was not altered
- Basic gateway
- Logs to stdout, or rows in a database anyone with write access can edit.
- DVARA
- Every record is HMAC-SHA256 signed and hash-chained on the response path, so chain continuity is verifiable end to end and any gap or alteration is detectable. Append-only by application invariant, not by hopeful convention.
Govern the tool call, not just the model request
- Basic gateway
- Governs the model request; tool calls land in a separate, mutable log.
- DVARA
- Tool calls are policy-checked and PII-scanned at the argument level on the same control plane as model calls, and signed into the same hash-chained audit — one record across model calls and tool calls. Applies to MCP servers registered with the DVARA MCP Gateway.
Stop runaway delegation and agent loops
- Basic gateway
- No view of a chain — every call looks like the first one.
- DVARA
- Loop detection watches the chain across MCP tool calls and agent-to-agent hops and kills a session once it starts spiralling, with human approval available for high-risk tool calls and a session-level cost and compliance summary. One OpenTelemetry trace spans LLM turns and MCP calls.
Generate evidence from the controls already running.
DVARA does not make you compliant by itself. It gives your security and compliance teams traceable records of the controls enforced at the AI boundary.
- Policy decisionsEach request records ALLOW or DENY with the rule that decided it and the reason, alongside the dry-run history for that policy.
- PII eventsEach detection records the action taken, the pattern matched and the workspace it belongs to.
- ApprovalsA tool call held for human approval records the request and the decision that released or refused it.
- Signed audit recordsRecords are HMAC-SHA256 signed and hash-chained, so a gap or an alteration is detectable. Signed audit is part of the licensed platform; without a licence the log is local and unsigned.
- ResidencyRouting is geo-aware: a request is sent only to providers in the workspace’s allowed regions, and one with no eligible provider is refused with a data-residency error rather than routed elsewhere.
- Erasure recordsTokenised PII in a workspace can be purged in one step. The purge is permanent and cannot be undone, and it applies to what DVARA holds — not to what your other systems have already stored.
Those records are what a report is built from. The DVARA Flightdeck generates one for a date range you choose, and the generation is itself an audit event.
- SOC 2 evidence
- HIPAA evidence
- GDPR evidence
- India RBI evidence
- India SEBI evidence
OWASP LLM Top 10, control by control
See exactly which risks DVARA controls at the gateway, and which remain outside it.
Gateway coverage does not replace model, application, identity, or retrieval-layer security.
Of the ten categories, DVARA covers 7 at the gateway layer, 2 in part, and 1 sits outside the gateway boundary. Every detection writes a signed audit event.
Regex and ML classifier pre-filters, per-workspace patterns. Blocked or flagged, with the policy decision recorded.
Regex always-on plus an opt-in embedded scanner, 22 filter types. Block, redact or log per workspace, responses included.
BYOK credentials encrypted at rest or held in your vault, rotated with grace, every resolution audited.
Out of scope at the gateway — a training-time concern. Provider allowlists stop unvetted models being used.
JSON Schema enforcement across providers, plus post-filters for XSS, SQLi and SSRF before delivery.
Per-agent tool allowlists, argument-level MCP policy, loop detection with a kill switch, and human approval gates.
System prompts are held server-side and never returned; extraction attempts are caught by the injection filters.
PII scanning on retrieved context and tool results. Vector store hardening stays with your retrieval layer.
Embedding-based grounding checks compare claims to their sources, logging, flagging or blocking on failure.
Hard and soft budget caps, per-workspace and per-key rate limits, and token quotas enforced before the call runs.
Score your AI stack in five minutes
You've just seen the failure modes. The AI Agent Production-Readiness Scorecard scores your stack against them in 15 questions — visibility, cost, audit, blast radius, and data residency. Governance either sits in the request path, or it doesn't count. Find out which side you're on.
15 questions · ~5 minutes · nothing you answer leaves your browser
When AI reaches production, the problem shows up differently for every team.
CTO: cannot scale agent deployment safely
- Pain
- Every team wants to ship agents, and each one arrives with its own rules for what they may touch.
- Consequence
- Approving the next deployment means re-reviewing the last one, because there is no shared control to point at.
- With DVARA
- One control plane in front of model calls, tool calls and agent-to-agent hops, with per-workspace policy and a record of every decision. Adopt it one plane at a time rather than all at once.
Platform Engineer: too many direct model and tool calls
- Pain
- A dozen teams call providers directly, and their agents reach tools and other agents through paths you do not own.
- Consequence
- There is no single place to apply a rule, so every new team is another integration to review and another exception to remember.
- With DVARA
- Three governed data planes on one control plane: the LLM Gateway at the edge for model requests, the MCP Gateway for tool calls, the A2A Gateway for delegation hops — sharing policy, keys and audit.
CISO: cannot prove what data or actions crossed the boundary
- Pain
- Prompts leave from laptops and services nobody registered, and tool calls act on systems you never saw the request for.
- Consequence
- Asked what crossed the boundary last quarter, and under which rule, the honest answer is assembled from memory.
- With DVARA
- Calls that go through DVARA are policy-evaluated, scanned for PII and written to a signed trail with the workspace and key behind them. Calls that bypass it are not covered — which is the argument for putting it in the path.
Compliance: cannot produce evidence
- Pain
- An auditor asks for proof that the controls you described in the questionnaire were actually running.
- Consequence
- Screenshots and spreadsheets get assembled by hand, and the evidence is only ever as good as the person who collected it.
- With DVARA
- Policy decisions, PII events, approvals and signed audit records come out of the controls themselves, and a report covers a date range you choose. DVARA does not make you compliant — it gives your team traceable records.
CFO/FinOps: cannot attribute or enforce spend
- Pain
- The provider invoice arrives as one number for the whole company.
- Consequence
- Budgets get set on estimates, and an overrun is something you find out about after the month has closed.
- With DVARA
- Each call is priced as it completes and stamped with the workspace, key and model behind it, and hard and soft caps are evaluated before the call runs.
Questions teams ask before they deploy.
How does DVARA identify an agent?
By the credential it presents. Every client — an application, an agent, a CI job — sends a workspace API key as a bearer token, and DVARA resolves that key to a workspace server-side before any rule runs, so you never pass a workspace ID yourself. Tool calls are additionally grouped into an agent session, and each record carries the session, the trace, the MCP server and tool, the policy decision, and the authenticated user where one is available. Agent-to-agent traffic adds a registry of peer agents with their own agent IDs. What DVARA attributes is the credential and the session behind a call — it does not verify that the software holding a key is the agent it claims to be.
What happens when an agent calls an MCP tool?
The call goes to the MCP Gateway instead of the MCP server directly, and passes through a chain of stages before it reaches the upstream server: authentication, rate limiting, workspace resolution, registry lookup, budget enforcement, policy evaluation, loop detection, approval gating, PII scanning, injection scanning, and audit recording. That is a separate path from a model request through the LLM Gateway, and it is evaluated at the argument level rather than on the tool name alone. It covers MCP servers you have registered — a tool an agent reaches by another route is not in the path. Agentic governance in detail →
Can each workspace have different policies and budgets?
Yes. Policy is evaluated per request, per model and per workspace, and a workspace can carry its own policies, budget caps and provider credentials. Cost is attributed per workspace, key and model, and hard and soft caps are evaluated before a call runs rather than reconciled afterwards. Platform-level defaults cover anything a workspace has not set, so a new workspace is governed before anyone configures it.
Does DVARA see or store our provider keys?
It handles them, and you choose how. Resolution runs in four steps: the workspace’s own credential first — Encrypted mode stores it with AES-256-GCM and decrypts it in process, Reference mode stores only a pointer and resolves the secret from your HashiCorp Vault, AWS Secrets Manager or Azure Key Vault at request time — then a platform-default credential, then a direct vault lookup, then an environment variable. Strict-BYOK turns the fallbacks off, so a workspace without its own credential is refused rather than borrowing the platform key. All of it runs on infrastructure you operate, but it would be wrong to say DVARA never sees your keys: in Encrypted mode it decrypts them to make the call. How credentials are stored and resolved →
Where does DVARA run?
Two models. Self-managed: you run it in your own infrastructure — VPC, cloud or on-prem — as container images activated by a signed licence key, using Docker Compose on a single host or the Helm chart on Kubernetes, which is the same chart on EKS, GKE, AKS or DOKS. Managed hosting: a dedicated cluster we run for you in your region, arranged through sales. The core platform behaves identically in both. On a self-managed install nothing goes back to us — the licence is validated locally, with no callback and no required telemetry. Deployment models compared →
What stays inside our perimeter?
On a self-managed install, everything DVARA persists sits on infrastructure you run: policies, budgets, workspaces, provider credentials, audit records, and the Flightdeck itself, all backed by a PostgreSQL you operate. Prompts and completions pass through the gateway on their way to the provider and are not copied to us. What does leave is the call you asked for — the prompt goes to the model provider you chose, and a tool call goes to the MCP server you registered. So this means DVARA adds no second destination for your data, not that the traffic never goes anywhere.
How do the LLM Gateway, MCP Gateway, A2A Gateway, and Flightdeck fit together?
One control plane, three enforcement points — and since 1.7.0 they are three paths on one process, not three services. The gateway serves model calls on :8080, tool calls under /mcp and agent-to-agent hops under /a2a. The separate :8070 and :8075 listeners were retired when the planes merged; a licence activates the two agentic paths rather than starting anything new. How the planes are put together →
What crosses the boundary when DVARA is running?
Model traffic: prompts and completions between your application, the LLM Gateway and the provider you called. Tool traffic: MCP tool arguments and responses between your agent, the MCP Gateway and the registered MCP server, which is often internal to you. Agent traffic: A2A messages between your agent, the A2A Gateway and the peer agent. Everything the governance itself produces — policy decisions, PII findings, approvals, audit records and cost records — is written to your own database and does not leave it. On a self-managed install there is no callback to us; on managed hosting the platform runs in a dedicated cluster we operate, which is the difference to weigh between the two.
Is DVARA open source?
No — DVARA is a commercial AI governance platform, not open source. The LLM Gateway is free to self-host, in development and in production, with no feature gate and no time limit. A licence adds the MCP and A2A governance planes, an SLA and a support contract.
How is DVARA different from LiteLLM?
LiteLLM is an open-source library and proxy for multi-provider routing. DVARA is an AI governance platform — Policy-as-Code, tamper-evident signed audit, PII and injection guardrails, and argument-level MCP tool-call governance are built into the request path, not bolted on. See the full comparison →
What is the latency overhead?
Governance runs in-process on the request path — there is no extra network hop to a separate policy service. Policy checks add single-digit milliseconds in typical configurations, the workspace lookup resolves in under a millisecond, and optional caches add no overhead when disabled. The Flightdeck dashboard reports live P95 latency for your own traffic.
Which LLM providers are supported?
14 today — OpenAI, Anthropic, Google Gemini, AWS Bedrock, Azure OpenAI, Mistral, Cohere, Groq, and more — behind one OpenAI-compatible endpoint, plus self-hosted models via Ollama.
Do we need to change our application code?
No. DVARA is drop-in OpenAI-compatible — point any OpenAI SDK or tool at the gateway URL and governance applies on the first call. Tool calls from AI agents are governed the same way through the MCP Gateway.
What is free, and what needs a licence?
The LLM Gateway is free and fully featured, self-hosted, in development and in production — policy enforcement, PII detection, guardrails, the tamper-evident signed audit chain and cost tracking are all included, with no feature gate and no clock. A licence adds the MCP and A2A governance planes, an SLA and a support contract. A trial licence lets you evaluate the whole platform, MCP and A2A gateways included, on your own self-hosted install. Pricing and deployment models →
The evidence your auditor asks for — built into every request, not bolted on after.
Preparing for a SOC 2 audit? See the evidence DVARA generates →
Put DVARA in front of one real AI workflow.
Run it free in your own infrastructure and see policy, PII, budget, and audit decisions on the first request.
Free and self-hosted, production included. A licence adds the MCP and A2A planes with support.