Indirect PII Exposure via Context Audit Prompt

This prompt is designed for privacy engineers and compliance officers who need to audit retrieval-augmented generation (RAG) traces for a specific, high-risk failure mode: indirect PII exposure. The core job-to-be-done is not to find PII in the user's direct input, but to detect when a system retrieves and surfaces documents containing personal information about individuals who are not the current user. This creates a compliance gap where sensitive data is exposed without the data subject's consent or a legitimate processing purpose tied to the original query. The ideal user has access to production trace data that links a user query to the specific documents retrieved, the final generated output, and metadata about both the user and the source documents.

Use this prompt when you have a trace span that captures the full retrieval-to-generation pipeline and you need to programmatically flag instances where a retrieved document contains a different person's PII. The prompt requires a structured input payload that includes the user's query, the retrieved context chunks, the final model output, and any available user or document metadata. It is not suitable for real-time blocking; its strength is in batch auditing and post-hoc compliance review. Do not use this prompt for direct PII detection in user inputs, for scanning system prompts for hardcoded secrets, or for auditing tool-call arguments. Those scenarios require dedicated, narrower prompts. The output is a structured finding that identifies the exposed individual's category (e.g., 'customer', 'employee', 'public figure'), the source document identifier, the specific PII fields found, and a binary assessment of whether the retrieval was necessary for the task.

The prompt's value is in its ability to distinguish between legitimate multi-person context (e.g., a contract between two companies) and accidental exposure (e.g., a customer support ticket that retrieves another customer's account notes). Before integrating this prompt into a production audit pipeline, you must define clear evaluation criteria. Test it against a golden dataset of traces that includes co-mingled multi-person documents, documents with no PII, and documents where the PII belongs to the current user. Common failure modes include false positives on organization names treated as PII and false negatives when PII is embedded in unstructured text without explicit labels. Always route high-severity findings for human review before taking action on the source documents or retrieval pipeline.

The following prompt template is designed for privacy engineers who need to systematically audit production RAG traces. It focuses on detecting when retrieved context documents contain personally identifiable information about individuals other than the end user, creating indirect exposure that may violate data minimization principles or privacy policies. The template uses square-bracket placeholders that you must replace with actual trace data, policy definitions, and output schema requirements before execution.

textCopy
You are a privacy audit assistant specialized in detecting indirect PII exposure in retrieval-augmented generation (RAG) traces. Your task is to analyze a production trace and identify whether any retrieved context documents contain personally identifiable information about individuals other than the user who initiated the request.

## INPUT DATA

**User Query:** [USER_QUERY]

**Retrieved Context Documents:**
[DOCUMENTS]

**Generated Output:** [GENERATED_OUTPUT]

**User Identity Context:** [USER_IDENTITY]

## PII DEFINITIONS

Apply the following PII categories when scanning context documents:

[PII_CATEGORIES]

## CONSTRAINTS

1. Only flag PII that belongs to individuals OTHER than the user who made the request. Do not flag the user's own information.
2. Distinguish between PII that was necessary for answering the query and PII that was retrieved unnecessarily.
3. If a document contains co-mingled PII for multiple individuals, analyze each individual separately.
4. Consider indirect identifiers that could re-identify an individual when combined (e.g., rare job title + small company + city).
5. Mark findings as FALSE POSITIVE if the apparent PII is actually a placeholder, example value, or synthetic data.
6. If no indirect PII exposure is detected, explicitly state that finding rather than returning an empty result.

## OUTPUT SCHEMA

Return a JSON object with this structure:

[OUTPUT_SCHEMA]

## ANALYSIS STEPS

1. Identify all individuals mentioned in the retrieved context documents.
2. For each individual, determine whether they are the requesting user or a third party.
3. For each third-party individual, catalog all PII fields present in the context.
4. Assess whether each PII field was necessary for answering the user's query.
5. Identify the document source and retrieval query that surfaced each exposure.
6. Assign a risk level based on the sensitivity and necessity of the exposed data.

## RISK LEVELS

[RISK_LEVELS]

## EXAMPLES

[EXAMPLES]

To adapt this template for your environment, replace the placeholders with concrete values. [PII_CATEGORIES] should contain your organization's specific PII taxonomy, such as names, email addresses, phone numbers, government identifiers, financial account numbers, health information, and precise geolocation. [OUTPUT_SCHEMA] must define the exact JSON structure your logging or compliance system expects, including fields for exposed_individual_category, document_source, retrieval_query, pii_fields_found, necessity_assessment, and risk_level. [RISK_LEVELS] should map to your incident response tiers, such as CRITICAL for exposed financial or health data, HIGH for contact information combined with other identifiers, MEDIUM for standalone contact information, and LOW for information already publicly available. [EXAMPLES] should include at least one positive case showing indirect exposure, one negative case where all PII belongs to the requesting user, and one edge case with co-mingled multi-person documents. Before deploying this prompt to production, validate it against a golden dataset of annotated traces and establish a human review step for any finding rated CRITICAL or HIGH.

This prompt is designed to operate as a post-retrieval audit step within a RAG trace analysis pipeline, not as a real-time guardrail. It should be invoked after a production trace is captured and the full request context—including the user query, retrieved documents, and final generated output—is available for inspection. The harness must extract the retrieved context documents from the trace span, pass them to the prompt alongside the original user query, and collect the structured finding. Because the prompt detects PII about individuals other than the user, the harness must also supply the authenticated user's identity (e.g., user ID, email, or name) as part of the [USER_IDENTITY] placeholder so the model can distinguish between self-PII and third-party PII.

The implementation should wrap the LLM call in a validation layer that enforces the expected output schema before the finding is written to the audit log. Parse the model's JSON response and validate that each finding object contains the required fields: exposed_individual_category, document_source, pii_type, retrieval_necessary, and risk_level. Reject findings where document_source does not match a document ID present in the trace span. For high-risk findings (risk_level: high or pii_type containing government IDs, financial account numbers, or health data), the harness must automatically create a review ticket and quarantine the trace from analytics dashboards until a human reviewer clears it. Implement a retry loop with a maximum of two retries if the model returns malformed JSON or fails schema validation; on the second failure, log the raw response and escalate to manual review.

Model choice matters for this workflow. Use a model with strong instruction-following and JSON mode support, such as Claude 3.5 Sonnet or GPT-4o, because the task requires careful distinction between the user's own PII and third-party PII embedded in retrieved documents. Avoid smaller or faster models that may conflate the two categories, producing false positives that flood the review queue. If you are processing high volumes of traces, consider batching multiple trace contexts into a single request with an array output schema, but cap batch size at five traces to prevent attention dilution. Log every invocation with the trace ID, model version, prompt version, validation result, and reviewer outcome to maintain an audit trail for compliance reporting. The harness should never automatically redact or modify the source documents based on the model's output—this prompt is for detection and alerting only. Remediation actions, such as removing documents from the retrieval index or updating data handling policies, must be performed out-of-band by authorized personnel after human review.