Customer Data Masking Prompt for Support Agents

This prompt is designed for support platform engineers who need to sanitize customer-submitted tickets before they enter an AI pipeline. Its job is to produce a masked version of a customer query that preserves the original intent, sentiment, and technical details while replacing personally identifiable information (PII) with safe placeholder tokens. Use this prompt as a pre-processing gate before routing, summarization, or auto-reply generation. It assumes the input is unstructured text from a support form, email, or chat transcript.

The ideal implementation point is immediately after ticket ingestion and before any AI model processes the text. Wire this prompt into your middleware so that downstream systems—whether they perform intent classification, sentiment analysis, or automated response drafting—never see raw customer identifiers. The prompt expects a single text block as input and returns a masked version with consistent placeholder tokens like [NAME_1], [EMAIL_1], or [PHONE_1]. These tokens maintain referential integrity across the text, so repeated mentions of the same entity receive the same placeholder index.

Do not use this prompt for structured database records, legal documents where redaction must be certified, or scenarios where the downstream system requires the original PII for identity verification. This prompt is a best-effort masking layer, not a cryptographic redaction tool. If your workflow requires auditable redaction with chain-of-custody documentation, route through a dedicated redaction service and use this prompt only as a secondary safety net. For high-risk regulated domains like healthcare or finance, always pair this prompt with human review and a validation step that checks for residual PII before the masked text reaches any model.

This prompt template is designed to be placed in your system instructions for an AI support agent that handles customer tickets. It instructs the model to produce a masked version of the user's query, replacing personally identifiable information (PII) with typed placeholders while preserving the semantic intent, sentiment, and technical details needed for downstream classification, routing, and response generation. The template uses square-bracket placeholders that you must replace with your organization's specific PII categories, masking rules, and output format requirements before deployment.

textCopy
You are a data masking engine for customer support tickets. Your only job is to produce a masked version of the user's input.

## INPUT
[USER_QUERY]

## MASKING RULES
Replace all detected instances of the following PII categories with typed placeholders exactly as shown:
- Full names → [PERSON_NAME]
- Email addresses → [EMAIL_ADDRESS]
- Phone numbers → [PHONE_NUMBER]
- Physical addresses → [PHYSICAL_ADDRESS]
- Payment card numbers → [PAYMENT_CARD]
- Account numbers → [ACCOUNT_NUMBER]
- IP addresses → [IP_ADDRESS]
- Government IDs (SSN, passport, driver's license) → [GOVERNMENT_ID]

## CONSTRAINTS
1. Preserve all non-PII text verbatim, including technical error messages, product names, timestamps, and ticket numbers.
2. Preserve the original sentence structure, punctuation, and line breaks.
3. Do not summarize, rephrase, or correct the user's text.
4. If no PII is detected, return the original input unchanged.
5. Do not add explanations, apologies, or commentary.
6. Mask partial matches (e.g., a first name alone still becomes [PERSON_NAME]).

## OUTPUT FORMAT
Return ONLY the masked text with no additional output.

## EXAMPLES

Input: "Hi, my name is Sarah Chen and my email is sarah.chen@example.com. My order #ORD-8821 hasn't arrived. I live at 742 Evergreen Terrace, Springfield."
Output: "Hi, my name is [PERSON_NAME] and my email is [EMAIL_ADDRESS]. My order #ORD-8821 hasn't arrived. I live at [PHYSICAL_ADDRESS]."

Input: "The API keeps returning a 500 error when I call /v1/orders from 192.168.1.100. My account ID is ACC-4492."
Output: "The API keeps returning a 500 error when I call /v1/orders from [IP_ADDRESS]. My account ID is [ACCOUNT_NUMBER]."

Input: "Can you help me reset my password? I can't log in."
Output: "Can you help me reset my password? I can't log in."

## RISK LEVEL
[HIGH] — This prompt handles regulated PII. Human review of the masking output is required before production deployment. Validate masking recall against a labeled PII test set.

To adapt this template, replace [USER_QUERY] with your actual input variable from the support ticketing system. Adjust the masking rules list to match your organization's data classification policy — add categories like date of birth, health information, or biometric data if your support domain handles them. Update the examples to reflect real ticket patterns from your system; include at least one example with no PII to prevent over-masking. Set [RISK_LEVEL] to HIGH, MEDIUM, or LOW based on your compliance requirements, and configure downstream validation to reject outputs that still contain regex-detectable PII patterns. Before shipping, run this prompt against a golden dataset of 100+ real tickets with known PII labels and measure both recall (did we catch all PII?) and precision (did we mask benign text?).

Integrating this prompt into a support agent application requires treating it as a deterministic preprocessing step before any LLM reasoning or retrieval occurs. The masking prompt should sit immediately after user input is received and before it touches any downstream model, vector database, or logging system. This placement ensures that PII never enters a context window where it could be memorized, leaked through a tool call, or written to an observability trace. In a typical support platform architecture, you would insert this prompt as a synchronous API call within the ticket ingestion webhook handler or the agent's on_user_message middleware. The input to the prompt is the raw customer message; the output is a JSON object containing the original text, a masked version, and a structured array of detected entities with their positions and replacement placeholders. Store both versions in your ticket record—the masked text for AI processing and the original in an encrypted, access-controlled field for authorized human review only.

Validation must happen at two levels. First, validate the model's JSON output against a strict schema that requires original_text, masked_text, and entities as an array of objects with type, original, masked, start_char, and end_char fields. Reject any response that fails to parse or omits required fields. Second, run a post-processing recall check: extract all masked tokens from the output and verify that none of them appear in the masked_text field. If a masked entity is found in the masked text, the redaction failed and the message must be blocked from downstream processing. For high-precision environments, implement a regex-based fallback scanner that runs independently of the LLM to catch common patterns (email addresses, phone numbers, credit card numbers) that the model might miss. If the regex scanner finds PII that the model did not flag, log the discrepancy and route the ticket to a human review queue rather than silently passing tainted data forward.

Model choice matters for both cost and reliability. This prompt works well with fast, inexpensive models like GPT-4o-mini, Claude Haiku, or Gemini Flash because the task is a constrained extraction problem, not a reasoning-intensive one. Avoid using the same model instance for both masking and the downstream support task—separation of concerns reduces the risk of prompt injection and makes it easier to audit which step failed. Set temperature to 0 for deterministic outputs, and implement a retry loop with exponential backoff (max 3 attempts) if the response fails schema validation. For high-throughput support systems processing thousands of tickets per hour, consider batching multiple messages into a single masking request to reduce API overhead, but ensure each message's entities are tracked independently. Log every masking operation with a correlation ID that ties the original ticket, the masked output, the model version, and the validation result together for auditability. If the masking step fails after all retries, the ticket must be quarantined—never fall back to processing unmasked customer data through the AI pipeline.