Skip to main content

Runtime AI governance

Ship AI faster.
Stay in control.
Prove every decision.

DVARA is a runtime AI governance platform for model, tool, and agent-to-agent calls — policy, data protection, spend control, and evidence.

Run DVARABook a Demo
AI APPSAI AgentsDVARARUNTIME GOVERNANCEIDENTITYPOLICYDATASPENDEVIDENCEALLOWED · EVIDENCE RECORDEDLLM ProvidersMCP ToolsPeer Agents
AI APPS + AI AgentsDVARARUNTIME GOVERNANCEIDENTITYPOLICYDATASPENDEVIDENCEALLOWED · RECORDEDLLM ProvidersMCP ToolsPeer Agents
Runs in your infrastructure

Keep governance and evidence in your environment.

Run DVARA in your VPC, cloud, or on-prem. Policies, credentials, budgets, and audit records stay in infrastructure you control. Model and tool payloads go only to the providers and servers you configure.

  • Deploy in your infrastructureRun DVARA in your VPC, cloud, or on-prem.
  • Use your provider keysStore encrypted credentials in your install or reference your own vault.
  • Verify the audit trailInspect HMAC-signed, hash-chained records for governed calls and decisions.
Built for your team

Ship more AI without creating a new control problem for every team.

Platform teams

Give every application and agent one governed path.

Security teams

Control what AI can access and see what crossed the boundary.

Compliance teams

Produce evidence from decisions that actually ran.

FinOps teams

Attribute spend and stop overruns before the next call.

Get started

One request. Five governance decisions.

Deploy DVARA, change the endpoint, and verify what happened on the first governed call.

  1. 1DeployUse Docker Compose for evaluation or Helm for a cluster.
  2. 2ConnectPoint your existing OpenAI-compatible SDK at DVARA.
  3. 3VerifyInspect the policy result, spend and audit evidence.
request.shzsh
$ curl -X POST https://dvara.acme.internal/v1/chat/completions \
> -H "Authorization: Bearer $TOKEN" \
> -H "Content-Type: application/json" \
> -d '{"model":"gpt-4o","messages":
> [{"role":"user","content":"Summarize this policy."}]}'
# OpenAI-compatible response
{"id":"chatcmpl-01J8DVARA",
"object":"chat.completion","model":"gpt-4o",
"choices":[{"index":0,"message":{
"role":"assistant","content":"The policy requires annual review."},
"finish_reason":"stop"}],
"usage":{"prompt_tokens":182,"completion_tokens":32,
"total_tokens":214}}
Run this quickstart
Works with your stack

Keep your models. Add runtime governance.

Keep your existing providers and SDKs. Change the endpoint, not the application.

  • OpenAI
  • Anthropic
  • Google Gemini
  • AWS Bedrock
  • Azure OpenAI
  • +9providers and OpenAI-compatible endpoints
Works with
OpenAI SDKLangChainSpring AIVercel AI SDKPydantic AI
View integrations
Capabilities

Six controls. One governed path.

Every call is identified, evaluated, protected, costed and recorded before it reaches the destination you configured.

01

Identity

Tie each call to its workspace and credential.

02

Policy

Apply versioned rules before model requests reach providers.

03

Data

Detect sensitive data and apply the workspace action—LOG by default.

04

Spend

Attribute cost and enforce configured budgets before each call.

05

Evidence

HMAC-sign and hash-chain records so changes are detectable.

06

Agent Actions

Evaluate agent model requests against configured policy, data and spend controls.

Routing

Connect once. Govern model calls across 14 providers.

One OpenAI-compatible endpoint with configurable routing and automatic failover.

Architecture

One DVARA deployment. Three governed paths.

Model calls pass through the DVARA LLM Gateway, tool calls through the MCP Gateway, and agent handoffs through the A2A Gateway. All three use the same policy and evidence model.

AI apps and agents
One shared platformDVARA AI Governance Platform
  • Identity
  • Policy
  • Data
  • Spend
  • Evidence

DVARA LLM Gateway

Model callsModels

DVARA MCP Gateway

Tool callsTools

DVARA A2A Gateway

Agent handoffsPeer agents

Performance

Governance should stay out of the way.

Decisions run inside the gateway request path.

Policy, data and spend checks run where each request is handled, without a separate policy-service network hop.

See request-path observability →

Gateways scale horizontally behind your existing infrastructure.

Add gateway instances behind your load balancer or autoscaler as traffic grows.

See autoscaling guidance →

Regional deployments apply governance close to the workload.

Run gateways in the regions your workloads require and use region-aware routing for governed traffic.

See multi-region guidance →
Why DVARA

Governance is built into the request path.

Test policy before activation.

Dry-run a versioned policy against a supplied context and inspect the decision without changing live traffic.

Explore Policy-as-Code →

Detect a changed or missing audit record.

HMAC signatures and hash chaining make edits, deletions and breaks in the governance record detectable during verification.

Explore audit evidence →

Inspect tool arguments, not only model requests.

For MCP servers registered with DVARA, policy and data checks inspect tool arguments before execution and record the decision.

Explore MCP governance →

Stop loops and require approval for risky actions.

Configure loop detection and approval rules to stop repeated activity and hold matched tool calls or agent handoffs for review.

Explore agent governance →
See how DVARA compares across 9 gateways →
Audit evidence

Turn runtime decisions into audit evidence.

DVARA turns the decisions made on the request path into traceable records your security and compliance teams can filter and export. It supplies evidence; it does not make your organization compliant.

  • Policy decisions
    See ALLOW or DENY, the deciding rule and the reason.
  • Data-protection actions
    See what was detected and the configured action that ran.
  • Human approvals
    For governed MCP calls, inspect the held request and the decision that released or refused it.
  • Signed audit records
    Verify HMAC signatures and hash-chain continuity for LLM governance records.

Filter records by workspace, event and date range in DVARA Flightdeck, then export evidence for SOC 2, HIPAA and GDPR reviews.

See how reports are generated
DVARA Flightdeck Audit Log with tenant, event type and date filters above an exportable event tableDVARA Flightdeck Audit Log with tenant, event type and date filters above an exportable event table
Filter governed events and export evidence without assembling it from application logs.
Security Coverage

Know where gateway controls apply—and where they do not.

See where DVARA provides gateway-level controls across the OWASP LLM Top 10—and where application, model or retrieval-layer controls are still required.

Full · 7 Partial · 2 Outside gateway · 1
LLM01
Full
LLM02
Full
LLM03
Partial
LLM04
Outside gateway
LLM05
Full
LLM06
Full
LLM07
Full
LLM08
Partial
LLM09
Full
LLM10
Full

Coverage assumes the relevant controls are configured and the traffic passes through the applicable DVARA gateway. Training, application, model, identity and retrieval controls remain your responsibility.

Review the complete OWASP mapping OWASP reference
Free self-assessment

Find the gaps in your AI controls.

Answer 15 questions about visibility, policy, data, spend and evidence. You receive the result immediately, and your answers stay in your browser.

Visibility Policy Data Spend Evidence
Check your governance gaps →

15 questions · about 5 minutes · no form required

FAQ

Questions teams ask before they deploy.

What does DVARA govern?

DVARA governs model calls that pass through the DVARA LLM Gateway. It applies configured identity, policy, data, spend, and evidence controls on the request path. Registered MCP tool calls and agent-to-agent traffic use the DVARA MCP Gateway and A2A Gateway.

See the governance architecture →

Do we need to change our application?

For OpenAI-compatible model calls, you usually change only the base URL and credential. Your existing SDK sends the request to the DVARA LLM Gateway, which returns an OpenAI-compatible response. MCP and A2A traffic use their corresponding DVARA gateway paths.

Run the quickstart →

Where does DVARA run?

DVARA can run self-managed in your VPC, cloud account, or on-premises environment. You can use Docker Compose on one host or Helm on Kubernetes. Dedicated managed hosting in a region you choose is available through DVARA.

Deployment models compared →

What data leaves our environment?

DVARA sends each model request to the provider you choose and each governed tool call to the MCP server you registered. On a self-managed deployment, DVARA stores policies, credentials, budgets, and audit records in infrastructure you operate; it does not send that governance data back to DVARA.

Review the data boundary →

Can we keep our existing model providers?

Yes. Keep your existing provider accounts and credentials, then configure DVARA to route governed model calls to the providers you choose. The integrations page lists supported providers and setup requirements.

Review supported integrations →

How is DVARA different from an AI gateway?

A basic AI gateway standardizes provider APIs and routes model traffic. DVARA is an AI governance platform: its LLM, MCP, and A2A Gateways are enforcement components for shared identity, policy, data, spend, and evidence controls.

Compare DVARA with AI gateways →

Put DVARA in front of one real AI workflow.

Connect one workflow and watch DVARA apply policy, protect data, attribute spend, and record evidence on the first call.

Run DVARABook a Demo