PII Redaction Prompt Before Tool Dispatch

This prompt is for security engineers building an agent gateway that must intercept and sanitize tool calls in real time. The job-to-be-done is a pre-flight redaction step: an AI agent has generated tool arguments that may contain live personally identifiable information (PII) from user sessions, and those arguments must be scrubbed before the payload is dispatched to a downstream API, database, or third-party service. The reader is responsible for preventing data exfiltration at the tool interface layer, not for cleaning up logs after the fact. This prompt assumes the agent's generated JSON or string arguments are structurally valid but may contain names, email addresses, phone numbers, government identifiers, or financial account numbers that must be replaced with typed placeholders while preserving the exact structure the receiving tool expects.

Use this prompt when the agent operates inside a trusted boundary with access to raw user data, but the tool it calls sits outside that boundary and should only receive de-identified payloads. The prompt is designed to be wired into a dispatch middleware that intercepts every tool call, applies the redaction, and then forwards the sanitized arguments. It is not a general-purpose PII scanner for free-text documents, nor is it a post-hoc log scrubber for audit trails. The prompt expects a structured input containing the original tool arguments and a configurable list of PII categories to redact, and it must return a structurally identical payload with detected entities replaced by typed placeholders such as [EMAIL_ADDRESS] or [PHONE_NUMBER]. The redaction must be deterministic enough to pass automated validation checks that compare the output schema against the input schema and verify that no known PII patterns remain.

Do not use this prompt when the tool itself requires real PII to function—for example, when calling a payment processor that needs a real credit card number or an identity verification service that requires a government ID. In those cases, the tool boundary is the compliance boundary, and redaction would break functionality. Do not use this prompt as a replacement for proper data access controls, encryption in transit, or API-level authentication. It is a defense-in-depth measure, not a primary security control. Before deploying, validate the prompt against a golden dataset of tool arguments containing known PII across multiple categories, measure both recall (did it catch all PII?) and false-positive suppression (did it leave non-sensitive terms alone?), and implement a human review step for any redacted payloads that fail structural integrity checks before they are released to production.

This prompt template instructs the model to act as a stateless PII redaction engine. It receives a raw tool input payload and a configurable list of PII categories to detect. The model must output only a valid JSON object containing the sanitized payload and a redaction map—no explanations, no conversational text. The template uses square-bracket placeholders for all variable inputs, making it ready to drop into an agent gateway or pre-dispatch middleware layer.

textCopy
SYSTEM:
You are a stateless PII redaction engine. Your only job is to sanitize tool inputs before they are sent to external APIs.

INPUT:
- RAW_PAYLOAD: [RAW_PAYLOAD]
- PII_CATEGORIES_TO_REDACT: [PII_CATEGORIES]
- REDACTION_STYLE: [REDACTION_STYLE]
- EXEMPTION_LIST: [EXEMPTION_LIST]

RULES:
1. Scan every string field in RAW_PAYLOAD for PII matching the specified categories.
2. Replace each detected PII instance with a typed placeholder using the format: <[CATEGORY]_[INDEX]>.
3. Do NOT redact terms on the EXEMPTION_LIST, even if they match a PII pattern.
4. Preserve all JSON structure, keys, numbers, booleans, and nulls exactly as received.
5. Output ONLY a valid JSON object with two fields: "sanitized_payload" and "redaction_map".
6. The "redaction_map" must map each placeholder to its original value.
7. If no PII is found, return the original payload unchanged and an empty redaction map.

OUTPUT_SCHEMA:
{
  "sanitized_payload": <original JSON structure with PII replaced>,
  "redaction_map": {
    "<PLACEHOLDER>": "<original_value>",
    ...
  }
}

CONSTRAINTS:
- Do not add, remove, or reorder keys.
- Do not alter non-string values.
- Do not explain your decisions.
- Do not wrap the output in markdown fences.

To adapt this template, replace the square-bracket placeholders with your runtime values. [RAW_PAYLOAD] should be the serialized JSON string of the tool's input arguments. [PII_CATEGORIES] is a comma-separated list such as EMAIL, PHONE, SSN, CREDIT_CARD, IP_ADDRESS. [REDACTION_STYLE] controls the placeholder format—options include TYPED (e.g., <EMAIL_1>), HASHED (e.g., sha256::abc123), or MASKED (e.g., j***@domain.com). [EXEMPTION_LIST] is a JSON array of terms that should never be redacted, such as test email addresses or internal identifiers. For high-risk production use, always validate the output against the expected schema before forwarding the sanitized payload to the downstream tool.

Before deploying this prompt, implement a post-processing validator that confirms the sanitized_payload is valid JSON, structurally identical to the input, and contains no unreplaced PII patterns. Run regression tests with a golden dataset of known PII payloads and measure recall (did we catch all PII?) and false-positive rate (did we redact non-PII terms?). For regulated data, route any payload where the redaction map is non-empty to a human review queue before tool dispatch. Never rely solely on the model's redaction decision for compliance-critical workflows.

This prompt is designed to sit inside a gateway middleware function that intercepts every tool call an agent attempts to make. The flow is: agent generates tool call → gateway intercepts → prompt redacts → gateway dispatches sanitized payload → gateway logs the mapping of placeholders to original values in a secure audit store. This architecture ensures that raw PII never leaves the trusted execution boundary and never appears in general-purpose logging systems like stdout, CloudWatch, or Datadog. The prompt itself is a secondary defense layer for context-aware PII detection that regex-based redaction misses, such as names embedded in unstructured text, addresses in non-standard formats, or PII disguised through natural language phrasing.

Validation and Retry Logic. Implement a strict JSON schema validator on the model's output to ensure it returns exactly {"tool_name": "...", "arguments": "..."}. The tool_name must match the intercepted call's original tool name, and arguments must be a valid JSON string containing the sanitized payload. If validation fails, retry the prompt once with a stronger instruction appended to the system message, such as 'Your previous output failed schema validation. Return ONLY the JSON object with tool_name and arguments fields.' If the second attempt also fails validation, block the tool call entirely and alert a human operator through your incident management pipeline. Do not fall through to the original unsanitized payload under any circumstances.

Audit Trail Requirements. The gateway must persist a mapping record for every redaction operation. Store the original value, the assigned placeholder (e.g., [PERSON_NAME_1]), the PII type detected, and a timestamp in a dedicated audit database with strict access controls. This mapping is essential for debugging, compliance, and data subject access requests. Never log this mapping to general logging systems. The audit store should be append-only with immutable records, and access should require a break-glass procedure with approval. For high-throughput systems, consider batching audit writes asynchronously but never drop a record on failure—buffer and retry until persistence succeeds.

Model Selection and Latency Budget. This prompt adds a full model inference round-trip to every tool call, so latency is a primary design constraint. Use a small, fast model optimized for classification and extraction tasks rather than a large general-purpose model. Models in the 1-8B parameter range with strong JSON mode support are appropriate. Set a strict timeout (e.g., 500ms) on the redaction call. If the model times out, treat it as a validation failure and follow the retry-then-block escalation path. For non-sensitive tool calls that don't involve user data, consider bypassing this prompt entirely based on a tool-level sensitivity classification to avoid unnecessary latency.

What to Avoid. Do not use this prompt as your only PII defense. It is a secondary, context-aware layer that complements deterministic regex-based redaction, not a replacement for it. Regex catches structured patterns like email addresses, phone numbers, and credit card numbers with near-perfect recall and zero latency. Run regex first, then pass the partially redacted text to this prompt to catch what regex missed. Also, never send the original unsanitized payload as a fallback—if the redaction pipeline fails, the tool call must be blocked, not degraded. Finally, test this prompt regularly against your organization's specific PII patterns, because general-purpose PII detection models may miss domain-specific identifiers like internal customer IDs, project codes that embed personal data, or industry-specific regulated fields.