Canary Token Output Contract Validation Prompt

This prompt is for platform engineers and security operations teams who need to enforce an output safety contract before any model response reaches a user, downstream system, or audit log. It acts as a programmable guard that inspects every generated output against a configurable canary token blocklist. When a match is found, the prompt returns a structured rejection decision with an audit trail instead of the raw output. Use this when you have already embedded canary tokens in system instructions and need a reliable, deterministic validation layer that sits between the model and the outside world. This is not a detection harness for finding tokens in free text; it is a policy enforcement point that decides what happens after detection.

The ideal user is an AI platform engineer integrating this prompt into a serving middleware, API gateway, or post-processing pipeline. You should have a defined list of canary tokens, each with a unique identifier, severity level, and expected location (e.g., system prompt, tool output, retrieval context). The prompt expects a raw model output string and a token blocklist as inputs. It returns a structured decision: either a pass with the original output intact, or a reject with a sanitized response, the matched token ID, severity, and a timestamped audit record. This prompt is not a substitute for input sanitization, rate limiting, or model-level safety training. It is a final checkpoint for a specific class of extraction indicators.

Do not use this prompt as your only defense against prompt injection or data leakage. It validates only the presence of known canary tokens, not novel extraction patterns, PII exposure, or policy violations. It also does not prevent tokens from appearing in outputs; it only controls what happens after they appear. If your threat model includes attackers who can modify or remove canary tokens before extraction, you need additional layers such as input sanitization, retrieval filtering, and runtime monitoring. Pair this prompt with the System Prompt Canary Token Embedding Template and the Canary Token Alerting and Escalation Prompt Template for a complete detection-to-response pipeline. Before deploying, test against the Automated Canary Token Fuzzing Harness to ensure your blocklist and matching logic hold under adversarial variation.

This prompt template acts as a final output gate in your AI pipeline. It receives a model-generated response and a configured blocklist of canary tokens, then determines whether any token has leaked. The prompt is designed to be called programmatically after every model generation but before the response reaches the user. It returns a structured pass/fail decision with an audit trail, making it suitable for high-security environments where instruction leakage must be detected in real time.

textCopy
You are an output security validator. Your only job is to check the [MODEL_OUTPUT] below against a canary token blocklist and return a structured validation result.

# BLOCKLIST
[TOKEN_BLOCKLIST]

# MODEL OUTPUT TO VALIDATE
[MODEL_OUTPUT]

# VALIDATION RULES
1. Check the MODEL OUTPUT for any exact or near-exact match of any token in the BLOCKLIST.
2. Near-exact means: case-insensitive match, token split across line breaks, or token with minor whitespace variation.
3. Do NOT flag tokens that appear in the BLOCKLIST itself or in these instructions.
4. If the MODEL OUTPUT contains a token that is also present in the [ALLOWED_CONTEXT], do NOT flag it. This prevents false positives when canary-like strings appear in legitimate user or system content.

# OUTPUT SCHEMA
Return ONLY valid JSON with this exact structure:
{
  "passed": boolean,
  "detected_tokens": [string],
  "match_locations": [{"token": string, "position": string, "excerpt": string}],
  "confidence": number (0.0 to 1.0),
  "recommended_action": "release" | "block" | "quarantine" | "escalate"
}

# CONSTRAINTS
- Do not explain your reasoning in the output.
- Do not include the blocklist tokens in your response except in the detected_tokens and match_locations fields.
- If no tokens are detected, return an empty array for detected_tokens and match_locations.
- Set confidence to 1.0 for exact matches, 0.8-0.95 for near-exact matches, and 1.0 when no tokens are detected.

Adaptation guidance: Replace [TOKEN_BLOCKLIST] with your actual canary token array, formatted as a JSON list or newline-separated values. The [MODEL_OUTPUT] placeholder should receive the raw model response before any post-processing. The [ALLOWED_CONTEXT] field is critical for reducing false positives—populate it with any legitimate strings from the user input, system prompt preamble, or tool outputs that might coincidentally resemble canary tokens. For production use, wrap this prompt in a retry loop with at least one retry on malformed JSON output, and log every validation result—including passes—to maintain a complete audit trail for security review.

This prompt is designed to operate as a synchronous validation gate between the model's raw output and the end user. It should be deployed as a post-processing step in your AI gateway, middleware, or reverse proxy. The prompt receives the raw model output and the active canary token blocklist, then returns a structured verdict. Do not rely on this prompt as your only defense; it is a detection layer that must be paired with an enforcement mechanism that can block, redact, or quarantine violating responses before they reach the user.

Wire the prompt into your application by calling it immediately after the primary model response is generated but before the response is streamed or returned to the client. The input to this prompt is the raw model output string and a JSON array of active canary tokens. The expected output is a strict JSON object with fields: verdict (one of PASS, BLOCK, QUARANTINE), detected_tokens (array of matched token strings), confidence (0.0 to 1.0), and audit_event_id (UUID for traceability). Implement a retry loop with a maximum of 2 attempts if the prompt returns malformed JSON. If the validator itself fails after retries, your application must default to the safest action—typically BLOCK—and log the failure as a critical incident. Use a fast, cost-effective model for this validation step (such as a small Claude Haiku or GPT-4o-mini tier) since it runs on every response.

For high-throughput systems, batch multiple responses into a single validation call where latency allows, but never batch across different users or sessions to avoid cross-contamination. Log every validation result—including passes—to your security information and event management (SIEM) system or audit database. The audit_event_id field must be propagated to downstream logging so security operations can trace a detection back to the exact request, model version, and prompt configuration. Before deploying to production, run this prompt against a golden dataset of outputs containing known canary tokens, clean outputs, and edge cases with near-miss token patterns. Measure precision and recall, and tune the prompt's [CONSTRAINTS] block to reduce false positives without missing real leakage. If your application handles regulated data, route all QUARANTINE verdicts to a human review queue and never auto-release them without approval.