You block PII in LLM traffic before it leaves your environment by inserting an inline AI gateway that performs reversible PII redaction (synthetic / mask / hash) with format preservation on every prompt, scores risk with a 7-factor probabilistic model on top of deterministic policy, and writes a content-free SHA-256 hash-chained audit log instead of storing raw prompts. The PII never reaches OpenAI, Anthropic, Google Gemini, or any of the other supported providers in the clear; the user still sees their own data in the response because redaction is reversible at the gateway. This guide walks through how the three redaction modes work, shows a before / after redacted-then-restored payload, presents the architecture diagram for the egress block, and explains the metadata-only audit pattern that keeps your audit log out of HIPAA / GDPR / PCI scope.
What Is Reversible PII Redaction?
Reversible PII redaction is the practice of substituting sensitive fields with placeholder tokens before a prompt leaves the gateway, sending the redacted prompt to the LLM provider, and then restoring the original values in the response before returning it to the application. The provider sees only redacted content; the application sees a coherent answer about the user’s actual data. The mapping between original values and placeholder tokens lives in the gateway’s session state and never leaves your environment. This is the difference between traditional DLP — which is detect-and-block — and AI-aware redaction, which is detect-redact-and-restore.
The Three Redaction Modes: Synthetic / Mask / Hash
Vaikora supports three redaction modes, selectable per workspace, per route, or per field. Each makes a different trade-off between model utility, traceability, and irreversibility.
| Mode | What it does | Format preservation | When to use |
|---|---|---|---|
synthetic |
Replaces real values with realistic fake values of the same type (e.g. a fake but valid SSN format, a fake phone number, a fake name) |
Yes — the model still sees a string that parses as an SSN, phone, or name and reasons about it normally |
Production user-facing apps where the model’s reasoning depends on the data shape (“summarize this customer’s case”) |
mask |
Replaces real values with a typed placeholder token (e.g. , , ) and tracks the mapping for restoration |
Partial — the token is recognizable but not literal; the model still distinguishes “the SSN” from “the email” |
Default for HIPAA / PCI / GDPR workspaces; clearest audit story; restoration on response is straightforward |
hash |
Replaces real values with a deterministic hash (e.g. the same SSN always becomes the same opaque hash within a session) |
No format preservation; the hash is opaque |
High-sensitivity fields where even the format should not leak; correlation analysis without exposing values |
Critically: reversibility is only at the gateway. The mapping table is held in encrypted session state and is never sent to the provider, never written to the audit log, and never visible to the application. Synthetic and mask modes are reversible by design (the gateway restores values on the response); hash mode is one-way and used when the application does not need restoration.
Before and After: A Redacted-Then-Restored Payload
This is the canonical example: a customer support assistant being asked to summarize a case that contains real PII. The user’s prompt enters the gateway in the clear, leaves the gateway redacted, comes back from the model with redacted placeholders, and is restored to the user with their actual data.
1. Original prompt (entering the gateway from the application)
POST https://api.vaikora.com/v1/chat/completions
Authorization: Bearer $VAIKORA_API_KEY
Content-Type: application/json
{
“model”: “gpt-4o”,
“messages”: [
{
“role”: “user”,
“content”: “Summarize this case: Maria Hernandez (SSN 123-45-6789,
email maria.h@example.com, phone 415-555-0142) called
on April 28 about a denied refund of $2,499.00.”
}
]}
2. Redacted prompt (leaving the gateway, sent to the LLM provider) — mask mode
{
“model”: “gpt-4o”,
“messages”: [
{
“role”: “user”,
“content”: “Summarize this case: <NAME_1> (SSN <SSN_1>,
email <EMAIL_1>, phone <PHONE_1>) called
on April 28 about a denied refund of $2,499.00.”
}
]}
# OpenAI / Anthropic / Gemini etc. only ever see this version.
# The mapping <NAME_1> → “Maria Hernandez”, <SSN_1> → “123-45-6789”, etc.
# is held in encrypted session state at the gateway. It does NOT leave.
3. Synthetic mode variant — same prompt, different mode
# Synthetic mode replaces with format-valid fakes so the model’s reasoning is unchanged.
{
“messages”: [
{
“role”: “user”,
“content”: “Summarize this case: Jordan Okafor (SSN 412-88-3014,
email jordan.o@example.org, phone 415-555-0931) called
on April 28 about a denied refund of $2,499.00.”
}
]}
# The model produces a summary about “Jordan Okafor” with the synthetic SSN / email /
# phone. On the response side, the gateway restores the original Maria Hernandez values
# before the application sees the summary.
4. Model response (with redacted tokens still in place)
{
“choices”: [{
“message”: {
“role”: “assistant”,
“content”: “<NAME_1> (<EMAIL_1>) called on April 28 about a refund denial.
The disputed amount is $2,499.00. SSN <SSN_1> on file.”
}
}]}
5. Restored response (returned to the application)
{
“choices”: [{
“message”: {
“role”: “assistant”,
“content”: “Maria Hernandez (maria.h@example.com) called on April 28
about a refund denial. The disputed amount is $2,499.00.
SSN 123-45-6789 on file.”
}
}]}
From the application’s perspective the round-trip is transparent: the LLM appeared to reason about Maria Hernandez and produce a summary about her. From the LLM provider’s perspective, no PII ever arrived. From the auditor’s perspective, the audit log shows that redaction fired, what categories were redacted, and the SHA-256 hash of the original payload — without storing the original prompt content.
The Egress Block Architecture
The PII egress block is the standard inline gateway pattern with the redaction stage made explicit. The diagram below shows the flow in plain text.
your code
OpenAI SDK
Maria Hernandez, SSN 123-45-6789
- Detect — 12+ vectors / 4 layers: pattern, semantic, ML, behavioral
- Score — 7-factor probabilistic risk score
- Redact — synthetic / mask / hash with format preservation
- Mapping held in encrypted session state at the gateway
- Audit — content: false, metadata + SHA-256 hash of inspected payload
OpenAI / Anthropic / Gemini / Azure / Bedrock / Mistral / Cohere / Together / Groq / Ollama / custom vLLM
Only sees redacted content
- Response-side detection — catches injection in tool outputs / RAG
- Restore — placeholder tokens replaced with original values
Two design choices worth pointing out. First, the mapping table that links placeholder tokens to original values lives only in the gateway, never in the audit log, never in the model provider’s logs. Second, the response side runs the same 4-layer detection — this is where prompt injection planted in tool outputs or RAG content gets caught before the model’s recommendation reaches the user.
7-Factor Risk Score: Why Redaction Is Not Just Pattern Matching
Reversible redaction needs a confidence call on every match. Is this nine-digit string actually an SSN, or is it an order number? Is this email field a real customer email or an internal placeholder? The 7-factor probabilistic risk score sits on top of deterministic detectors and decides redact-vs-allow on the gray zone. The seven factors:
- Action. Action type, destructiveness, and payload analysis — what the request is actually trying to do.
- Agent. Agent age and maturity, historical violations, and approval rate.
- Temporal. Time of day, weekend / holiday context, and whether the request lands inside business hours.
- Environmental. IP reputation, production vs staging, and geographic context.
- Behavioral. Deviation from the agent’s baseline, action velocity, and pattern consistency.
- Compliance. Regulatory scope (HIPAA / PCI / GDPR), policy alignment, and audit requirements.
- Data sensitivity. PII presence, data volume, and sensitivity classification.
The combination is the right framing: deterministic policy enforcement with probabilistic risk scoring. Deterministic for the clear cases (a valid SSN regex inside a prompt is always redacted under hipaa preset); probabilistic for the gray zone (a nine-digit field that may or may not be a sensitive identifier).
The Metadata-Only Audit Pattern
If you redact PII out of the prompt but then log the original prompt content for evidence, you have not actually solved the compliance problem — you have moved it from the LLM provider to your own log store. The metadata-only audit pattern (content: false) is what closes the loop. The audit log retains the decision metadata, the redaction summary, the risk score, and a SHA-256 hash of the inspected payload, but does not retain the prompt content itself.
{
“action_id”: “act_2026_04_30_148ca”,
“agent_id”: “acme-prod/support-assistant”,
“action_type”: “chat.completions”,
“timestamp”: “2026-04-30T14:08:11Z”,
“latency_ms”: 9,
“risk_score”: 0.18,
“anomaly_flag”: false,
“threat_confidence”: 0.04,
“policy_decision”: “allow”,
“redaction_summary”: {
“mode”: “mask”,
“counts”: { “PERSON_NAME”: 1, “SSN”: 1, “EMAIL”: 1, “PHONE”: 1 }
},
“content”: false,
“payload_sha256”: “f1e2c4b5…d9a0”,
“prev_hash”: “a3b1d80e…77c2”,
“curr_hash”: “5e92fd34…091b”
}
This entry is HIPAA-, GDPR-, PCI DSS-, SOC 2-, ISO 27001-, NIST CSF-, and CCPA-compatible. The hash chain (prev_hash links to the previous entry’s curr_hash) provides tamper-evidence; the absence of prompt content keeps the audit log out of the regulated data scope.
Next Steps
If your team is shipping LLM features that touch customer data, the most valuable next step is to enable reversible PII redaction in mask mode against a non-production environment, run a representative sample of real prompts through the gateway, and inspect the audit log to see what categories fired at what frequency. The companion guides — “OpenAI Proxy Integration Without Rewriting Your App” and the secure AI development reference architecture — show how the egress block sits in a complete LLM application stack.
Your AI Agents Need a Control Layer
See how Vaikora intercepts, evaluates, and enforces policy on every AI agent action — in real time, before execution.
Frequently Asked Questions
How do I block PII before it reaches OpenAI / Anthropic / Gemini?
Insert an inline AI gateway with reversible PII redaction enabled. The gateway detects PII in the prompt, redacts it (synthetic, mask, or hash mode), forwards the redacted prompt to the upstream LLM provider, restores the original values on the response, and writes a content-free SHA-256 hash-chained audit record. The PII never leaves your environment in the clear.
What is reversible PII redaction?
Reversible PII redaction is detect-redact-and-restore: substitute sensitive values with placeholder tokens or synthetic equivalents before sending to the model, then restore the original values in the response so the user sees their own data. The mapping never leaves the gateway.
Which redaction mode should I pick?
Mask mode is the default for hipaa, pci-dss, and gdpr workspaces — clearest audit, straightforward restoration, model still distinguishes typed fields. Synthetic mode is best when the model’s reasoning depends on data shape (a model summarizing a customer case still needs a string that looks like a name). Hash mode is for the highest-sensitivity fields where format preservation itself is too much disclosure.
Does the LLM provider ever see the original PII?
No. The redacted prompt is what is sent to OpenAI, Anthropic, Google Gemini, Azure OpenAI, AWS Bedrock, Mistral, Cohere, Together AI, Groq, Ollama, or your custom vLLM. The mapping between placeholders and original values is held only in the gateway’s encrypted session state and is destroyed at the end of the session.
Does the application have to change?
No, beyond the one-line OpenAI base_url change to point at the gateway. The application keeps using the OpenAI SDK and sees a normal OpenAI-shaped response with the user’s real data restored. Redaction and restoration are invisible to the application code.
How does this avoid creating a compliance liability in the audit log?
The audit log is content-free by default (content: false). It retains decision metadata, the redaction summary (mode and field counts), the risk score, and a SHA-256 hash of the inspected payload — not the prompt itself. This satisfies SOC 2, HIPAA, GDPR, PCI DSS, ISO 27001, NIST CSF, and CCPA evidence requirements without storing prompt content.
What if the model needs the real data to produce a useful answer?
Most production cases work with mask or synthetic mode because the model reasons about the structure of the case (“a customer with a denied refund”) rather than the specific identifier. For workflows that genuinely require the real value (e.g. a tool call that looks up an account by SSN), the gateway can scope redaction to the prompt while passing the real value through to the deterministic tool path under a separate policy. This is configured per route, not globally.
How accurate is PII detection?
Up to ~ 99.9% accuracy in controlled evaluation, with <0.1% false-positive rate in testing. The 7-factor probabilistic risk score handles the gray-zone calls (nine-digit field that may or may not be an SSN) while deterministic detectors handle the clear cases.