What the gateway does not govern
A governance product that only lists what it covers leaves you to guess the rest, and a guess reads as a claim. So this page lists the boundary: what the DVARA gateway governs, what it governs only in part, and what it does not touch.
A call that does not go through the gateway is not governed
This is the boundary every gateway shares, and it comes first because nothing on this page changes it. The gateway governs the traffic that passes through it. A team that calls a provider directly, with its own provider key, is invisible to it: no policy, no PII check, no budget, no audit record.
Closing that gap is a network and procurement question, not a product setting:
- Send model traffic out only through the gateway, by egress policy.
- Issue provider keys to the gateway, not to teams. With keys held in the gateway, a team has no key to call a provider with.
- Know which teams hold provider accounts.
For MCP tool servers, Flightdeck can compare what developers have configured with what is registered: see shadow MCP servers. It finds what is written down, not what runs.
The surfaces, one by one
Governed means every request runs the gateway's checks — policy, PII, guardrails, budgets and rate limits as you set them — and is audited. Partly governed names what is checked and what is not. Not served means the gateway does not offer the API at all: a request to it through the gateway gets 404, so the only way to use it is directly with the provider, where it is ungoverned.
| Surface | Status | What that means today |
|---|---|---|
Chat completions, the Responses API, Anthropic Messages, Gemini generateContent, legacy completions, the Cursor base URL | Governed | Requests and replies are checked and audited, streamed or not |
Embeddings (/v1/embeddings) | Governed on the request | The input runs the same request checks as chat, so REDACT changes what is embedded. The returned vectors are not inspected; there is nothing in them to read. Your vector store and what you retrieve from it are outside the gateway |
Batches (/v1/batches and their input files) | Partly governed | The uploaded input file is scanned for PII as a whole (BLOCK refuses it, REDACT rewrites it) and its models are checked against what the workspace may use. A submit is checked against budgets and audited, and usage and cost are booked when the batch completes. The requests in the file are not checked for injection or against policy rules one by one, and the results file is not scanned |
| MCP tool calls, agent-to-agent calls | Governed in the Enterprise platform | See MCP and A2A. Not in DVARA Open Source |
Image generation (/v1/images/*) | Not served | On the roadmap |
Audio: transcription, translation and speech (/v1/audio/*) | Not served | On the roadmap |
| Realtime, bidirectional streaming (WebSocket) | Not served | On the roadmap |
Moderations (/v1/moderations) | Not served | On the roadmap |
Fine-tuning (/v1/fine_tuning/*) | Not served | On the roadmap, together with vector stores and assistants. Until then, training data sent for fine-tuning goes straight to the provider and is not governed |
| Provider files, vector stores, assistants and threads | Not served | Batch input files are the one exception, above |
Why fine-tuning matters most
Of the surfaces the gateway does not serve, fine-tuning carries the highest consequence. Sending training data to a provider is one API call, the data may hold exactly what your PII rules exist to stop, and a model trained on it cannot be untrained. The OWASP Top 10 for LLM Applications 2026 counts fine-tuning subversion under LLM05 Data and Model Poisoning.
Until the gateway governs fine-tuning, govern it the way you govern any direct provider call: hold the provider keys that can start a fine-tuning job, and decide who may use them.
Coverage that depends on what you send
Some controls are on the governed surfaces but only act when the request gives them something to act on. The failure-modes table has the full list. Two are worth naming here:
- Grounding checks a reply only against source documents the request sends. A reply with no sources is not checked. From 1.10.0 it is counted and labelled
unchecked: Ground responses in supplied sources. - Injection detection reads text. Images and audio in a request are passed to the model but not scanned for hidden instructions.
Related
- OWASP LLM & MCP Top 10 crosswalk — each risk, and what a governed request path can and cannot do about it
- What fails open and what fails closed