Structured Output Field Privacy Review Prompt

This prompt is designed for API developers and privacy engineers who need to audit production traces of structured JSON or XML responses. The core job-to-be-done is to detect personally identifiable information (PII) that has leaked into API response fields, even when those fields were not defined as sensitive in the output schema. This is a critical control for systems that enforce strict schema contracts but may still inadvertently surface user data through free-text fields, error messages, or nested objects that bypassed redaction logic.

The ideal user is an engineer or compliance reviewer who has access to production trace data and the corresponding API response schema. You need the raw response payload, the schema definition that declares which fields are sensitive, and the context of the original request to make a determination. This prompt is not a replacement for static code analysis or a data loss prevention (DLP) scanner; it is a targeted review tool for structured outputs that have already passed through your application's serialization layer. Use it when you suspect a schema gap, when onboarding a new API version, or as part of a scheduled privacy audit of high-risk endpoints.

Do not use this prompt for scanning unstructured text like chat completions, log streams, or free-form documents. It is ineffective against obfuscated PII that requires statistical detection, and it will not catch data leakage through side channels like response headers or timing. This prompt also assumes the PII is recognizable in plain text within the field value; it will not identify encrypted or tokenized data that still constitutes PII under your policy. For those scenarios, pair this with a dedicated PII detection model or a regex-based scanner. After running this prompt, always route findings to a human reviewer before taking any automated enforcement action, such as blocking an endpoint or purging data.

This prompt template is designed to be integrated into an automated trace review pipeline. It instructs the model to act as a privacy auditor, examining a single structured output trace (JSON or XML) for any personally identifiable information (PII) that has leaked into the response fields. The core task is to identify data that violates the intended schema constraints, such as a free-text field containing an email address or a numeric ID field exposing a social security number. The prompt is structured to produce a machine-readable JSON output that can be directly ingested by a logging or alerting system.

textCopy
You are a privacy audit AI. Your task is to review a structured API response trace for PII leakage.

Review the [RESPONSE_PAYLOAD] against the [FIELD_SCHEMA_DEFINITION]. The schema definition marks each field as sensitive or non-sensitive.

Identify any field in the response that contains PII but is NOT marked as sensitive in the schema. PII includes, but is not limited to: full names, email addresses, phone numbers, physical addresses, government IDs, financial account numbers, and credentials.

For each finding, you must output a JSON object with the following structure:
{
  "findings": [
    {
      "field_path": "$.user.profile.bio",
      "leaked_data_category": "EMAIL_ADDRESS",
      "leaked_value_preview": "j...@example.com",
      "schema_sensitivity": "non-sensitive",
      "severity": "HIGH"
    }
  ],
  "summary": {
    "total_fields_scanned": 0,
    "total_leaks_found": 0
  }
}

[CONSTRAINTS]
- Traverse all nested objects and arrays. The field_path must be a valid JSONPath or XPath expression.
- For the leaked_value_preview, show only the first and last character of the value to avoid re-exposing the full PII in the audit log.
- If no leaks are found, return an empty findings array and a summary with zero counts.
- Do not flag fields that are correctly marked as sensitive in the schema, even if they contain PII.
- Classify severity as "LOW" for non-identifiable personal data, "MEDIUM" for indirect identifiers, and "HIGH" for direct identifiers or credentials.

[RESPONSE_PAYLOAD]
```json
[INSERT_RAW_JSON_OR_XML_TRACE_HERE]

[FIELD_SCHEMA_DEFINITION]

jsonCopy
[INSERT_SCHEMA_WITH_SENSITIVITY_FLAGS_HERE]

To adapt this template for your own use, you must provide two critical inputs. First, the [RESPONSE_PAYLOAD] should be the exact string of the structured output from your production trace, which your harness will inject programmatically. Second, the [FIELD_SCHEMA_DEFINITION] must be a mapping of your API's response schema with a boolean or string flag (e.g., "sensitive": true) for every field. This schema definition acts as the ground truth for the audit. For high-risk deployments, the harness that wraps this prompt should validate the output JSON against a strict schema to prevent parsing errors and should log any audit finding that has a "HIGH" severity for immediate human review before any automated redaction or deletion occurs.

This prompt is designed to be called programmatically as part of a batch or streaming trace-audit pipeline, not as a one-off chat interaction. The harness should feed the prompt one structured output payload at a time, along with its corresponding API schema definition. The model returns a JSON array of findings, which the harness must validate, log, and route based on severity. Because this workflow handles potentially sensitive data, the harness itself must run in a secured environment with access controls and audit logging enabled.

The implementation should follow a strict validate → retry → escalate loop. After receiving the model's JSON response, validate it against the expected output schema using a JSON Schema validator. Check that every field_path actually exists in the original payload and that data_category values come from your approved taxonomy (e.g., PII, PHI, PCI, CREDENTIALS, NONE). If validation fails or the model returns malformed JSON, retry once with the same input and a stronger instruction to correct the specific validation error. If the retry also fails, log the raw response and flag the trace for manual review. For high-severity findings—such as CREDENTIALS or PHI in a field not marked sensitive—the harness should automatically create an incident ticket and notify the privacy engineering team.

Model choice matters here. Use a model with strong JSON mode and long-context support, such as gpt-4o or claude-3-5-sonnet, because deeply nested payloads can produce large prompts. Enable structured output mode (e.g., OpenAI's response_format with a strict JSON schema) to reduce parsing failures. For cost control on high-volume trace pipelines, consider a two-stage approach: a fast classifier prompt that flags payloads likely to contain sensitive data, followed by this detailed review prompt only on flagged payloads. Always log the prompt_version, model_id, trace_id, and timestamp alongside each finding so you can correlate privacy findings back to specific model behavior and prompt versions during incident reviews.

Before deploying, build a small golden dataset of 20–30 structured payloads with known privacy issues—including deeply nested fields, arrays of objects, and fields with ambiguous names like note or description. Run the prompt against this dataset and measure precision and recall per data category. Pay special attention to false positives on fields that contain benign structured data that resembles PII (e.g., UUIDs, base64-encoded images, or test account numbers). If false positives exceed 5%, add few-shot examples to the prompt showing these edge cases. After deployment, sample 1% of low-severity findings for weekly human review to detect drift in the model's sensitivity or new patterns of leakage that the prompt misses.