Error Log PII Redaction Prompt

This prompt is designed for SRE and observability engineers who need to run raw error logs through an LLM for summarization, root cause analysis, or incident postmortems without exposing personally identifiable information (PII). It instructs the model to produce a redacted error description that preserves debugging information such as stack traces, error codes, and system state while stripping user data, authentication tokens, session identifiers, and personal identifiers. The primary job-to-be-done is enabling safe AI-assisted incident analysis when logs inevitably contain customer data that should never appear in model outputs, chat histories, or downstream analysis tools.

Use this prompt when error logs may contain customer email addresses, IP addresses, request bodies with user input, or session tokens. It is appropriate for environments where logs are streamed directly from production systems into an AI pipeline, and where a human operator needs a sanitized summary to begin debugging. The prompt assumes the input has already been captured and that the operator has no practical way to manually scrub every line before analysis. It works best as a preprocessing step before the redacted output is passed to a second LLM call for summarization or root cause analysis, or before it is stored in an incident channel that multiple teams can access.

Do not use this prompt as a replacement for proper log scrubbing at the ingestion layer. If your logging pipeline can strip PII before it reaches disk, do that first—this prompt is a defense-in-depth measure, not a primary privacy control. It is also not suitable for logs containing protected health information (PHI) subject to HIPAA, where a Business Associate Agreement (BAA) and additional safeguards are required. In regulated contexts, always route redacted outputs through human review before they enter any persistent store. Finally, avoid using this prompt when the debugging task requires the PII itself—for example, when investigating a user-specific bug where the email address or session token is the only way to reproduce the issue. In those cases, keep the analysis entirely within your existing access-controlled observability tools.

This template is designed to be placed directly into your system prompt or as a pre-processing instruction before error logs reach a summarization or analysis model. It instructs the model to act as a privacy-preserving filter, replacing personal data with typed placeholders. The goal is to prevent PII leakage through AI-generated incident summaries, Slack notifications, or ticket updates while keeping enough context for an on-call engineer to diagnose the issue.

codeCopy
You are a privacy redaction engine for error logs. Your task is to sanitize the provided [ERROR_LOG] by replacing all detected Personally Identifiable Information (PII) and secrets with safe, typed placeholders. You must preserve all stack traces, error codes, timestamps, and non-PII debugging information verbatim.

### Redaction Rules
- **Email Addresses**: Replace with [REDACTED_EMAIL].
- **IP Addresses**: Replace with [REDACTED_IP].
- **Physical Addresses**: Replace with [REDACTED_ADDRESS].
- **Names**: Replace with [REDACTED_NAME].
- **Phone Numbers**: Replace with [REDACTED_PHONE].
- **API Keys, Tokens, and Secrets**: Replace with [REDACTED_SECRET] if they appear in headers, query params, or request bodies.
- **Session Tokens / JWTs**: Replace the token value with [REDACTED_TOKEN] but preserve the key name (e.g., `Authorization: Bearer [REDACTED_TOKEN]`).
- **Credit Card / Financial Account Numbers**: Replace with [REDACTED_FINANCIAL].

### Strict Constraints
- **Do not** modify or remove stack traces, exception types, or line numbers.
- **Do not** redact generic identifiers like `user_id`, `request_id`, or `trace_id` unless they contain PII.
- **Do not** summarize or rewrite the error message; only perform direct string replacement.
- If no PII is detected, return the original [ERROR_LOG] unchanged.

### Output Format
Return ONLY the fully redacted error log as a plain text block. Do not add explanations, notes, or markdown fences.

### Error Log to Redact
[ERROR_LOG]

To adapt this template, replace [ERROR_LOG] with your actual log payload at runtime. If your application has a specific PII taxonomy (e.g., GDPR-defined identifiers), add or remove entity types in the Redaction Rules list. For high-throughput systems, consider pairing this prompt with a lightweight, pre-flight regex check to skip the LLM call entirely when no known PII patterns are detected, reducing latency and cost. Always log the redaction action itself (without the raw log) for auditability.

Integrating the Error Log PII Redaction Prompt into an application requires treating it as a deterministic data processing step, not a conversational feature. The prompt should be deployed as a stateless function within your error aggregation pipeline—typically as a pre-processor before logs are written to long-term storage, indexed in observability platforms, or summarized for on-call notifications. The function receives a raw error log string as [INPUT], applies the redaction template, and returns a structured JSON object containing the redacted_description, a list of redacted_entities with their replacement tokens, and a redaction_confidence score. This output must be validated before the original log is discarded or the redacted version is surfaced to engineers.

The implementation must include a strict validation layer that checks the output schema before the redacted log is used. First, confirm that the redacted_description field is a non-empty string and that no values from the redacted_entities list appear in it (a simple substring check catches most leakage). Second, verify that each entity in the redacted_entities array contains a type, original_value, and replacement_token. Third, implement a regex-based safety net that scans the redacted_description for common PII patterns—email addresses, phone numbers, credit card numbers, JWTs, and API keys—and flags the output for human review if any match. For high-severity error channels (e.g., payment processing or authentication services), route all redacted outputs with a redaction_confidence below 0.95 to a manual review queue before the log is distributed. Model choice matters here: use a model with strong instruction-following and JSON mode support (such as GPT-4o or Claude 3.5 Sonnet) and set temperature=0 to maximize deterministic redaction behavior.

Retry logic should be conservative. If the model returns malformed JSON or fails schema validation, retry once with the same input and a stronger constraint instruction appended (e.g., 'You MUST return only valid JSON matching the exact schema'). If the retry also fails, fall back to a regex-based redaction function that masks known PII patterns and flags the log for human review. Log every redaction event—including the model used, latency, confidence score, entity types detected, and whether the output passed validation—to your observability platform. This audit trail is essential for debugging redaction failures, demonstrating compliance during security reviews, and tuning the prompt over time. Never silently drop validation failures; a log with PII is a liability, but a dropped log during an incident is an operational risk. The harness should default to surfacing the log with a warning rather than suppressing it entirely.