How to Redact PII Before Sending Data to an LLM

Redacting PII before sending data to an LLM means replacing personally identifiable values—emails, phone numbers, government IDs, payment cards, and similar literals—with neutral placeholders so the model receives enough context to respond without processing raw sensitive strings. The goal is to shrink your exposure surface: third-party model providers, log pipelines, and retrieval indexes see [EMAIL] instead of user@example.com, while your authorized systems can retain originals when legally permitted and operationally necessary.

Why redaction belongs before the model call

Once text is included in an LLM prompt, you lose fine-grained control over how that text is stored, logged, or reflected in outputs. Redaction at the preprocessing boundary gives you a deterministic choke point:

• Provider boundaries — Model APIs may retain prompts depending on account settings and product tier.
• Cross-session leakage — In poorly isolated systems, context from one user could influence another.
• Logging — Request middleware often logs bodies before your application logic runs unless you intercept early.
• RAG persistence — Embeddings stored in vector databases are difficult to erase field-by-field later.

Redaction is not a substitute for collecting less data, but it is one of the most practical controls developers can implement this week. Pair it with the broader patterns in LLM Data Leakage: Causes, Examples and Prevention and the PII and Secrets Leakage Checklist.

Redaction vs blocking vs allowing

Secrets (API keys, private keys, bearer tokens) should usually trigger block, not redact—replacing sk-test_abc123 with [API_KEY] still tells the model a secret was present and does not fix credential exposure if the raw value already hit logs. See How to Prevent API Keys from Leaking into AI Prompts.

For nuanced trade-offs between redaction, masking, and tokenization, read PII Redaction vs Masking vs Tokenization.

API-based redaction with IdenticAPI

Enable redaction by setting "redact": true on POST /api/v1/security/pii-secrets:

{
  "text": "Email user@example.com about invoice 9988. Callback: 555-010-0200.",
  "redact": true
}

The response includes findings plus redacted_text:

{
  "verdict": "suspicious",
  "risk": "medium",
  "findings": [
    { "category": "email", "start": 6, "end": 22 },
    { "category": "phone", "start": 48, "end": 60 }
  ],
  "redacted_text": "Email [EMAIL] about invoice 9988. Callback: [PHONE]."
}

Placeholder tokens are consistent and documented in PII & Secrets Detection docs: [EMAIL], [PHONE], [SSN], [CREDIT_CARD], [API_KEY], and others.

Product details: PII & Secrets Detection. Quick manual tests: PII Checker.

Preprocessing pipeline architecture

A typical redaction pipeline looks like this:

┌─────────────┐    ┌──────────────┐    ┌─────────────┐    ┌──────────┐
│ User input  │───▶│ PII scan     │───▶│ Policy      │───▶│ LLM call │
│ + RAG chunks│    │ (redact=true)│    │ engine      │    │          │
└─────────────┘    └──────────────┘    └─────────────┘    └──────────┘
                          │                    │
                          ▼                    ▼
                   Audit log (IDs only)   Block if secrets

Policy engine responsibilities:

• Map verdict to actions (safe → forward, suspicious → forward redacted text, unsafe → block)
• Merge redacted user input with redacted retrieval context
• Attach metadata (pii_redacted: true) for downstream analytics

Implement this as a dedicated module—see Building a Privacy Filter Before Your LLM API Call for a full design walkthrough.

What to redact in practice

Scan and redact all text assembled into the model context, not just the latest user message:

1. Current user message
2. Conversation history (prior turns may contain PII)
3. Retrieved RAG chunks from tickets, PDFs, or wikis
4. Tool outputs returned to the model (CRM lookups, search snippets)
5. System prompt inserts that include user-specific variables

Missing any of these layers creates a bypass. A user may ask an innocuous follow-up while the history still contains a credit card number from three turns ago.

Placeholder strategies

API redaction uses fixed placeholders ([EMAIL]). Alternatives include:

• Typed labels — [EMAIL_1], [EMAIL_2] when multiple addresses appear
• Pseudonyms — Replace with reversible tokens stored in a secure vault (closer to tokenization)
• Minimal masking — u***@example.com (partial visibility; weaker for LLM boundaries)

Fixed placeholders are simple and avoid re-identification through partial patterns. If the model must perform actions requiring exact values (e.g., "send email to this address"), keep those actions in tools that read from authorized stores—not from the redacted prompt.

Example workflow: customer support bot

User message (synthetic):

I'm user@example.com. My card ending 1111 was charged twice. Phone: 555-010-0200.

After redaction:

I'm [EMAIL]. My card ending 1111 was charged twice. Phone: [PHONE].

The model can still classify the issue as a billing dispute. A human agent or billing tool with proper access retrieves full details from your CRM—not from the LLM transcript.

Note: "ending 1111" may still be sensitive in some contexts. Detection focuses on full card numbers validated by Luhn; partial fragments may require custom rules or human review.

Redaction and model quality

Redaction can affect answers when the task requires exact literals ("What is my registered email?"). Mitigations:

• Route identity questions to authenticated profile APIs instead of the model
• Tell users when data was redacted for privacy
• Use server-side tools that operate on session-scoped identifiers, not prompt content

Test regression prompts after enabling redaction. Compare answer quality on a synthetic dataset before rolling out broadly.

Logging redaction events

Log structured metadata without raw PII:

{
  "event": "pii_redacted",
  "request_id": "req_abc123",
  "finding_categories": ["email", "phone"],
  "verdict": "suspicious",
  "conversation_id": "conv_456"
}

Store request_id from the API response to correlate with IdenticAPI usage dashboards during incident response.

Limitations

Redaction before LLM calls reduces risk but does not eliminate it:

• Re-identification — Surrounding context may still identify individuals without email addresses (rare names plus employer plus city).
• Model memorization — If raw data was sent before you enabled redaction, prior logs or fine-tuning datasets may still contain it.
• Incomplete detection — Obfuscated PII bypasses pattern scanners; see What Is PII Detection? for coverage limits.
• Downstream tools — Agents that browse the web or read files may re-fetch sensitive content outside your redacted prompt.

Schedule periodic reviews using the PII and Secrets Leakage Checklist.

Next steps

• Integrate the API: How to Detect PII in Text with an API
• Node.js and Python examples: PII Detection in Node.js, PII Detection in Python
• Compare redaction with masking and tokenization: PII Redaction vs Masking vs Tokenization