Canary Token Incident Response Playbook Prompt

This prompt is designed for security incident responders and AI security engineers who have received an active alert from a canary token detection system. The core job-to-be-done is to transition from a raw detection event to a structured, evidence-backed investigation. The ideal user is someone who understands the AI system's architecture and has access to the raw model logs, the original system prompt containing the canary token, and the flagged output. You need this context before running the prompt: the exact canary token that triggered the alert, the full model output where it appeared, the conversation history leading up to the extraction, and any relevant tool-call or retrieval logs. Without this evidence package, the prompt will produce speculative results that cannot drive a real incident response process.

Use this prompt when a monitoring system flags that a canary token embedded in system instructions has surfaced in a model response, signaling a potential system prompt extraction event. The prompt structures the investigation by analyzing extraction evidence, identifying the likely attack vector (such as direct prompt injection, indirect injection via retrieved documents, or multi-turn conversation hijacking), assessing the blast radius of the exposed system instructions, and generating prioritized remediation steps with explicit evidence preservation requirements. The output includes a severity classification, an attack vector hypothesis with supporting evidence, a blast radius assessment covering what other system instructions or secrets may have been exposed, and a remediation plan that covers immediate containment, evidence collection, and longer-term defensive improvements.

Do not use this prompt for proactive canary token embedding or detection pipeline setup; those are covered by sibling playbooks in this content group, including the System Prompt Canary Token Embedding Template and the Canary Token Output Detection Harness Prompt. Do not use this prompt as a real-time blocking mechanism—it is an investigative tool for post-detection analysis, not a live output filter. Do not use this prompt if you lack access to the raw evidence; the investigation quality depends entirely on the completeness of the input context. After completing the investigation with this prompt, the next step is to execute the remediation actions, preserve all evidence in a tamper-proof incident record, and feed findings back into your canary token placement strategy and detection rules to improve future detection coverage.

This template provides a complete investigation framework for canary token extraction incidents. Replace each square-bracket placeholder with incident-specific data before sending to the model. The prompt is designed to produce a structured analysis that identifies the attack vector, assesses blast radius, and generates remediation steps with evidence preservation. Use this when you have confirmed a canary token appeared in model output and need a systematic investigation.

textCopy
You are a security incident responder investigating a canary token extraction event in an AI system. Your task is to analyze the evidence, identify the attack vector, assess the blast radius, and produce a structured incident report with remediation steps.

## INCIDENT DATA
- Incident ID: [INCIDENT_ID]
- Detection Timestamp: [DETECTION_TIMESTAMP]
- Canary Token Value: [CANARY_TOKEN_VALUE]
- Canary Token Tier: [TOKEN_TIER]
- Token Placement Location: [TOKEN_PLACEMENT]
- Affected Model/Endpoint: [MODEL_ENDPOINT]
- Prompt Version at Time of Incident: [PROMPT_VERSION]

## EXTRACTION EVIDENCE
Provide the full output containing the canary token, surrounding context, and any relevant conversation history:

[EXTRACTION_OUTPUT]

## CONVERSATION CONTEXT
Include the full conversation transcript leading up to the extraction, including user inputs, system responses, tool calls, and retrieved documents:

[CONVERSATION_TRANSCRIPT]

## SYSTEM CONFIGURATION
- Instruction Hierarchy Structure: [INSTRUCTION_HIERARCHY]
- Active Safety Policies: [SAFETY_POLICIES]
- Tool Permissions: [TOOL_PERMISSIONS]
- RAG Configuration: [RAG_CONFIG]
- Input Filters Active: [INPUT_FILTERS]
- Output Filters Active: [OUTPUT_FILTERS]

## INVESTIGATION REQUIREMENTS
1. Classify the attack vector (system prompt extraction, indirect injection, multi-turn manipulation, encoding obfuscation, context overflow, few-shot contamination, routing bypass, retrieval poisoning, or other).
2. Determine whether other canary tokens at different tiers were also extracted.
3. Assess whether any real sensitive data may have been co-extracted.
4. Identify the specific prompt instructions or safety policies that failed.
5. Map the attack path through the system architecture.
6. Evaluate whether the extraction was targeted or incidental.

## OUTPUT FORMAT
Produce a structured JSON incident report with these fields:
{
  "incident_id": "string",
  "severity": "critical|high|medium|low",
  "attack_vector": "string with classification",
  "attack_vector_confidence": "high|medium|low",
  "attack_path": ["ordered list of system components exploited"],
  "blast_radius": {
    "other_tokens_extracted": ["list of other canary tokens found"],
    "sensitive_data_risk": "high|medium|low|none",
    "affected_components": ["list of compromised system parts"],
    "user_impact": "description of user-facing consequences"
  },
  "root_cause": {
    "failed_controls": ["specific instructions or policies that failed"],
    "exploited_weakness": "description of the vulnerability",
    "contributing_factors": ["configuration or design issues that enabled the attack"]
  },
  "evidence_preservation": {
    "conversation_id": "string",
    "log_references": ["relevant log entries"],
    "forensic_artifacts": ["files or data to preserve"]
  },
  "remediation": {
    "immediate_actions": ["steps to take now"],
    "short_term_fixes": ["fixes within 24-48 hours"],
    "long_term_improvements": ["systemic changes needed"],
    "prompt_changes": ["specific instruction modifications"],
    "filter_updates": ["input/output filter changes"]
  },
  "detection_gaps": ["what monitoring missed"],
  "recommended_retesting": ["specific tests to verify fixes"]
}

## CONSTRAINTS
- Base all findings on the provided evidence only. Do not speculate without marking it as low-confidence inference.
- If evidence is insufficient for any field, set the value to null and note the gap in detection_gaps.
- Preserve all evidence references for audit trail.
- Flag any indication that real user data or credentials may have been exposed.

After pasting this template, validate that all placeholders are replaced with actual incident data before sending to the model. The output JSON should be machine-readable for ingestion into your incident management system. For high-severity incidents where the canary token tier is critical or the blast radius assessment indicates possible PII exposure, route the model's output to a human incident commander for review before executing remediation steps. Run this prompt against a consistent model version to ensure reproducible investigation quality across incidents.

The incident response prompt is not a standalone tool—it is a decision-support module inside a larger security operations pipeline. When a canary token detection alert fires from your output monitoring harness, the raw extraction evidence (the leaked token, the full model response, the conversation context, and the detection timestamp) becomes the [EXTRACTION_EVIDENCE] input to this prompt. The prompt's job is to produce a structured investigation brief that a human responder can act on within minutes, not to autonomously execute remediation. Wire this prompt into your incident management platform (PagerDuty, ServiceNow, Jira, or a custom SOAR playbook) so that every canary alert automatically triggers an investigation brief generation step before the responder even opens the ticket.

The implementation harness requires three integration points. First, evidence assembly: before calling the LLM, your alert handler must collect and format the extraction evidence into a structured input block. This includes the canary token value, the token tier (surface, deep, or tool-output), the full model response containing the leak, the preceding conversation turns or tool-call history, the model version and prompt version identifiers, and the detection confidence score from your output scanner. Package this as a JSON object and inject it into the [EXTRACTION_EVIDENCE] placeholder. Second, output validation: the prompt returns a structured JSON investigation brief. Validate that the output contains all required fields—attack_vector, blast_radius_assessment, evidence_preservation_steps, and remediation_actions—before surfacing it to a responder. If validation fails, retry once with a repair prompt that includes the validation errors. If the retry also fails, escalate the raw evidence to a human without AI-generated analysis. Third, audit logging: log every generated investigation brief alongside the raw extraction evidence, the prompt version, the model version, and the validation result. This audit trail is essential for post-incident review and for demonstrating that your canary token detection pipeline is functioning correctly under real extraction attempts.

Model choice matters here. Use a model with strong instruction-following and structured output capabilities (GPT-4o, Claude 3.5 Sonnet, or equivalent). Do not use a small or quantized model for incident response analysis—the cost of a hallucinated attack vector or a missed blast radius assessment is too high. Set temperature=0 or a near-zero value to maximize deterministic, repeatable output. If your organization requires air-gapped or private deployment, ensure the model has access to the canary token taxonomy and tier definitions either through the system prompt or through retrieval-augmented generation from your internal security knowledge base. Human review is mandatory: the prompt's output is a starting point for investigation, not a final determination. Every generated brief must be reviewed by a human responder who can validate the attack vector hypothesis, confirm the blast radius, and authorize remediation actions. The prompt should save the responder time, not replace their judgment.

Common failure modes to guard against in the harness: (1) the prompt may hallucinate an attack vector that sounds plausible but does not match the evidence—always cross-reference the suggested vector against the raw extraction context; (2) the blast radius assessment may overstate or understate impact if the prompt lacks access to system architecture context—consider injecting a [SYSTEM_ARCHITECTURE_CONTEXT] block with details about which components had access to the leaked canary token; (3) the evidence preservation steps may be generic rather than specific to your logging infrastructure—customize the [CONSTRAINTS] block to include your actual log retention tools, snapshot procedures, and chain-of-custody requirements. Before deploying this prompt into production, run it against a set of historical canary token extraction events (or simulated ones) and have two responders independently score the usefulness of the generated briefs. Only promote to production when the briefs consistently reduce time-to-assessment without introducing new errors.