Redact personally identifiable information before it enters an LLM request, not after a provider has received it. The practical goal is data minimization: send only the information the model needs, preserve enough structure for the task to work, and keep the original values inside a more tightly controlled system.
This is not achieved by adding one regular expression in front of an API client. Names are ambiguous, identifiers vary by country and business, and apparently harmless details can identify a person when combined. A reliable design therefore uses a documented data-flow map, multiple detection methods, task-aware replacement, and tests built from realistic examples.
This guide is an engineering workflow, not legal advice. The categories your organization must treat as personal, sensitive, regulated, or confidential depend on its jurisdictions, contracts, and use case. Technical statements and product capabilities cited below were checked against official sources on 2026-07-24.
Data minimization is narrower than “collect everything, then redact obvious identifiers.” The UK Information Commissioner’s Office describes the principle as processing personal data that is adequate, relevant, and limited to what is necessary for the stated purpose. In practice, this means excluding unneeded fields before detection and redaction begin (official ICO data minimisation guidance, checked 2026-07-24).
Map sensitive data flows before writing a detector
Start with the complete path of a request. The visible chat message is only one possible source of PII. An LLM call may also contain a system prompt, retrieved passages, conversation history, tool results, file extracts, metadata, error details, and identifiers added by middleware.
For each field, record five things:
| Field or source | Why the model receives it | Possible sensitive data | Allowed transformation | Where the original remains |
|---|---|---|---|---|
| User message | Answer the immediate request | Names, contact details, account data | Replace or drop by category | Application database |
| Retrieved document | Supply domain context | Authors, customers, case details | Redact before prompt assembly | Document store |
| Conversation history | Maintain continuity | Repeated identifiers and inferred facts | Re-scan every request | Session service |
| Tool result | Complete an agent step | Database rows, addresses, tokens | Allowlist returned fields | Tool boundary |
| Request metadata | Routing and debugging | Email, IP address, tenant name | Omit or pseudonymize | Gateway logs |
Draw trust boundaries around the browser, application, redaction service, model gateway, provider, telemetry platform, and support tools. Redaction should occur before data crosses the boundary you are trying to protect. If raw text first goes to an external detection service, you have changed the destination of the disclosure rather than eliminated it.
Also inspect responses. A model can repeat a placeholder, infer an identity from context, or return sensitive text supplied by a tool. Input redaction and output inspection are separate controls. If the workflow feeds model output into another model, search index, ticket, or trace store, map those downstream flows too.
OWASP’s LLM02:2025 guidance treats sensitive information disclosure as an application-level risk and recommends sanitization, input validation, access controls, and restricted data sources. It also cautions that system-prompt restrictions may not always be honored, so a prompt instruction should not be the only output control (official OWASP LLM02:2025 guidance, checked 2026-07-24).
NIST describes de-identification as removing identifying information so data cannot be linked to specific individuals, while also warning that some de-identified data can be re-identified. That warning matters for free text: removing an email address may not be enough when a rare job title, town, and incident date still point to one person (NIST IR 8053).
Define PII categories for the actual workflow
Do not begin with a universal list copied from a vendor. Build a policy for the application and its data. A useful taxonomy usually includes:
- direct identifiers, such as full names, email addresses, phone numbers, postal addresses, usernames, and government-issued identifiers;
- financial and account data, including payment-card numbers, bank details, customer IDs, and claim numbers;
- authentication material, such as passwords, session tokens, API keys, recovery codes, and security answers;
- sensitive attributes, including health, biometric, employment, education, precise location, or other regulated information relevant to the use case;
- indirect or quasi-identifiers, such as age, uncommon occupation, event date, small geographic area, and a distinctive case description;
- organization-specific secrets, including internal project names, unreleased product details, private URLs, and contract terms.
Treat secrets as a separate, fail-closed category even if a legal definition of PII would not include them. An API key should never be preserved because it is “not personal information.”
For every category, define an action rather than a label alone:
| Category | Default action | Possible exception |
|---|---|---|
| Credentials and access tokens | Block the request and alert safely | None in ordinary model prompts |
| Government or financial identifiers | Remove or replace with a typed token | Last four characters only when the task requires them |
| Person names | Replace with stable role-aware placeholders | Keep public figures only under an explicit policy |
| Dates and locations | Generalize or shift consistently | Retain when essential and approved |
| Internal record IDs | Tokenize | Preserve a nonreversible correlation token |
Write down what is deliberately retained. A support summarizer may need product names and error codes but not customer names. A document classifier may need a country but not a street address. An extraction workflow might require a relationship—“the same patient appears twice”—without needing the patient’s identity.
Combine deterministic and contextual detection
Use a layered detector. No single technique has adequate coverage across structured identifiers and natural language.
- Schema and allowlist controls: Do not put an entire database object into a prompt. Construct a new request object from fields the model is allowed to receive.
- Exact rules and checksums: Use regular expressions for well-formed patterns, then validate where possible. Length, prefix, checksum, and surrounding labels reduce false positives.
- Dictionaries: Match internal project names, customer domains, facility names, and other organization-specific terms.
- Named-entity recognition: Use a contextual model for people, locations, and organizations that do not follow fixed patterns.
- High-risk secret scanning: Detect credential formats and entropy-like strings, with a blocking action rather than ordinary replacement.
- Manual or policy review: Route novel high-risk document types and low-confidence cases for review before enabling automated submission.
Microsoft Presidio documents this kind of combination: its recognizers can use regular expressions, deny lists, checksums, rules, named-entity recognition, and surrounding context. Its analyzer reports detected spans, while its anonymizer can replace, redact, mask, hash, or encrypt them (official Presidio text anonymization documentation).
Managed detectors can be useful, but their boundary and supported behavior must fit the system. Amazon Comprehend, for example, returns an entity type, character offsets, and a confidence score for detected PII spans (official PII detection documentation). A confidence value is not a guarantee. Calibrate thresholds on your own languages, document formats, and error costs.
Normalize text cautiously. Unicode normalization may help matching, but transformations can invalidate offsets. Extracting text from PDFs, OCR, HTML, email, or office files can also split or reorder values. Run detection on the exact representation you will transform, and test the extraction layer as part of the privacy control.
Redact without destroying the meaning
Plain deletion often damages the task. Compare these prompts:
Customer reported that failed to receive a refund from .
[PERSON_1]reported that they failed to receive a refund from[MERCHANT_1].
The second version preserves roles and relationships. Use typed placeholders such as [PERSON_1], [EMAIL_1], and [ACCOUNT_1]. Within one request or authorized workflow, map repeated values to the same placeholder so the model can follow references. Avoid a global mapping that lets unrelated sessions be correlated.
Choose the transformation by purpose:
| Transformation | What it preserves | Main tradeoff | Typical use |
|---|---|---|---|
| Removal | Nothing from the original value | May remove useful context | Fields irrelevant to the task |
| Masking | A small visible fragment | The fragment may still be identifying | Last four digits for approved support flows |
| Generalization | A range or region | Reduces precision | Exact age, date, or address |
| Consistent pseudonymization | Equality and relationships | Stable tokens can enable correlation | Repeated people or accounts within one workflow |
| Reversible tokenization | A controlled path back to the original | Creates a sensitive mapping and key-management obligation | Approved workflows that must restore values |
Google Cloud’s official documentation distinguishes one-way and reversible pseudonymization and explains that deterministic transformations can preserve referential integrity across values. It also warns against supplying cryptographic keys as raw text and describes managed key handling as the preferred approach for its service (official pseudonymization documentation).
Keep the re-identification map outside prompts, traces, and analytics. Give it a short lifetime when possible, encrypt it at rest, restrict access, and bind it to a tenant and purpose. If the application only needs to insert a model-generated summary back into a customer record, it may not need to restore names at all.
Do not tell the model to perform the first redaction pass. Sending raw text to the model with “remove the PII” has already crossed the boundary. An LLM may assist an offline review inside an approved environment, but it is not a substitute for pre-request controls.
Test false positives, misses, and reconstruction risk
Build a labeled evaluation set before selecting thresholds. Include real data only when its use is approved and controlled; otherwise create representative synthetic cases. Cover:
- each supported language, locale, and writing system;
- names that are also common words, product names, or place names;
- punctuation, spacing, Unicode variants, OCR errors, and line breaks;
- nested and overlapping entities, such as a name inside an email address;
- structured identifiers with valid and invalid checksums;
- indirect identification from combinations of otherwise ordinary details;
- prompt injection text that asks the system to reveal, skip, or reverse redaction;
- documents with no PII, so over-redaction is measurable.
Measure at the span and category level. Recall asks what fraction of sensitive entities the detector found. Precision asks what fraction of its findings were actually sensitive. Report both: a detector that marks every noun as PII can have high recall while making the application unusable.
Weight errors by consequence. Missing an API key or national identifier is not equivalent to missing a city name. Over-redacting a person’s name in a general summary may be harmless; over-redacting dosage, date, or error-code text may change the answer. Set category-specific policies and review bands instead of one universal threshold.
Add end-to-end assertions. Capture the exact serialized request immediately before transport and scan it again with an independent rule set. Verify that raw fixtures do not appear in request logs, retry queues, traces, exception messages, caches, or model outputs. The same discipline used in a self-hosted evaluation gate can make privacy checks a release condition rather than a manual promise.
Finally, run reconstruction tests. Give reviewers only the transformed prompt and ask whether a person can still be singled out using the remaining details. This does not prove anonymity, but it catches failures that entity-level metrics miss.
Log safely without losing operational visibility
Redaction code can become a new leakage point if it logs the original text, matched substring, or reversible mapping. Production logs should normally contain:
- a request-safe correlation ID;
- redaction policy and detector versions;
- counts by entity category;
- actions taken, such as replaced, generalized, or blocked;
- latency, error class, and retry outcome;
- a coarse risk decision;
- no raw prompt, matched value, replacement map, or credential.
Separate privacy audit events from application debugging. Restrict access, define retention, and test deletion. If a temporary quarantined sample is essential for investigating a detector failure, require an explicit workflow, minimize the excerpt, encrypt it, record access, and expire it automatically.
Telemetry libraries, HTTP clients, and exception trackers may record request bodies by default. Inspect them rather than assuming your application logger is the only copy. Streaming, retries, dead-letter queues, and fallback providers also need the same sanitized payload. Never fall back to the raw prompt because the redaction service is unavailable; fail closed for high-risk routes or use a reduced local rule set whose limitations are documented.
For agent systems, tool arguments and tool results deserve special attention. The MCP security checklist explains how least-privilege tools and approval boundaries reduce the amount of sensitive data that reaches the model in the first place.
Use a production checklist and fail closed
Before enabling an LLM-backed workflow, verify the following:
- Every prompt source and downstream destination is mapped.
- Allowed fields are constructed explicitly rather than copied wholesale.
- PII, secret, and organization-specific categories have documented actions.
- Detection combines schema controls, deterministic rules, contextual methods, and custom terms.
- Redaction runs before the first untrusted or external boundary.
- Typed placeholders preserve only the relationships the task needs.
- Reversible mappings and keys are stored outside prompts and telemetry.
- Evaluation covers languages, formats, false positives, misses, and reconstruction risk.
- The final serialized request is scanned in an automated test.
- Logs, traces, retries, caches, and error reports contain no raw sensitive values.
- Detector failure has a defined fail-closed or approved degraded behavior.
- Policies, detectors, dependencies, and evaluation fixtures have version owners.
Re-run the evaluation when the input format, supported language, detector, extraction library, prompt assembly, model workflow, or logging stack changes. Review samples of blocked and redacted traffic through an approved process, then use those findings to expand fixtures.
Redaction is one layer, not permission to send every remaining field. Pair it with data minimization, short retention, access controls, provider configuration, and a clear purpose for each model call. If an application cannot explain why a field is needed, the safer transformation is usually to omit it.
For the surrounding controls, see the LLM data retention checklist and the multi-tenant RAG security guide.
Frequently asked questions
Is hashing PII enough before sending it to an LLM API?
Not always. Unsalted hashes of predictable values, such as phone numbers or common email addresses, may be guessable, and a stable hash can link activity across requests. Use a scoped keyed transformation when equality must be preserved, and remove the value when it is not needed.
Should PII redaction happen in the browser or on the server?
Place it before the first boundary that must not receive raw data. Browser-side redaction can reduce exposure, but server-side enforcement is still useful because clients can be modified or bypassed. High-risk systems often use both, with the server as the policy enforcement point.
Can an LLM redact PII from its own prompt?
It can transform text, but it cannot prevent the initial disclosure because the raw prompt has already reached the model provider. Perform the first pass locally or inside an approved service boundary before the API request.
How do I know whether the redaction is good enough?
Measure recall and precision by category on representative fixtures, then add end-to-end checks on the final serialized request. Also test whether remaining combinations of details can identify a person. There is no single threshold that fits every workflow; set stricter failure behavior for credentials and high-impact identifiers.