Inspect model traffic before it leaves your boundary. And inspect what comes back, before your code runs it.
DVARA checks the model requests and responses you configure it to check — for injection and jailbreak attempts on the way out, and for unsafe or leaked content on the way back — then blocks, flags, or logs by your policy. One enforcement point in front of every application behind the gateway.
Guardrails are licensed and have no free tier.
Why is prompt injection so hard to stop in the application?
A poisoned document, a crafted user message, or a tool response carrying instructions can override the system prompt, pull context back out, or push the model into output your own code then runs. Bolting a filter onto one application does not help the next one, and “the model is usually fine” is not a control. An enforcement point at the gateway covers whatever routes through it — which is a narrower claim than safety, and a checkable one.
What does DVARA look for?
Patterns on the way out, and different patterns on the way back. Every detection carries a risk score and a rule ID, so a match is something you can look up rather than a verdict you have to trust.
Twenty-three request-side patterns across jailbreak, direct injection, and indirect injection, each with its own risk score. Matching is case-insensitive, and zero-width Unicode characters are treated as indirect injection rather than ignored.
Eight request-side patterns for attempts to extract the system prompt, plus a response-side detector that compares the reply against the system prompt by n-gram overlap — so a paraphrased leak is caught, not just a verbatim one.
Twenty-one response-side patterns for content that would be dangerous to whatever consumes it — script injection, SQL, command injection, and server-side request forgery. It protects your downstream systems from the model, not the model from the user.
Six categories — profanity, violence, sexual content, competitor mentions, restricted topics, and your own deny-list patterns — with the last three configured from your own keyword lists.
Caps on messages per request, single-message length, estimated input tokens, and a default response-token ceiling applied when the client does not set one. A violation is refused with a 413 rather than passed on to be paid for.
An opt-in layer that compares a prompt against deny-intent examples you supply, to catch paraphrases the patterns miss. It needs a real embedding service, is request-side only, and is off by default.
What else can you require of a response?
That it has the shape your code expects, that its claims trace to the sources you supplied, and that a long conversation does not walk into the context window unannounced.
Require a response to match a JSON Schema. A response that fails is retried, and one that keeps failing is refused with a 422 rather than handed to code that expects a shape it did not get.
For retrieval workflows, sentence-level claims in a response are compared against the source passages you passed in, and claims below your threshold are flagged. It needs sources on the request — there is nothing to ground against otherwise.
As a request approaches the model’s context window you get warning headers with the utilization percentage, and pruning if you configured it — rather than discovering the limit as a provider error.
Streamed output is scanned as it passes, in windows with an overlap so a pattern split across two chunks is still caught. On a stream, blocking terminates it with a content-filter finish reason — but content already delivered has already been delivered.
Where does each check actually run?
This is the question to settle before enabling anything: some checks never leave the gateway, and some send your prompt text to another service. Both are supported — they are just different decisions.
Everything above runs inside the gateway on pre-compiled patterns, with no network call and no third party. This is what runs when you turn guardrails on and configure nothing else.
Lakera, Shield Gemini, Bedrock Guardrails and Aporia are HTTP calls to a service outside the gateway, and what they receive is the flattened prompt text. Treat enabling one as a decision about where your prompts go.
The bundled ONNX injection classifier runs inside the gateway — no HTTP, no API key, no egress — which is the option for air-gapped and residency-bound deployments that still want ML-grade injection detection. If the model cannot load, classification is skipped rather than the request failing.
Register an endpoint you run and DVARA posts the flattened prompt text, the tenant ID, and any config you set. Plugins are scoped platform-wide or per tenant and reload across the fleet without a restart.
Each call carries an HMAC signature over the request body, and your plugin must verify it — that proves the call came from your gateway and was not altered. It is authentication, not encryption, and not isolation: your plugin still receives the prompt text in the clear.
You choose per plugin. Open treats a failed call as no detections and lets the request through; closed rejects the request. The docs advise starting every new plugin open and promoting it only once you trust its uptime.
What happens when a prompt trips a guardrail?
Six stages, split at the provider. Detection and decision are separate steps — the detectors find things, and your action decides whether finding one changes anything.
- 1
The request reaches the gateway
Guardrails run after PII enforcement and before the provider is chosen. Which detectors run is your configuration — the pattern set, and any ML classifier or plugin you enabled.
- 2
Size limits, then detection
Oversized requests are refused first, with a 413. What survives is scanned for injection, jailbreak, extraction, and content-policy matches, each carrying a risk score.
- 3
Your policy picks the action
Block, flag, or log — set per tenant and overridable per category, so you can block injection while only flagging profanity. When several detections fire, the most restrictive action wins.
- 4
An allowed request goes to the provider
Blocking refuses the call with a 403 before egress. Flag and log forward it unchanged and record what was found — the request still goes.
- 5
The response is inspected
Schema validation runs, then PII, then the output guardrails: content policy, output sanitization, and system-prompt leakage. A stream is scanned as it passes rather than at the end.
- 6
The decision is recorded
A distinct event records a block, a flag, or a log, carrying the category, label, risk score, and rule ID of each detection — and never the text that matched. Counters go to your metrics stack.
Do these guardrails cover tool calls and agent hops?
Not the way they cover model calls, and the difference is worth knowing before you write a rule and assume it applies everywhere. Each plane has its own controls.
Model requests and responses through the DVARA LLM Gateway, including streams. That is the surface this page describes.
Sensitive-data detection and its own actions, on a separate pass that runs before guardrails on the request and before them on the response. Different detectors, different actions, different edition boundary.
Injection detection scans MCP tool responses before they enter the agent’s context. That is one detector, not the guardrail pipeline — the rest of tool-call governance is the MCP Gateway’s policy, approval, and loop controls.
PII enforcement, and not these guardrails: content-safety guardrails on the A2A stream are documented as a follow-up. Do not assume a rule written here applies to an agent-to-agent hop.
Where do you manage guardrail policy?
In DVARA Flightdeck. Register guardrails, tune thresholds, choose block, flag, or log per category, and review what each detection caught.
How does DVARA compare on guardrails and safety?
Against the three alternatives that score strongest on guardrails and safety in the matrix behind how DVARA compares — chosen by score, not by how weak they are. Each row is checkable against that product's own public documentation.
| Capability | DVARA | AWS Bedrock | Portkey | TrueFoundry |
|---|---|---|---|---|
| Prompt firewall (pre + post filter pipeline) | ✓ | ✓ | ∼ | ∼ |
| Jailbreak detection | ✓ | ✓ | ∼ | ∼ |
| Output sanitization (XSS, SQLi, SSRF) | ✓ | — | — | — |
| System prompt leakage detection | ✓ | — | — | — |
| Content policy filters per tenant | ✓ | ✓ | ∼ | ∼ |
| Pricing model | Licensed, sized by request volume — no hard stop on overage | Token-metered on-demand, or provisioned throughput (source) | Subscription from $49/mo + per-request overage (source) | Free tier, then $499/mo tiers + usage overage (source) |
Capabilities last verified June 2026; pricing models August 2026. A stale mark is worse than no claim — every row is checkable against each product's own public documentation. For the full matrix across ten alternatives, see how DVARA compares.
What do you need to run guardrails?
A licence. Unlike PII detection, which has a keyless tier, none of this runs without a key. See what a licence covers.
There is no keyless tier of this feature. Everything on this page — the pattern detectors, size limits, schema validation, grounding, plugins — needs a licence key.
The gateway itself, plus regex PII detection with log or block. That is detection of sensitive data, not injection defence — the two are separate pipelines with separate boundaries.
Gateway-enforced inspection is one control among several. It does not review your application code, harden your retrieval layer, or make a model safe — treat it as the layer that catches what reaches the gateway.
Common questions about LLM guardrails
How does DVARA detect prompt injection and jailbreak attempts?
By pattern first: twenty-three request-side patterns across jailbreak, direct injection and indirect injection, each carrying a risk score, matched case-insensitively and with zero-width Unicode treated as indirect injection. On top of that you can enable an ML classifier or your own HTTP plugin. Pattern matching catches known shapes — a novel phrasing that matches nothing is why the ML and semantic layers exist.
Does it inspect outputs as well as prompts?
Yes, and with different detectors. The response side runs content policy, output sanitization for script injection, SQL, command injection and server-side request forgery, and a system-prompt leakage check that compares the reply against the system prompt by n-gram overlap so a paraphrased leak is caught too.
Which checks run locally and which use an external service?
Every pattern detector, size limit, and schema check runs in the gateway with no network call. Lakera, Shield Gemini, Bedrock Guardrails and Aporia are HTTP calls to a service outside it, and what they receive is your flattened prompt text. The bundled ONNX injection classifier is the exception among ML options — it runs in-process with no egress, which is the path for air-gapped deployments.
What happens when a guardrail matches?
Your tenant action decides: block refuses the call with a 403 before it reaches a provider, flag and log forward it unchanged and record what was found. Actions can be set per category, so injection can block while profanity only flags, and when several detections fire the most restrictive one wins. Size violations are separate — they always refuse with a 413.
Can I bring my own detector, and what does it receive?
Yes. Register an HTTP endpoint you run and DVARA posts the flattened prompt text, the tenant ID, and any config you set, signed with an HMAC your plugin must verify. Note one thing that surprises people: a plugin returns detections, not decisions. The enforcement action is the tenant’s configured action, so a plugin cannot choose to block on its own.
What happens if a plugin is unavailable?
Whichever fail mode you set for it. Open treats the failed call as no detections and lets the request through; closed rejects the request outright. The guidance is to start every new plugin open and promote it to closed only once you trust its uptime, because closed turns your plugin’s availability into your gateway’s availability.
Can policies differ by tenant?
Yes. Whether guardrails run, the action, per-category overrides, the risk threshold, size limits, which plugins are enabled and their config are all per-tenant, falling back to the platform setting where unset.
Can streamed responses be inspected or stopped?
They are scanned as they pass, in windows with an overlap so a pattern split across two chunks is still caught, and blocking terminates the stream with a content-filter finish reason. Be clear about what that means: a stream is stopped part-way, so tokens already sent to the caller have already been sent. It is containment, not prevention.
What does JSON Schema enforcement do?
It requires the response to match a schema you registered, retries when validation fails, and refuses with a 422 if it keeps failing — so downstream code gets the shape it expects or a clear error, rather than malformed output. Providers differ in what they support natively; where a provider cannot do strict mode, the response carries a header saying so.
How do grounding checks work?
Sentence-level claims from the response are embedded and compared against the source passages you passed on the request, and claims below your threshold are flagged, logged, or blocked. It only works when the request carries sources — there is nothing to ground against otherwise — and it measures similarity to those sources, not truth.
Which OWASP LLM categories do these guardrails address?
Prompt injection, improper output handling, and system-prompt leakage are addressed by the detectors on this page. Sensitive-information disclosure is PII handling, excessive agency is MCP governance, unbounded consumption is size limits plus budgets. The platform-level mapping, with what is only partly covered and what is out of scope at a gateway entirely, is on the homepage. Coverage is not certification, and it does not replace application or model-layer review.
Do guardrails cover MCP and A2A traffic?
Partly, and it is worth being precise. Injection detection scans MCP tool responses before they enter the agent’s context — one detector, not this pipeline. On the A2A plane, PII enforcement applies but content-safety guardrails are a documented follow-up. Do not assume a rule written for model calls is enforced on an agent-to-agent hop.
Which edition includes guardrails?
All of it is licensed — there is no keyless tier of this feature. What runs without a licence key is the gateway itself plus regex PII detection with log or block, which is sensitive-data detection rather than injection defence.
Start by seeing what your traffic trips.
Log as the action changes nothing and shows you everything — which categories fire, how often, and on what. Decide what to block once you have a week of that rather than before.