Blog

DVARA 1.0.0 is generally available. It gives engineering and governance teams one place to set policy, protect sensitive data, control cost, and record what happened across LLM and MCP traffic.

This post covers why we built it, what is in 1.0.0-GA, and how to run it in your own infrastructure today.

In the previous post, you got DVARA running and sent requests to multiple providers through a single OpenAI SDK client. This post covers the next layer of AI gateway capabilities — LLM streaming, structured JSON outputs, Prometheus observability, and local development with Ollama.

DVARA is an AI gateway that governs model, tool and agent-to-agent calls. Its LLM Gateway accepts the OpenAI API shape, so an existing SDK can use DVARA by changing the base URL. Your application keeps the same client while model requests gain policy, PII checks, budgets, audit, routing, and operational evidence.

An agent can keep sensitive data out of a model prompt and still leak it in the next tool call. MCP arguments and responses are separate data paths, so they need their own policy, PII handling, and audit controls.

An AI agent can call a tool, read the result, and decide what to do next. That makes it useful. It also means one bad decision can repeat at machine speed: another database query, another email, another refund attempt, another billable model call.

Your API gateway handles TLS termination, rate limiting, and request routing. It does these things well. But when your traffic carries prompts, tokens, tool calls, and model-specific payloads, an API gateway becomes a passthrough — it can see the HTTP envelope but not the AI semantics inside it.