Confidential Information Exclusion Audit Prompt Template

This prompt is designed for security, privacy, and compliance engineers who need a second-layer semantic audit on AI-generated text. It acts as a model-graded redaction compliance check, producing a structured report that flags potential PII, API keys, credentials, and other confidential entities. Use it as a post-generation gate in any pipeline where data leakage is a regulatory or business risk—for example, before logging a model response, sending a customer email, or returning an API payload to a third-party system.

This is not a replacement for deterministic regex or NER scanners. Those tools are fast, predictable, and essential for catching well-formed patterns like credit card numbers or email addresses. This prompt complements them by catching context-dependent leaks that pattern matchers miss: an API key embedded in a code snippet without a standard prefix, a person's name combined with their medical condition in a summary, or a password accidentally echoed in a troubleshooting response. Deploy this audit after deterministic scanners have run, and treat its findings as high-signal alerts that require human review or automated redaction before the output proceeds.

Do not use this prompt as your only defense. It is a probabilistic semantic layer, not a cryptographic guarantee. It can miss obfuscated secrets, produce false positives on benign text that resembles confidential data, and vary in sensitivity across model versions. Always pair it with deterministic scanning, and for regulated domains (HIPAA, PCI-DSS, GDPR), require human review of flagged outputs before they leave your system. Wire this prompt into your logging and alerting infrastructure so that every flag generates an audit trail with the original text, the model's findings, and the disposition decision.

This template provides the core instruction set for an LLM to act as a security auditor. Its job is to scan a provided text for potential confidential information, including PII, secrets, and internal data, and produce a structured report. The prompt is designed to be strict, preferring false positives over missed detections, and requires the model to cite its evidence. Before using this in production, you must replace the square-bracket placeholders with your organization's specific definitions, policies, and output format requirements.

textCopy
You are a security-focused text auditor. Your task is to analyze the provided text for any potential confidential information. You must be strict and err on the side of caution. If you are unsure, flag it.

Follow these steps:
1. Scan the text for the entity types defined in [CONFIDENTIAL_ENTITY_DEFINITIONS].
2. For each potential match, extract the context snippet and assess its severity based on [SEVERITY_RUBRIC].
3. If [USE_REGEX_PATTERNS] is provided, apply those patterns first as a high-precision filter.
4. Compile your findings into a single JSON object that strictly adheres to the provided [OUTPUT_SCHEMA].

[CONFIDENTIAL_ENTITY_DEFINITIONS]:
- PII: Names, addresses, phone numbers, email addresses, SSNs, passport numbers, driver's license numbers.
- Secrets: API keys, passwords, connection strings, private keys, tokens.
- Internal-Confidential: Internal project names, unreleased product details, financial figures, strategic plans.

[SEVERITY_RUBRIC]:
- HIGH: Direct exposure of secrets or highly sensitive PII (e.g., SSN, password).
- MEDIUM: Exposure of personal contact information or internal financial data.
- LOW: Vague reference to an internal project or a single piece of non-sensitive PII.

[USE_REGEX_PATTERNS]:
- PII_EMAIL: \b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Z|a-z]{2,}\b
- SECRET_KEY: \b(sk-[A-Za-z0-9]{32,})\b

[OUTPUT_SCHEMA]:
{
  "audit_result": {
    "contains_confidential_info": boolean,
    "findings": [
      {
        "entity_type": "PII" | "Secret" | "Internal-Confidential",
        "severity": "HIGH" | "MEDIUM" | "LOW",
        "matched_pattern": "string or null",
        "context_snippet": "string of the text surrounding the match",
        "rationale": "brief explanation of why this was flagged"
      }
    ],
    "summary": "a one-sentence summary of the findings"
  }
}

[INPUT]:
{{user_input_text}}

To adapt this for your application, replace the content inside the [CONFIDENTIAL_ENTITY_DEFINITIONS], [SEVERITY_RUBRIC], and [OUTPUT_SCHEMA] placeholders with your organization's specific data classification policies. The [USE_REGEX_PATTERNS] section is optional but highly recommended for high-precision detection of structured secrets. For a production implementation, you would inject the [INPUT] programmatically and validate the model's response against the [OUTPUT_SCHEMA] before logging the result. If the output fails schema validation, you should implement a retry mechanism with a simplified version of this prompt, or escalate to a human review queue, especially for HIGH severity findings.

This prompt is designed to be called as a post-generation safety gate within a data processing pipeline, not as a standalone chat interaction. The typical integration pattern is: (1) an upstream system or model generates text, (2) this prompt receives the text as [INPUT] along with a [CONFIDENTIAL_ENTITY_LIST] and [SEVERITY_THRESHOLD], and (3) the structured JSON output is parsed by application code to decide whether to block, redact, or route the original text for human review. Because the prompt itself handles the detection logic, your application code should be thin: parse the JSON, check the overall_severity field, and execute a pre-defined action based on a configured threshold. Do not use this prompt for real-time chat moderation where latency is critical; it is optimized for thoroughness over speed.

The implementation harness must handle validation, retries, and logging. First, validate the model's JSON output against a strict schema that requires overall_severity (an enum of NONE, LOW, MEDIUM, HIGH, CRITICAL), a findings array with entity_type, context_snippet, and severity fields, and a redaction_recommendation boolean. If validation fails, implement a retry loop (maximum 2 retries) by appending the validation error to the [CONSTRAINTS] field and re-invoking the prompt. Log every invocation—including the original text hash, the model's raw output, and the final validated result—to an immutable audit store. For high-severity findings, trigger a human review queue that presents the original text, the detected snippet, and the model's recommendation side-by-side.

For model selection, prefer a model with strong instruction-following and structured output capabilities, such as gpt-4o or claude-3.5-sonnet. The prompt's reliance on regex patterns and named entity recognition (NER) means it benefits from models with large context windows that can ingest the full [CONFIDENTIAL_ENTITY_LIST] without truncation. To reduce latency and cost, cache the system prompt and the entity list as a reusable prefix. The [INPUT] text should be the only variable payload. If your application processes high volumes, batch the inputs but ensure each batch item receives its own prompt invocation to prevent cross-contamination of findings. Finally, avoid wiring this prompt directly to an end-user-facing feature without the validation and human-review circuit breakers; a false negative in this workflow can lead to a data leak incident.