Keep sensitive data out of model traffic. Inspect it before it crosses the next boundary.
DVARA inspects the requests and responses you configure it to inspect, inside your own deployment, and applies the action you chose — log, block, or redact — before the content reaches a provider, a tool, a peer agent, or the caller. Detection, redaction, and NER carry different edition requirements.
Regex detection with log or block runs keyless; redaction and tokenization are licensed.
How does PII actually leak through an LLM call?
Someone pastes a customer record into a chat box; a retrieval step pulls an identity number into context; a model echoes an email address straight back at the caller. Provider-side filters are a black box you cannot audit, and “tell people not to” is not a control. What DVARA adds is an inspection point you operate, on the paths you choose, doing what you configured it to do — which is a narrower promise than compliance, and a checkable one.
What can DVARA inspect, and in which direction?
Six paths, sharing one engine and one configuration — but not one behaviour. Which are inspected is a per-tenant setting, and the response and streaming paths have switches of their own.
Scanned after policy evaluation and before the provider is called, across user messages, tool result blocks, and the arguments of a function call. This is the only path where blocking rejects the call outright, with a 400.
Scanned after the provider replies and before the caller sees it. Redaction rewrites the body; logging returns it unchanged. Blocking is not applied here, so on this path the audit event is your signal rather than a stopped response.
Scanned in flight rather than after the fact: text accumulates in a rolling buffer and each safe region is scanned, with an overlap kept between windows so a value split across two chunks is still caught. Here blocking does apply — the stream terminates with a content-filter finish reason.
The DVARA MCP Gateway runs the same engine and the same configuration over tool-call arguments before forwarding, and recursively over a successful response body on the way back.
The A2A plane enforces your tenant’s PII setting on each outbound message part and scans the peer’s reply. Redaction of structured response bodies there is a documented follow-up, so treat blocking as the response-side control on that plane.
Stripping always runs before a response is written to the cache, and it always uses redaction behaviour regardless of the action you configured — so a cached entry cannot re-serve one caller’s sensitive values to another.
What actually finds the sensitive data?
Three detectors you can layer, with different accuracy and different deployment consequences. The default posture is regex only, and the gateway logs which posture is active when it starts.
Sixteen structured types, validated rather than merely matched: Luhn on cards and NPI, a DEA checksum, Verhoeff on Aadhaar, structural validation on PAN. That is what stops an arbitrary 12-digit number being reported as an identity number. Runs in-process.
Adds fourteen filters the regex set deliberately does not cover — MAC address, bank routing, VIN, street address, ZIP, tracking number and more — chosen not to overlap, so one entity is caught once. Eight further dictionary-based filters are opt-in per tenant because they collide with ordinary English. It does no checksum validation, so keep regex for cards.
For unstructured PII — names, locations, organisations — run Presidio as your own pod and point the gateway at it. This is the one detector that makes a network call, to a service inside your own deployment. It is fail-open: if the pod is unreachable, detection falls back to regex-only rather than failing the request.
Add your own patterns, and restrict which built-in filters a tenant runs, from the console or tenant metadata. Layered NER is not on by default — the default posture is regex only, and the gateway logs which posture is active at startup.
What happens when a match is found?
Detection and action are separate steps, and the action is yours. The step worth reading twice is the fourth: block means three different things depending on which path the match was on.
- 1
The content reaches an enforcement point
A request arrives at the LLM Gateway, the MCP Gateway, or the A2A Gateway. Scanning runs where you enabled it — it is a per-tenant setting, not something that happens to traffic you have not configured.
- 2
The configured detectors evaluate it
Regex runs by default. The embedded scanner and Presidio join it if you turned them on, and overlapping detections are deduplicated so the higher-confidence result wins.
- 3
Your tenant policy picks the action
Log, block, or redact — resolved per tenant, falling back to the platform default, which is log. The action is what decides whether anything actually changes.
- 4
The action is applied — and it differs by path
On the request, blocking rejects with a 400 and redaction replaces values before egress. On a non-streaming response, redaction rewrites the body and blocking is not applied. On a stream, blocking terminates it with a content-filter finish reason.
- 5
The detection is recorded
A distinct event records the request detection, the redaction, or the response leak. The payload carries the entity types and counts, and never the values themselves.
If you redact a value, can you get it back?
Within limits worth designing around. Redaction mints a token and keeps the original encrypted, so a workflow that legitimately needs the value can still recover it — but recovery is an admin operation, and tokens do not live forever.
A redacted value becomes a typed placeholder token in the text that continues onward, so the shape of the prompt survives and the model gets a stable stand-in rather than the value.
Encrypted with AES-256-GCM in a durable, tenant-scoped store that is shared across replicas, so a token minted on one pod resolves on another and survives a restart. The encryption password is yours to supply and manage.
De-tokenization is an admin operation, restricted to the owner and policy-admin roles. Purging a tenant’s token store is owner-only and irreversible.
Tokens expire — the default retention is 30 days — and each tenant has a ceiling on how many are stored, 50,000 by default. Plan any workflow that needs the original value inside that window rather than assuming a value is always recoverable.
A tenant can opt into restoring the tokens that request minted in the response the caller receives. It is off by default, scoped to that request, non-streaming chat completions only, and runs after the cache write — so the cache only ever holds the tokenized form.
The provider and the cache see tokens. The caller sees tokens unless you enabled the round-trip. The audit record sees entity types and counts. The original value lives only in the encrypted store, until it expires or is purged.
Where do you configure this?
On one screen per tenant. The action, which built-in filters run, the guardrail posture, and the de-tokenize and purge controls all live together rather than being scattered across pages.
How does DVARA compare on PII and data protection?
DVARA leads every row in this table, which is unusual enough that you should check it rather than take it on trust. These are the three alternatives that score strongest on data protection in the matrix behind how DVARA compares — chosen by score, not by how weak they are — and each row is checkable against that product's own public documentation.
| Capability | DVARA | Portkey | AWS Bedrock | TrueFoundry |
|---|---|---|---|---|
| PII detection + redaction (LLM + MCP) | ✓ | ∼ | ∼ | ∼ |
| DLP custom patterns per tenant | ✓ | — | — | — |
| Reversible tokenisation | ✓ | — | — | — |
| Pricing model | Licensed, sized by request volume — no hard stop on overage | Subscription from $49/mo + per-request overage (source) | Token-metered on-demand, or provisioned throughput (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.
Which parts of this need a licence?
The line is between finding sensitive data and changing it. Detecting and refusing runs keyless; rewriting the content, and keeping a reversible copy of what you rewrote, does not. See what a licence covers.
Regex-based detection, with log or block as the action. That is detection and refusal — enough to stop sensitive data reaching a provider, and enough to see what your traffic contains.
Redaction itself: reversible tokenization and the token store, plus Presidio and GLiNER NER. The signed, hash-chained audit trail is licensed too — keyless keeps a local unsigned log.
The MCP and A2A planes are licensed and have no keyless tier at all, so PII enforcement on tool calls and agent hops arrives with those planes rather than with the free gateway.
Common questions about PII detection and redaction
Does detection send data to a third party?
Not with the default detectors. Regex and the embedded scanner run in-process inside your own deployment. Presidio is the exception: it is a network call, to an analyzer pod you run yourself, so the data stays in your deployment but does leave the gateway process. No detector calls a vendor API.
Which detectors and types are supported?
Regex covers sixteen structured types with checksum or format validation — cards by Luhn, NPI, DEA, Aadhaar by Verhoeff, PAN structurally, plus email, phone, SSN, IP, passport, IBAN, MRN and more. The embedded scanner adds fourteen complementary filters by default, with eight dictionary-based ones opt-in per tenant. Presidio adds NER for names, locations and organisations. Custom patterns can be added per tenant.
Which traffic can be inspected?
LLM requests and responses including streams, MCP tool-call arguments and responses, and A2A messages and replies. They share one engine and one configuration, but not one behaviour on every path — the response and streaming paths have their own switches, and blocking behaves differently on each.
Can streaming responses be inspected?
Yes, and it is on by default. Text accumulates in a rolling buffer, each safe region is scanned, and an overlap is kept between windows so a value split across two chunks is still caught. On a stream, blocking does apply — it terminates the stream with a content-filter finish reason — which is not true of a non-streaming response.
What happens when PII is detected?
Whatever your tenant action says: log and forward unchanged, block, or redact. The platform default is log, so a deployment nobody has configured detects and records without changing traffic. Blocking rejects a request with a 400, is not applied to a non-streaming response, and terminates a stream.
Is redaction reversible?
Within limits worth planning around. Values are encrypted with AES-256-GCM in a durable tenant-scoped store, and restoring one is an admin operation limited to the owner and policy-admin roles. Tokens expire — 30 days by default — and each tenant has a storage ceiling, so treat recovery as time-bounded rather than permanent.
Does redaction happen before caching?
Yes, and this one is not configurable. Stripping runs before a response is written to the cache and always uses redaction behaviour regardless of the action you chose, so a cached entry cannot re-serve one caller’s values to another. The opt-in response round-trip runs after the cache write for the same reason.
What appears in logs, traces, audits, and caches?
Audit payloads carry entity types and counts, never the values. The cache holds the tokenized form. The original value lives only in the encrypted token store until it expires or is purged. Detections write distinct events for a request detection, a redaction, and a response leak, so the three are distinguishable after the fact.
Can policies differ by tenant?
Yes. Whether scanning is on, which action applies, whether responses and streams are scanned, which built-in filters run, and any custom patterns are all per-tenant, set from the console, the tenant portal, or the automation API. A tenant setting falls back to the platform default where it is not set.
Which edition includes detection, redaction, and tokenization?
Regex detection with log or block runs with no licence key. Redaction itself — reversible tokenization and the token store — is licensed, as are Presidio and GLiNER NER and the signed, hash-chained audit trail. Free detection does not mean free redaction, which is the distinction most worth checking before planning a rollout.
Start by seeing what your traffic actually contains.
Detection with log as the action changes nothing and shows you everything — it is the cheapest first step, and it runs without a licence key. Decide on blocking and redaction once you have looked.