How to reduce sensitive data in LLM prompts

Reducing sensitive data in prompts is not one task. It is a small set of repeated decisions made at the point where a prompt is built. The goal of this guide is to show what each decision looks like for common workflows — and to be honest about the parts that masking cannot solve.

The shape of the problem

A prompt usually carries three things: an instruction, some context, and (often) a piece of user-provided text. Sensitive data leaks into the context and into the user-provided text. The instruction is rarely the issue.

Most of the wins come from reducing what ends up in the context. Masking handles the remainder — specifically the recognized entities that you cannot avoid including.

Workflow 1: Summarization

Problem. A support agent pastes a customer email into a prompt to get a one-sentence summary.

Naive prompt.

Summarize the following customer email in one sentence:

From: Jane Doe <jane.doe@example.com>
Phone: +47 900 12 345
Account: AC-91823

"I have been trying to reach you about my subscription for two weeks…"

Reduced prompt after masking.

Summarize the following customer email in one sentence:

From: <PERSON_1> <EMAIL_1>
Phone: <PHONE_1>
Account: <ID_1>

"I have been trying to reach you about my subscription for two weeks…"

Why it works. The summary task does not depend on the actual name or contact data. The model produces a faithful summary; placeholders are rehydrated on the way back so the agent still sees Jane's name in the result.

Limitation. The free-text body is unchanged. If the body itself contains personal data, that is not reduced by masking alone. Trim or paraphrase upstream when feasible.

Workflow 2: Drafting a reply

Problem. The application drafts a personalized reply to a customer.

Reduced prompt after masking.

Write a polite reply to <PERSON_1> at <EMAIL_1>.
Tone: warm, professional. Length: 4 sentences.
Context: their order <ID_1> shipped yesterday.

Why it works. The model writes a draft with placeholders; rehydration restores the real name, email and order ID before the reply reaches the app. The provider sees no real identifier.

Workflow 3: Customer-support classification

Problem. Classify an inbound ticket into a small set of categories.

Reduction strategy. Send only the subject and the first sentence of the body. Mask recognized entities in what remains. Most classification quality comes from the first 200–300 characters; the rest is often unnecessary.

Workflow 4: Internal copilots

Problem. An internal assistant answers questions about company data, often by pulling records into the prompt.

Reduction strategy. Retrieve only the columns the question needs. Mask names, emails and identifiers in the retrieved rows. Cap the number of rows. Send the masked context and let the model reason; rehydrate on the way back.

Workflow 5: Extraction

Problem. Pull structured fields out of a document.

Reduction strategy. Extraction is the case where the sensitive value is the answer. Two patterns help: extract on a redacted copy and re-link locally if the value is already known, or restrict extraction to non-sensitive fields and handle the rest with deterministic parsing.

Honest limitations

Masking protects supported values. It does not:

• Catch arbitrary user-defined entities or context-specific identifiers your team uses internally.
• Replace data minimization upstream of the prompt.
• Change what a provider may retain under their current terms.
• Defend against prompt injection or jailbreaks.
• Replace broader governance, policy or security review.

Where to go next

See the GDPR and LLMs pillar for the framing, PII Masking for the currently supported entity set, and First request for a working example.