Stop sensitive data from leaking into — and out of — your models.
DVARA scans every LLM prompt and response for PII and acts on it inline: block the call, redact the data before it reaches the provider, or log it for review. Detection runs in your own infrastructure — regex, Microsoft Presidio, or the in-process Phileas engine — with no raw PII ever leaving your boundary.
PII detection & redaction ship in every DVARA install — see pricing.
Every prompt is an exfiltration path. Every response is a re-injection path.
Employees paste customer records into chat; a RAG pipeline pulls an SSN into context; a model echoes an email address straight back. Provider-side filters are a black box you can't audit, and “just tell people not to” isn't a control an auditor will accept. DVARA inspects traffic on the way out and the way back, and acts before data crosses the line.
Detection that runs where your data already is
Regex (always on, Luhn-validated cards), Microsoft Presidio NER, and the embedded Phileas engine — 22 default filter types including SSN, cards, phone, email, IP, passport, and IBAN.
Regex and Phileas make zero network calls — no vendor API key, no data egress, sub-millisecond detection. Presidio, if used, runs as your own service.
PII scanning works on streamed SSE responses with a rolling window that catches matches spanning chunk boundaries — not just on buffered replies.
Redacted values become tokens backed by an encrypted store, so an authorized caller can de-tokenize later — workflows that legitimately need the value still work, without raw PII reaching the model.
Enable or disable, choose block / redact / log, add custom patterns, and restrict Phileas filters — all per tenant, from the console or tenant metadata.
PII is stripped before any semantic-cache write, so a cached response can never re-serve someone else’s sensitive data.
Detect, decide, act — in both directions
- 1
Inbound scan
The prompt is scanned by the configured detectors before it is dispatched to any provider.
- 2
Act
Block the call, redact-and-continue, or log — per tenant or platform policy. Redacted values are replaced inline before the request leaves your boundary.
- 3
Outbound scan
The model response is scanned for PII leaks before it returns to the caller, and before anything is cached.
- 4
Audit
Every detection is signed into the tamper-evident audit trail — the raw PII is never written into the audit payload. Tokens stay reversible for authorized de-tokenization.
Data-protection policy in DVARA Flightdeck
Common questions about PII redaction for LLMs
No. Regex and the Phileas engine run in-process inside your own deployment with zero network calls. Presidio, if you enable it, runs as your own service. No raw PII leaves your boundary.
Yes. Dvara scans both the outbound prompt and the inbound response, including streaming SSE responses, so leaks in model output are caught before they reach the caller.
Block the call, redact the value inline before it reaches the model or caller, or log and allow — configurable globally and per tenant.
Yes. Redacted values are replaced with tokens backed by an encrypted store, so an authorized caller can de-tokenize later without the raw value ever reaching the model.
Regex covers Luhn-validated cards, SSN, email, and phone; Presidio adds NER; Phileas adds 22 filter types including passport, IBAN, IP, and bank routing numbers. Custom patterns can be added per tenant.
Keep PII out of your models — in both directions.
PII detection and redaction ship in every DVARA install. Start a free 30-day trial, or read how it works.