Canary Token Alerting and Escalation Prompt Template

This prompt is for security operations teams who have deployed canary tokens in their AI system prompts and need an automated, structured response when a token is detected in model outputs. It classifies the detection event by severity, generates a machine-readable alert payload, and recommends an escalation path based on the token tier and extraction context. Use this prompt inside a detection pipeline where a canary token match has already occurred. It does not perform the detection itself. It assumes you have the raw model output, the matched token value, the token tier, and the surrounding context available as inputs. This prompt belongs after detection and before human incident response. It bridges the gap between a raw regex match and a routed, prioritized security alert.

The ideal user is a detection pipeline or an automated SOAR (Security Orchestration, Automation, and Response) workflow that has already matched a canary token regex. The required inputs are non-negotiable: you must provide the exact token string that fired, its pre-assigned tier (e.g., L1_SURFACE, L2_DEEP, L3_TOOL_OUTPUT), the full model output containing the token, and at least 500 characters of surrounding context. Without these inputs, the prompt cannot accurately assess blast radius or recommend an appropriate escalation path. The prompt is designed to be stateless and idempotent—running it twice with the same inputs should produce the same severity classification and alert routing decision.

Do not use this prompt for initial token detection or regex matching. It is not a substitute for a high-recall detection harness. Do not use it when the token tier is unknown or when the extraction context is truncated, as missing context leads to incorrect severity downgrades. This prompt is also inappropriate for real-time blocking decisions; it is designed for asynchronous alert generation and human review. If you need to block a response from reaching the user based on a canary match, implement that logic in your detection gateway before this prompt runs. Finally, avoid using this prompt for non-security use cases such as general content filtering or toxicity scoring—its output schema and escalation logic are purpose-built for canary token incident response.

This template is the core of your detection pipeline. It activates after a canary token match is confirmed by your output scanning harness. The prompt ingests the raw detection event, the token's predefined tier, and the surrounding conversation or tool-call context. It then produces a structured alert payload ready for your SIEM, paging system, or incident response queue. Do not use this prompt for initial token scanning—it assumes detection has already occurred and focuses entirely on classification, severity scoring, and escalation logic.

textCopy
You are a security alert classifier for an AI canary token detection system. A canary token has been detected in a model's output. Your job is to analyze the detection event, classify its severity, and produce a structured alert payload with an escalation recommendation.

## INPUTS
- DETECTION_EVENT: [DETECTION_EVENT]
- TOKEN_TIER: [TOKEN_TIER]
- EXTRACTION_CONTEXT: [EXTRACTION_CONTEXT]
- MODEL_ID: [MODEL_ID]
- SESSION_ID: [SESSION_ID]
- TIMESTAMP: [TIMESTAMP]

## TOKEN TIER REFERENCE
- TIER_1_SURFACE: Token placed in visible system prompt preamble. Low sensitivity. Indicates basic extraction attempt.
- TIER_2_INSTRUCTION: Token embedded inside behavioral instructions. Medium sensitivity. Indicates deeper instruction probing.
- TIER_3_POLICY: Token hidden inside safety or refusal policy blocks. High sensitivity. Indicates targeted policy extraction.
- TIER_4_TOOL: Token placed inside tool description or parameter schemas. Critical sensitivity. Indicates tool-surface reconnaissance.

## TASK
1. Classify the severity of this detection as LOW, MEDIUM, HIGH, or CRITICAL based on TOKEN_TIER and EXTRACTION_CONTEXT.
2. Generate an alert payload matching the [OUTPUT_SCHEMA].
3. Recommend an escalation path: LOG_ONLY, SECURITY_REVIEW, INCIDENT_RESPONSE, or EMERGENCY_PAGE.
4. Include a concise evidence summary that quotes the relevant output fragment containing the token.

## SEVERITY RULES
- TIER_1 with isolated extraction and no tool context: LOW
- TIER_2 with any extraction: MEDIUM
- TIER_3 with any extraction: HIGH
- TIER_4 with any extraction: CRITICAL
- Any tier with multi-turn extraction pattern: escalate one level
- Any tier with tool-call correlation: escalate one level

## ESCALATION RULES
- LOW severity: LOG_ONLY
- MEDIUM severity: SECURITY_REVIEW within 24 hours
- HIGH severity: INCIDENT_RESPONSE within 4 hours
- CRITICAL severity: EMERGENCY_PAGE within 15 minutes

## CONSTRAINTS
- Do not include the raw canary token value in the evidence summary. Reference it by token ID only.
- If EXTRACTION_CONTEXT is incomplete or ambiguous, note this in a confidence field and default to one severity level higher.
- If multiple tokens are detected in one event, generate separate alert payloads for each.
- Preserve all timestamps in UTC ISO 8601 format.

## OUTPUT_SCHEMA
Return a JSON object with this exact structure:
{
  "alert_id": "string, generated as CANARY-{TIMESTAMP}-{SESSION_ID}",
  "severity": "LOW|MEDIUM|HIGH|CRITICAL",
  "token_tier": "string",
  "token_id": "string, the token identifier without the raw value",
  "model_id": "string",
  "session_id": "string",
  "detection_timestamp": "string, ISO 8601",
  "escalation_path": "LOG_ONLY|SECURITY_REVIEW|INCIDENT_RESPONSE|EMERGENCY_PAGE",
  "evidence_summary": "string, max 200 chars, describe what was detected and where without exposing the raw token",
  "confidence": "HIGH|MEDIUM|LOW",
  "recommended_actions": ["string, concrete next step"],
  "correlation_hints": {
    "multi_turn": true|false,
    "tool_call_involved": true|false,
    "related_session_ids": ["string"]
  }
}

Adapt this template by replacing the TOKEN_TIER_REFERENCE with your organization's actual canary tier definitions. If you use a different tiering model—such as per-environment, per-customer, or per-model-version tiers—update the severity and escalation rules accordingly. The OUTPUT_SCHEMA should match your SIEM or incident management system's expected payload format. If your detection harness already enriches events with user identity, geographic metadata, or rate-limit counters, add those fields to both the INPUTS block and the output schema. Test this prompt with synthetic detection events across all four tiers before connecting it to a live paging system. A misclassified CRITICAL event that triggers an unnecessary page will erode trust in the entire canary program.

This prompt is designed to sit inside a security monitoring pipeline, not as a standalone chatbot. It receives structured detection events from an upstream canary token scanner—typically a regex or pattern-matching service that monitors model outputs in real time—and produces a classified alert payload. The prompt's job is to interpret the raw detection event, assess severity based on token tier and extraction context, and recommend an escalation path. It should be called automatically when a canary token match is detected, never exposed to end users or embedded in the model's own system prompt.

Wire the prompt into an event-driven workflow: a detection service publishes a canary_token_detected event containing the token ID, tier, matched text, source context (e.g., user output, tool result, log stream), and timestamp. A handler function constructs the prompt request by populating [DETECTION_EVENT] with the serialized event, [TOKEN_TIER_MAP] with your organization's tier definitions and severity mappings, [ESCALATION_POLICY] with team contacts and response SLAs, and [OUTPUT_SCHEMA] with the expected JSON structure. Validate the model's response against the schema before any downstream action—reject and retry once if the output fails schema validation, then fall back to a default CRITICAL classification and page the on-call security engineer. Log every prompt invocation, the raw model response, and the validation result for audit and regression testing.

For model choice, prefer a fast, instruction-following model with strong JSON output discipline (e.g., Claude 3.5 Sonnet or GPT-4o with structured outputs enabled). Latency matters here—the prompt should return in under 2 seconds to avoid delaying incident response. Set temperature=0 to eliminate classification variance. If the detection event contains sensitive output text, ensure the prompt request is sent through an internal API or private deployment; never route canary token evidence through a public model endpoint. For high-security environments, run this prompt on a locally deployed model to keep detection evidence within your network boundary.

The prompt's severity classification must be treated as a recommendation, not an automatic trigger for destructive actions. Implement a two-stage escalation gate: for LOW and MEDIUM severities, log the alert and create a ticket in your security queue for review within the SLA window. For HIGH and CRITICAL severities, immediately notify the on-call security engineer via pager and include the full alert payload. Never allow the model's output to directly rotate API keys, revoke credentials, or block user accounts—those actions require human approval. The prompt's recommended_actions field should be surfaced to the responder as suggested next steps, not executed automatically.

Test this harness end-to-end before production deployment. Create a regression suite with known detection events across all severity tiers, including edge cases like malformed token matches, duplicate detections, and events with truncated context. Verify that schema validation catches malformed model outputs, that the retry-and-fallback logic works, and that alert routing reaches the correct teams. Run these tests after every prompt change and model upgrade. Monitor production metrics: classification latency, schema validation failure rate, retry frequency, and false-positive alert volume. If the model starts misclassifying severities or hallucinating escalation contacts, freeze the prompt version and investigate before the harness generates noisy alerts that erode responder trust.