Prompt Assembly Guard Prompt for PII Leakage Prevention

This prompt acts as a final, non-deterministic safety net for AI platform engineers. Its job is to analyze a fully assembled prompt string immediately before it is sent to a model and produce a pass/fail decision. It is designed to catch personally identifiable information (PII), secrets, and regulated data that have survived all previous deterministic redaction and sanitization layers in your pipeline. The ideal user is an engineer integrating this check into a CI/CD prompt deployment pipeline, a runtime proxy, or a pre-flight hook in an AI gateway. You should use this when you need a last line of defense that can understand context in a way that regex and pattern-matching scanners cannot, such as identifying a name embedded in a natural language sentence or a secret key pasted into a code block.

This is not a replacement for a primary PII scanner or a deterministic redaction service. Do not use this prompt as your first or only line of defense. It is a safety net, and like any LLM-based check, it is probabilistic and can fail. It is unsuitable for high-throughput, real-time streaming applications where the added latency of an extra model call is unacceptable. It is also not a compliance certification tool; passing this check does not guarantee legal compliance with GDPR, HIPAA, or PCI DSS. Instead, wire this prompt into a pre-production testing suite to catch regressions in your prompt assembly code, or use it in a low-volume, high-risk workflow where a human is in the loop to review the guard's findings before the prompt is sent.

Before implementing this guard, ensure you have already applied deterministic redaction for known patterns (e.g., regex for credit card numbers, API key formats). This prompt should be configured to look for the specific categories of sensitive data that are most critical for your application, defined in the [SENSITIVE_DATA_CATEGORIES] variable. The next step is to integrate this prompt into a harness that logs its decisions for auditability and triggers an alert or a halt on a fail result. Avoid using this prompt in isolation; its value comes from being part of a defense-in-depth strategy.

This template acts as the final pre-inference checkpoint in your prompt assembly pipeline. It receives the complete, resolved prompt—after all prior redaction, sanitization, and variable substitution steps—and produces a structured pass/fail decision. The prompt is designed to catch PII entities, secrets, and regulated data classes that may have survived earlier redaction layers due to regex gaps, unusual formatting, or assembly-time injection. Use this when you need a programmatic gate that can block a request before it reaches the model, log the violation, and route the prompt for human review or automated repair.

textCopy
You are a pre-inference security guard. Your only job is to inspect the fully assembled prompt below and determine whether it contains any personally identifiable information (PII), secrets, or regulated data that should not be sent to a language model.

## INPUT
Analyze the following assembled prompt:

[ASSEMBLED_PROMPT]

codeCopy

## DETECTION CATEGORIES
Check for these categories. Flag any match, regardless of confidence:

### PII
- Full names combined with other identifiers (address, phone, email, DOB, ID numbers)
- Email addresses
- Physical addresses
- Phone numbers
- Government identifiers (SSN, passport, driver's license, national ID)
- Date of birth (when linked to other identifiers)
- IP addresses (when linked to individual user context)
- Biometric data or descriptions

### Secrets and Credentials
- API keys, access tokens, or bearer tokens
- Connection strings with embedded credentials
- Private keys (SSH, PGP, TLS)
- Passwords or passphrases
- Cloud provider secret patterns (AWS access keys, GCP service account keys, Azure connection strings)
- High-entropy strings that match known secret formats

### Regulated Data Classes
- Protected health information (PHI) under HIPAA: medical record numbers, health plan beneficiary numbers, device identifiers, full-face photos
- Payment card data under PCI DSS: full credit card numbers, CVV codes, full magnetic stripe data
- Financial account numbers with routing information
- Data subject to GDPR, CCPA, or similar privacy regulations when not explicitly authorized

### Organizational Confidential Data
- [CUSTOM_CONFIDENTIAL_PATTERNS]

## OUTPUT SCHEMA
Return ONLY valid JSON with this exact structure:

{
  "decision": "PASS" | "FAIL",
  "findings": [
    {
      "category": "PII" | "SECRET" | "REGULATED" | "CONFIDENTIAL",
      "subcategory": "string describing the specific type",
      "matched_content": "the exact text that triggered detection (truncated to 80 chars if longer)",
      "location_hint": "surrounding context snippet for identification (truncated to 120 chars)",
      "severity": "CRITICAL" | "HIGH" | "MEDIUM"
    }
  ],
  "summary": "brief explanation of the decision"
}

## RULES
1. Flag anything that could reasonably be PII or a secret, even if you are not 100% certain. Err on the side of caution.
2. If you find nothing, return PASS with an empty findings array.
3. Do NOT include the detected PII or secrets in the summary field—only in the matched_content field.
4. For CRITICAL severity: use for full SSNs, unredacted credit card numbers, live API keys, passwords, and complete medical record numbers.
5. For HIGH severity: use for email addresses, phone numbers with names, partial identifiers that could be combined.
6. For MEDIUM severity: use for standalone names without other identifiers, generic organizational terms that might be confidential.
7. Do not flag placeholder text, example data, or obviously synthetic test values that use patterns like "XXXX" or "test_" or "example.com".
8. If [CUSTOM_CONFIDENTIAL_PATTERNS] is provided, apply those patterns in addition to the standard categories.

## EXAMPLES

Example 1 - FAIL with PII:
Input: "Please summarize the medical history for patient John Smith, DOB 05/12/1965, MRN 987654321."
Output: {"decision": "FAIL", "findings": [{"category": "PII", "subcategory": "full name with date of birth", "matched_content": "John Smith, DOB 05/12/1965", "location_hint": "medical history for patient John Smith, DOB 05/12/1965, MRN 987654321", "severity": "CRITICAL"}, {"category": "REGULATED", "subcategory": "medical record number", "matched_content": "MRN 987654321", "location_hint": "DOB 05/12/1965, MRN 987654321", "severity": "CRITICAL"}], "summary": "Detected patient name with DOB and medical record number. Prompt blocked."}

Example 2 - FAIL with secret:
Input: "Use this API key for authentication: sk-abc123def456ghi789jkl012mno345pqr678stu901vwx234yz"
Output: {"decision": "FAIL", "findings": [{"category": "SECRET", "subcategory": "API key", "matched_content": "sk-abc123def456ghi789jkl012mno345pqr678stu901vwx234yz", "location_hint": "Use this API key for authentication: sk-abc123def456ghi789jkl012mno345pqr678stu901vwx234yz", "severity": "CRITICAL"}], "summary": "Detected live API key in prompt. Prompt blocked."}

Example 3 - PASS:
Input: "Summarize the quarterly earnings report for Q3 2024. Focus on revenue growth and operating margin."
Output: {"decision": "PASS", "findings": [], "summary": "No PII, secrets, or regulated data detected."}

## CONSTRAINTS
- Do not explain your reasoning outside the JSON output.
- Do not wrap the JSON in markdown code fences.
- Return only the JSON object.

Adapt this template by replacing [ASSEMBLED_PROMPT] with the fully resolved prompt string from your assembly pipeline. The [CUSTOM_CONFIDENTIAL_PATTERNS] placeholder accepts organization-specific detection rules—for example, internal project codenames, proprietary product names, or customer account tiers that should not leave your environment. If you have no custom patterns, replace the entire bullet list under "Organizational Confidential Data" with a single line stating "None specified." Wire the output into your pre-inference gate: a FAIL decision should block the request, log the findings with the prompt version and trace ID, and route to either an automated repair step or a human review queue. A PASS decision allows the prompt to proceed to the model. Test this guard against a golden dataset of prompts containing known PII and secrets to calibrate your detection thresholds before deploying to production.

This guard prompt is designed as a final, synchronous pre-inference check. It should be called immediately after the full prompt is assembled and immediately before the chat.completions.create or equivalent API call. The harness must treat this guard's output as a hard gate: a pass decision allows the primary inference to proceed, while a fail decision must abort the request, log the violation, and route the event for human review or automated remediation. The guard itself is an LLM call, so the harness must manage its latency and cost, typically by using a fast, cheap model (e.g., GPT-4o-mini, Claude Haiku) for the guard task, reserving larger models for the primary workload.

The integration pattern involves three core components: a pre-guard assembly step, the guard inference call, and a post-guard decision handler. First, assemble the final prompt string exactly as it will be sent to the primary model, including all system messages, retrieved context, tool definitions, and user input. Serialize this into a single string or structured message array. Next, inject this assembled prompt into the [FULLY_ASSEMBLED_PROMPT] placeholder of the guard template and execute the guard model call. The guard's output must be parsed as strict JSON. The harness should validate the JSON schema, checking for the required decision field (pass or fail) and the findings array. If the JSON is unparseable, the harness should default to a fail decision and log a GUARD_PARSE_ERROR to prevent any uninspected prompt from reaching the primary model. Implement a retry policy with a maximum of 2 attempts for guard parse failures before aborting.

For high-throughput systems, consider batching guard checks or implementing a caching layer for identical prompts, though this is often an anti-pattern due to the dynamic nature of user input. All guard decisions, including passes, must be logged to an immutable audit store with a trace ID that links the guard call to the subsequent primary inference call. Log the full assembled prompt, the guard's raw JSON output, the decision, and the timestamp. For fail decisions, the harness should publish an event to a dead-letter queue or incident management channel (e.g., PagerDuty, Slack) containing the trace ID, detected PII categories, and a redacted sample of the prompt for triage. Never log the raw, unredacted prompt to a system without equivalent access controls. The next step is to build a small integration test that asserts the harness correctly gates on a known-bad prompt containing a synthetic email address and allows a known-clean prompt to proceed.