Sensitive Data Exposure Detection Prompt

This prompt is for security engineers and AI platform architects who need to embed runtime sensitive data exposure detection directly into an AI assistant's system instructions. The job-to-be-done is transforming the assistant into a monitoring layer that inspects its own outputs and internal reasoning traces for PII, credentials, API keys, session tokens, and confidential business data before those artifacts reach end users or external systems. Use this when you need exposure alerts with data classification, exposure context, and containment recommendations without deploying a separate scanning service. This prompt belongs in the system prompt architecture of any AI product that handles user data, generates responses from retrieved documents, or operates in regulated environments where data leakage carries compliance risk.

The ideal deployment context is a production AI system where the assistant has access to sensitive source material—retrieved documents, user-provided inputs, internal knowledge bases, or tool outputs that may contain credentials or personal data. The prompt works as a policy layer that runs before final output delivery, catching exposure events that static pre-processing or post-processing scanners might miss because they lack access to the model's reasoning chain. You should wire this prompt into the system instructions alongside your other behavioral policies, not as a standalone service. The detection logic must have access to the assistant's draft response and any retrieved context that informed it. Without that access, the prompt cannot inspect what the model is about to emit.

Do not use this prompt as your only data loss prevention control. It is a defense-in-depth layer, not a replacement for input sanitization, output scanning, or access controls. The prompt cannot catch exposure that occurs in tool calls the model makes to external services, nor can it prevent the model from including sensitive data in structured outputs that bypass the text inspection path. It also adds latency and token cost to every response, so evaluate whether your threat model justifies continuous inspection or whether sampling-based audit is sufficient. For high-throughput systems, consider using this prompt on a percentage of traffic or only when the assistant accesses high-risk data sources.

Before deploying, you must test this prompt against a curated set of exposure scenarios: PII in retrieved documents, credentials in user inputs, API keys in generated code samples, session tokens in debugging output, and confidential business data in summaries. Each scenario should have a known expected detection outcome. Run these tests across every model you intend to use, because detection sensitivity varies significantly between model families and versions. If your application operates in a regulated domain, pair this prompt with a human review step for any detected exposure event and maintain audit logs of detection decisions, overrides, and containment actions taken.

This prompt template is designed to be inserted directly into your assistant's system instructions. It transforms the model into a runtime security monitor that scans its own inputs and outputs for sensitive data, including PII, credentials, and confidential content. The prompt uses square-bracket placeholders so you can adapt the data classifications, risk thresholds, and output schema to your organization's specific data handling policies without rewriting the core detection logic.

textCopy
You are a security-focused AI assistant with an embedded sensitive data exposure monitor. Your primary task is to fulfill user requests, but you must simultaneously scan all text you process—including user inputs, retrieved documents, tool outputs, and your own generated responses—for potential sensitive data exposure.

## Data Classification Policy
Classify any detected sensitive data into one of the following categories based on [DATA_CLASSIFICATION_SCHEMA]:
- **PII**: Names, email addresses, phone numbers, physical addresses, government IDs, dates of birth, or any combination that could identify an individual.
- **Credentials**: API keys, passwords, tokens, connection strings, private keys, or authentication secrets.
- **Financial**: Credit card numbers, bank account details, routing numbers, or financial account identifiers.
- **Health**: Medical record numbers, diagnoses, treatment details, or any protected health information.
- **Confidential**: Internal project names, unreleased product details, proprietary algorithms, or documents marked confidential per [CONFIDENTIALITY_MARKERS].
- **Legal**: Attorney-client privileged communications, litigation details, or regulatory findings.

## Detection Rules
1. Scan every message, document, tool output, and generated text before it is sent to the user.
2. Flag partial matches and obfuscated data (e.g., `user [at] domain [dot] com`, base64-encoded secrets).
3. Do not include the actual sensitive value in your detection report. Instead, provide the data type, location context, and a redacted indicator.
4. If sensitive data appears in retrieved context or tool outputs, flag it even if you did not generate it.
5. Apply stricter scrutiny when the user role is [USER_ROLE] and the data source is [DATA_SOURCE_TYPE].

## Output Schema for Exposure Alerts
When sensitive data is detected, append a structured alert block to your response using the exact format below. If no exposure is detected, do not include the alert block.

```json
{
  "exposure_alert": {
    "alert_id": "string, unique identifier for this alert",
    "severity": "CRITICAL | HIGH | MEDIUM | LOW",
    "category": "PII | CREDENTIALS | FINANCIAL | HEALTH | CONFIDENTIAL | LEGAL",
    "detection_location": "user_input | retrieved_context | tool_output | generated_response",
    "data_type_detected": "string, type of data without the actual value (e.g., 'email address', 'API key')",
    "context_snippet": "string, surrounding text with the sensitive portion replaced by [REDACTED]",
    "recommended_action": "REDACT_AND_CONTINUE | BLOCK_RESPONSE | ESCALATE_FOR_REVIEW | LOG_ONLY",
    "confidence": 0.0_to_1.0
  }
}

Severity Definitions

• CRITICAL: Plaintext credentials, full credit card numbers, or unredacted government IDs. Block the response and escalate immediately.
• HIGH: Complete PII records, health information, or confidential documents. Redact before responding and log the event.
• MEDIUM: Partial PII, internal project names without context, or potential credential patterns. Log and continue with caution.
• LOW: Isolated data points that could become sensitive in combination. Log for audit review.

Constraints

• Never output the actual sensitive value in your alert.
• If the user explicitly requests sensitive data exposure (e.g., testing or red-teaming), follow the [RED_TEAM_POLICY] and log the attempt without exposing real data.
• When confidence is below [CONFIDENCE_THRESHOLD], flag as LOW severity and recommend LOG_ONLY.
• If multiple categories apply, create separate alert entries for each.
• Do not let exposure detection degrade the quality of your primary response. Detection must be additive, not disruptive.

Examples

[FEW_SHOT_EXAMPLES]

Escalation Path

If severity is CRITICAL or HIGH, follow the escalation procedure defined in [ESCALATION_POLICY] before delivering any output to the user.

To adapt this template for your environment, replace the square-bracket placeholders with your organization's specific policies. The [DATA_CLASSIFICATION_SCHEMA] should reference your internal data taxonomy. [CONFIDENCE_THRESHOLD] should be tuned based on your tolerance for false positives—start at 0.7 and adjust after reviewing production logs. The [FEW_SHOT_EXAMPLES] placeholder is critical for model performance; provide at least three examples showing correct detection with redacted context snippets and appropriate severity assignments. Before deploying, validate that the output schema is parseable by your logging infrastructure and that the alert block does not interfere with your application's primary response parsing. For high-risk deployments handling real PII or credentials, always pair this prompt with a human review step for CRITICAL and HIGH severity alerts until you have established trust in the detection accuracy.

This prompt is designed to operate as a runtime guardrail within a larger AI application, not as a standalone chat interaction. It should be invoked programmatically after the model generates a response but before that response is returned to the user or written to a log. The harness wraps the model call, captures the output, and then runs this detection prompt as a secondary evaluation step. The detection prompt itself should be treated as a high-priority system instruction that cannot be overridden by user context, and it must have access to the full generated content and any relevant conversation history to assess exposure risk accurately.

Wiring the prompt into an application requires a structured pipeline: (1) Capture the candidate output from the primary model. (2) Construct the detection request by injecting the candidate output into the [CONTENT_TO_SCAN] placeholder and any relevant conversation context into [CONVERSATION_CONTEXT]. (3) Call a fast, cost-efficient model (such as a smaller Claude or GPT model) with this detection prompt and enforce a strict JSON output schema using the model's native JSON mode or function-calling API. (4) Parse the response and validate the exposure_detected boolean, the classifications array, and the severity field against an expected schema. If the JSON is malformed, retry once with a repair prompt that includes the raw output and schema constraints. (5) If exposure_detected is true and severity is high or critical, block the response, log the full detection payload, and route to a human review queue. For medium severity, consider redacting the sensitive spans using the exposed_spans field before returning the response. For low severity, log the event and allow the response through with a flag for later audit.

Logging and observability are critical because this prompt is a compliance control. Every detection run must produce a structured audit record that includes: the detection prompt version, the model used for detection, the raw detection output, the final action taken (blocked, redacted, allowed), a timestamp, and a unique correlation ID linking back to the original user request. These records should be stored in a tamper-evident log separate from general application logs. For high-risk deployments, implement a sampling-based human review where a percentage of low and medium severity detections are manually reviewed to calibrate the detector's precision and recall. Additionally, build an eval harness that tests the detection prompt against a golden dataset of known PII, credentials, API keys, and confidential business data embedded in realistic response formats. Measure false-positive rates on clean responses and false-negative rates on deliberately seeded exposures. Run this eval suite on every prompt change before deployment, and gate releases on passing predefined thresholds. Finally, never rely solely on this prompt for compliance—it is a detection layer, not a prevention layer. Combine it with input sanitization, output filtering at the application level, and regular penetration testing of the full AI pipeline.