Error Message and Stack Trace Sanitization Prompt Template

This prompt is for production engineers and SRE teams who need to prevent information leakage through model-generated error messages and stack traces. The core job is to take a raw error output—which may contain internal file paths, hostnames, environment variables, credentials, or PII—and produce a sanitized version that is safe to log, display to users, or pass to downstream systems. The reader is expected to have a raw error string and a defined set of redaction rules or categories, and they need a reliable, repeatable way to strip sensitive data without destroying the diagnostic value of the error.

Use this prompt when you have a post-generation safety net requirement: the model has already produced an error message or stack trace, and you need to scrub it before it enters logs, monitoring dashboards, or user-facing surfaces. This is not a prompt for preventing the model from generating sensitive data in the first place—that belongs to system prompt architecture and safety policy prompts. It is also not a replacement for structured logging libraries or static analysis tools that catch secrets at commit time. Instead, this prompt sits in the output pipeline, acting as a final filter for free-text error content that may contain leaked internal details. The prompt works best when paired with a validation step that checks the sanitized output against a deny-list of patterns (e.g., /home/, aws_access_key_id, 192.168.) and flags any residual leaks for human review.

Do not use this prompt for real-time streaming error sanitization where latency is critical and token-by-token redaction is required—that workflow needs a streaming guard with buffering logic. Avoid relying on this prompt as the sole defense for highly regulated environments (PCI DSS, HIPAA) without adding a human review step and an audit trail of what was redacted. The prompt is designed for batch or near-real-time processing of individual error strings, not for scanning entire log files or datasets. For those cases, pair this prompt with a batch processing pipeline that iterates over records and aggregates redaction decisions. Before deploying, test the prompt against a golden set of known-leaky error messages and measure both recall (did it catch all sensitive data?) and precision (did it over-redact and destroy useful debugging information?).

This template is the core instruction set for sanitizing error outputs. It is designed to be copied directly into your prompt management system, IDE, or orchestration layer. The prompt instructs the model to act as a security-focused post-processor, scanning a provided error payload for file paths, internal hostnames, credentials, and PII, then returning a sanitized version alongside an audit log of changes. Use this when you have a raw error string from a model or application and need a clean, safe version for logging, user display, or downstream analysis.

codeCopy
SYSTEM: You are a production security sanitizer. Your task is to analyze the provided error message and stack trace, identify sensitive information, and produce a sanitized version. You must follow the redaction rules precisely and output only the specified JSON structure.

INPUT ERROR PAYLOAD:
[ERROR_PAYLOAD]

REDACTION RULES:
- File Paths: Replace absolute paths (e.g., `/home/user/project/src/main.py`) with a token like `[REDACTED_PATH]`. Preserve relative paths or library names if they do not reveal system structure.
- Internal Hostnames & IPs: Replace internal hostnames (e.g., `db-internal.example.com`), private IPs (e.g., `10.0.0.1`, `192.168.x.x`), and non-routable addresses with `[REDACTED_HOST]`. Public domain names and public IPs can be kept.
- Credentials & Secrets: Replace any string resembling an API key, token, password, connection string, or private key with `[REDACTED_CREDENTIAL]`. Look for patterns like `key=...`, `token:...`, `-----BEGIN PRIVATE KEY-----`.
- PII: Replace email addresses, phone numbers, and physical addresses with `[REDACTED_PII]`. Do not redact generic usernames unless they are an email address.
- Stack Trace Frames: Preserve the structure of the stack trace. Redact only the sensitive parts within each frame. Do not remove entire frames unless they consist solely of redacted information.

OUTPUT SCHEMA:
{
  "sanitized_error": "The fully sanitized error string with all sensitive data replaced.",
  "redaction_log": [
    {
      "original_value": "The exact string that was redacted",
      "redaction_type": "PATH | HOST | CREDENTIAL | PII",
      "redacted_value": "The token that replaced it"
    }
  ],
  "contains_sensitive_data": true
}

CONSTRAINTS:
- If no sensitive data is found, return the original error in `sanitized_error`, an empty `redaction_log`, and set `contains_sensitive_data` to false.
- Do not alter the error message's grammar, punctuation, or non-sensitive content.
- If you are unsure whether a string is sensitive, flag it as a `POTENTIAL` finding in a separate `review_queue` array within the JSON output.

To adapt this template, replace [ERROR_PAYLOAD] with the actual error string at runtime. You can extend the REDACTION RULES list with organization-specific patterns, such as internal project codenames or specific environment variable prefixes. The OUTPUT SCHEMA is a strict contract; ensure your application's parsing logic expects this exact JSON structure. The review_queue array for uncertain findings is a critical safety valve—it allows the system to handle ambiguous cases without blocking the pipeline, routing them for human or secondary automated review instead.

This prompt is designed to be called as a post-generation safety net, sitting between the primary model's output and any downstream system—a logging pipeline, a user-facing UI, a database, or an internal Slack channel. The harness should treat the sanitization step as a blocking gate: if the prompt fails to return a valid sanitized output, the original unsanitized text must not be forwarded. The recommended integration pattern is a dedicated sanitization service or middleware function that accepts the raw error message and stack trace, calls the LLM with this prompt template, validates the response, and only then releases the cleaned output.

Validation and retry logic is critical because the sanitization prompt itself can fail. The harness must validate that the returned JSON matches the expected schema: a sanitized_error_message string, a sanitized_stack_trace string (or null), and a redactions array of objects each containing original, redacted, type, and confidence. If the response fails JSON parsing, use a retry with error feedback: send the malformed response back to the model with a message like 'Your previous response was not valid JSON. Return ONLY the JSON object with the fields sanitized_error_message, sanitized_stack_trace, and redactions.' Implement a maximum of 2 retries before escalating to a human review queue or falling back to a conservative regex-based redaction. For high-security environments, log every redaction decision with the redactions array as an audit trail, and consider adding a human approval step for any redaction with confidence below 0.85 or for type values of credential or internal_path.

Model choice and latency matter in production. This task requires strong instruction-following and JSON output reliability, but not deep reasoning. A fast model like GPT-4o-mini, Claude 3.5 Haiku, or Gemini 1.5 Flash is appropriate for most deployments. If processing streaming outputs, buffer the complete error message before calling the sanitization prompt—partial redaction on incomplete text produces false negatives. For batch processing of historical logs, run sanitization as an asynchronous job with a dead-letter queue for any output that fails validation after retries. Never cache sanitization results across different inputs, as the same error message format may contain different sensitive data on each occurrence. The most common production failure mode is the model returning a sanitized message that still contains a variant of the original sensitive data (e.g., redacting /home/prod/user but leaving /home/prod/admin). Mitigate this by running the sanitized output through a secondary regex-based scan for known patterns before release.