Consent Boundary Verification Prompt for Traces

This prompt is designed for privacy product managers and compliance engineers who need to verify that data processing in a production AI trace stayed within the consent scope the user originally granted. The core job-to-be-done is not just detecting PII, but answering a harder question: 'Did we use the user's data for a purpose they did not agree to?' This requires comparing the declared consent scope—which may include multiple processing purposes, third-party sharing flags, and retention limits—against the actual processing steps observed in the trace, including tool calls, retrieved context, generated outputs, and data passed to external APIs.

Use this prompt when you have a production trace that captures the full request lifecycle (user input, system prompt, tool calls, retrieved documents, and final output) and you also have access to the user's consent record, which should specify allowed purposes, third-party sharing permissions, and any data category restrictions. The prompt is most effective in environments with granular consent models, such as those required under GDPR, CCPA, or internal data governance policies where users can opt into specific processing purposes independently. It is not a general-purpose PII scanner; for raw PII detection in logs, use the sibling 'PII Detection Prompt for Trace Logs' instead.

Do not use this prompt when consent records are unavailable, incomplete, or stored in a format that cannot be mapped to trace events. It is also inappropriate for real-time enforcement at the API gateway level—this is an offline audit and review tool, not a low-latency policy engine. The prompt assumes a human reviewer will act on the violation flag; it is not designed to automatically block processing. If you need automated enforcement, combine this prompt's output with a policy engine that can halt specific tool calls or data flows based on the violation flag and consent gap description.

Before running this prompt, ensure your trace data includes span-level metadata that identifies the processing purpose for each step, or be prepared to provide a mapping from tool names and API endpoints to processing purposes in the [CONTEXT] block. The prompt's accuracy depends heavily on this mapping. If your traces lack purpose-level tagging, you will get unreliable results. Start with a small set of known-consent traces to calibrate the prompt's violation detection threshold before scaling to bulk audit workflows.

This prompt is the core instruction set you will send to an LLM to audit a production trace for consent boundary violations. It is designed to be copied directly into your observability harness, with square-bracket placeholders that you replace with runtime data. The prompt forces the model to extract the user's declared consent scope, identify the actual processing purpose observed in the trace, and flag any mismatch. Use this template as the starting point for your automated consent verification pipeline.

textCopy
You are a privacy compliance auditor reviewing an AI system trace. Your task is to verify that all data processing observed in the trace stayed within the consent scope the user granted.

## INPUT DATA

**Consent Record:** [CONSENT_RECORD]
**Trace Data:** [TRACE_DATA]
**Data Processing Policy:** [DATA_PROCESSING_POLICY]

## OUTPUT SCHEMA

Return a valid JSON object with this exact structure:
{
  "consent_scope": {
    "purposes": ["string"],
    "data_categories": ["string"],
    "third_party_sharing_allowed": boolean,
    "retention_period_days": number | null,
    "jurisdiction": "string"
  },
  "observed_processing": {
    "primary_purpose": "string",
    "data_categories_accessed": ["string"],
    "third_parties_contacted": ["string"],
    "trace_span_ids": ["string"]
  },
  "violation_flag": boolean,
  "violations": [
    {
      "type": "purpose_mismatch" | "data_category_exceeded" | "unauthorized_third_party" | "retention_exceeded" | "jurisdiction_violation",
      "description": "string",
      "evidence_span_id": "string",
      "severity": "critical" | "high" | "medium" | "low"
    }
  ],
  "rationale": "string",
  "recommended_action": "string"
}

## CONSTRAINTS

- Only flag a violation if there is clear evidence in the trace that processing exceeded the consent scope.
- If the consent record is ambiguous or incomplete, note this in the rationale but do not assume violation.
- If the trace contains multiple processing steps, evaluate each one against the consent scope.
- Treat third-party sharing as a violation unless the consent record explicitly allows it for the observed purpose.
- If retention timestamps in the trace exceed the consent retention period, flag a retention_exceeded violation.
- Do not hallucinate consent terms. Derive the consent_scope strictly from the provided [CONSENT_RECORD].
- If the trace does not contain enough information to determine a violation, set violation_flag to false and explain the uncertainty in the rationale.

## EXAMPLES

**Example 1: Clear Violation**
Consent Record: { "purposes": ["account_management"], "data_categories": ["email", "name"], "third_party_sharing_allowed": false }
Trace shows: API call to third-party analytics service with user email and name.
Output: violation_flag: true, type: unauthorized_third_party, severity: critical.

**Example 2: No Violation**
Consent Record: { "purposes": ["personalization", "analytics"], "data_categories": ["browsing_history", "preferences"], "third_party_sharing_allowed": true }
Trace shows: Internal recommendation model accessed browsing_history and preferences. No third-party calls.
Output: violation_flag: false.

**Example 3: Ambiguous Trace**
Consent Record: { "purposes": ["service_improvement"], "data_categories": ["usage_data"], "third_party_sharing_allowed": false }
Trace shows: Data sent to an endpoint with an unclear owner. No explicit third-party identifier.
Output: violation_flag: false, rationale: "Unable to confirm whether the destination endpoint belongs to a third party. Recommend manual review."

## RISK LEVEL

Current risk level for this audit: [RISK_LEVEL]
- If RISK_LEVEL is "high": require human review of all flagged violations before taking action.
- If RISK_LEVEL is "medium": auto-escalate critical and high severity violations for human review.
- If RISK_LEVEL is "low": log all violations and proceed with automated remediation.

Analyze the trace data against the consent record and return only the JSON object.

To adapt this template, replace the placeholders with real data from your trace store and consent management platform. [CONSENT_RECORD] should be a structured JSON object from your consent database containing the purposes, data categories, and sharing preferences the user agreed to. [TRACE_DATA] should be the relevant span data from your observability tool, including tool calls, API requests, and data access events. [DATA_PROCESSING_POLICY] is your organization's internal policy document that defines acceptable processing purposes and data handling rules. [RISK_LEVEL] should be set dynamically based on the data sensitivity and regulatory environment—use "high" for healthcare or financial data, "medium" for PII in non-regulated contexts, and "low" for anonymized or public data. After running the prompt, always validate the output JSON against the schema before acting on the violation flag. For high-risk audits, route the output to a human reviewer queue with the original trace attached as evidence.

This prompt is designed to operate as a batch audit step within a trace review pipeline, not as a real-time interceptor. Wire it to run against stored trace spans after a session completes or during a scheduled compliance sweep. The harness must extract the user's consent record (from a consent management platform or user metadata store) and the trace's processing events (tool calls, retrieval steps, and generated outputs) before invoking the model. Because consent models are often granular—covering multiple purposes, third-party sharing flags, and expiration dates—the harness should normalize the consent record into a structured JSON object with fields for purpose, third_party_sharing_allowed, data_categories, and expiration_timestamp before passing it as [CONSENT_GRANT].

Validation and retry logic is critical because a false negative (missing a violation) carries compliance risk. After the model returns a JSON response, validate that the violation_flag field is a boolean, the observed_purposes array contains only strings that map to known processing purposes in your taxonomy, and the consent_scope object matches the structure of the input consent grant. If validation fails, retry once with the validation error appended to the [CONSTRAINTS] field. If the retry also fails, route the trace to a human review queue with the raw trace data, the consent grant, and the failed model output. Do not auto-approve traces where the model's output fails structural validation.

Model choice and tool use: Use a model with strong structured output capabilities and low refusal rates on compliance tasks. GPT-4o, Claude 3.5 Sonnet, and Gemini 1.5 Pro are suitable. Do not give this prompt access to tools that modify data—it should only read trace data and produce findings. If your trace store is large, pre-filter traces to only those that contain tool calls, retrieval steps, or output generation events before running this prompt. For RAG-heavy traces, include the retrieved document metadata in the [TRACE_DATA] so the model can assess whether third-party data sharing occurred through retrieval augmentation.

Logging and audit trail: Every invocation must produce an immutable audit record containing the trace ID, consent grant version, model output, validation result, and reviewer decision (if escalated). Store these records in a tamper-evident log separate from your application logs. This audit trail is your evidence for regulatory reviews and should be queryable by trace ID, user ID, and violation status. If your consent model changes (e.g., a new processing purpose is added), re-run this prompt against historical traces that may now be in violation under the updated consent scope.

What to avoid: Do not use this prompt as a real-time gate on user requests—latency and model availability make it unsuitable for synchronous enforcement. Do not rely solely on the model's violation_flag without human review for high-severity findings. Do not pass raw, unredacted PII into the prompt if the model provider's data processing terms don't cover it; instead, hash or pseudonymize user identifiers before inclusion. Finally, do not treat a clean audit as proof of compliance—this prompt detects processing-purpose mismatches but cannot verify that the consent was freely given or properly recorded in the first place.