Injection Incident Postmortem Analysis Prompt

Use this prompt after an incident has been detected and initial evidence has been collected. It is an after-action analysis tool, not a real-time detection mechanism. The ideal user is a security engineer or incident responder who has access to the full conversation trace, system prompt version, tool-call logs, and any retrieved context involved in the breach. You should have already isolated the affected session and gathered the raw artifacts before running this analysis. The prompt produces a structured postmortem document that identifies the injection vector, traces the attack path through your system architecture, assesses which defense layers failed, and generates concrete hardening recommendations plus regression test cases.

Do not use this prompt for live traffic screening, real-time injection blocking, or as a substitute for a prompt firewall. It is designed for forensic depth, not speed. The analysis assumes you have a complete picture of the incident—partial logs or redacted traces will produce incomplete or misleading postmortems. If you are still in the detection phase, use a classification or detection prompt from the Jailbreak and Injection Defense Prompts group first. Once the incident is contained and evidence is preserved, return here to understand what broke and how to prevent recurrence.

The output is designed to feed directly into your incident tracking system, security review process, and prompt regression test suite. Expect a structured document with sections for attack timeline, vector classification, defense layer assessment, root cause analysis, hardening recommendations, and generated test cases. Each recommendation should be actionable enough to turn into a Jira ticket or a pull request. The regression test cases should be copy-paste ready for your prompt evaluation harness. Before running this prompt, ensure you have the full conversation log, the exact system prompt in use at the time, any tool definitions, and retrieved context if RAG was involved. Missing evidence will be flagged in the output as an analysis gap.

This prompt template is designed for incident response teams who need to move from a detected injection breach to a structured postmortem quickly. It forces the model to analyze the incident across four dimensions—vector identification, defense gap analysis, remediation planning, and regression test generation—in a single, comprehensive pass. The output is a machine-readable JSON object that can be ingested into ticketing systems, runbooks, or security dashboards. Use this prompt when you have a confirmed injection incident with sufficient forensic evidence to populate the placeholders. Do not use it for speculative threat modeling or pre-incident design reviews; those workflows require different prompts from the Jailbreak and Injection Defense group.

textCopy
You are an AI security incident analyst. Your task is to produce a structured postmortem for a confirmed prompt injection incident. Follow the instructions precisely and output only the JSON object specified in [OUTPUT_SCHEMA]. Do not add commentary outside the JSON.

## INCIDENT EVIDENCE
- Timestamp: [INCIDENT_TIMESTAMP]
- Affected System/Endpoint: [AFFECTED_SYSTEM]
- User Input or Injected Payload: [INJECTED_PAYLOAD]
- System Prompt (sanitized): [SYSTEM_PROMPT_SNIPPET]
- Model Response or Action Taken: [MODEL_RESPONSE]
- Retrieved Context or Tool Outputs Involved: [RETRIEVED_CONTEXT_OR_TOOL_OUTPUTS]
- Conversation History (if multi-turn): [CONVERSATION_HISTORY]
- Observed Impact: [OBSERVED_IMPACT]

## ANALYSIS INSTRUCTIONS
1. **Injection Vector Identification**: Analyze the provided evidence to determine the exact injection technique used. Classify it as direct prompt injection, indirect injection via retrieved content, tool output injection, multi-turn jailbreak, obfuscated payload, or role-play attack. Explain how the payload bypassed existing defenses.
2. **Defense Gap Assessment**: Identify which specific defense layers failed or were missing. Reference the following categories: instruction hierarchy enforcement, input sanitization, delimiter-based separation, tool output validation, multi-turn consistency checks, refusal policy, or output filtering.
3. **Root Cause Summary**: Provide a concise root cause statement (maximum 3 sentences) that a non-security engineer can understand.
4. **Remediation Plan**: Recommend specific hardening steps. For each recommendation, specify the defense layer, the change required, and the expected prevention mechanism. Prioritize by impact.
5. **Regression Test Cases**: Generate 3-5 specific test cases that would have caught this vulnerability. Each test case must include the input payload, the expected safe behavior, and the failure condition to check.

## CONSTRAINTS
- Do not speculate beyond the provided evidence. If a determination cannot be made, state "Insufficient evidence" for that field.
- Do not recommend disabling the feature or removing the model as a remediation unless the evidence shows no other mitigation is possible.
- All remediation steps must be actionable by an engineering team within a standard sprint cycle.
- If the incident involves PII or credentials in the payload, flag this in the `data_exposure_risk` field and recommend immediate credential rotation or data containment steps.

## OUTPUT_SCHEMA
{
  "incident_id": "string",
  "analysis_timestamp": "string (ISO 8601)",
  "injection_vector": {
    "technique": "string",
    "confidence": "high|medium|low",
    "explanation": "string"
  },
  "defense_gaps": [
    {
      "layer": "string",
      "failure_description": "string"
    }
  ],
  "root_cause_summary": "string",
  "remediation_plan": [
    {
      "priority": 1,
      "layer": "string",
      "action": "string",
      "expected_prevention": "string"
    }
  ],
  "regression_test_cases": [
    {
      "test_id": "string",
      "input_payload": "string",
      "expected_behavior": "string",
      "failure_condition": "string"
    }
  ],
  "data_exposure_risk": {
    "pii_or_credentials_detected": true|false,
    "containment_required": true|false,
    "notes": "string"
  }
}

To adapt this template, start by filling every placeholder with concrete evidence from your incident logs. If you lack a specific piece of evidence—such as the full conversation history or retrieved context—replace the placeholder with "Not available" rather than removing the field; this prevents the model from hallucinating missing data. For very long incident logs that exceed the model's context window, split the evidence across multiple prompts and synthesize the findings manually, or use a model with a larger context window and enable prompt caching for the static instruction prefix. After receiving the JSON output, validate it against the schema before ingesting it into your incident management system. A simple JSON Schema validator in your integration layer can catch malformed outputs and trigger a retry with the same prompt.

This prompt is a single-pass analysis tool, not a real-time defense mechanism. After generating the postmortem, feed the remediation_plan into your engineering backlog and the regression_test_cases into your Prompt QA and Regression Testing pipeline. For incidents involving PII or credential leakage, execute containment steps immediately—do not wait for the postmortem to complete. If the model's confidence on the injection vector is low, escalate to a human security analyst for manual review before closing the incident.

This prompt is designed to be the analytical engine inside a broader incident response harness, not a standalone chat interface. The harness should feed structured incident data into the prompt's placeholders, execute the analysis, validate the output against a known schema, and route the result for human review before any remediation actions are taken. The primary integration points are your incident tracking system (e.g., Jira, PagerDuty), your logging and monitoring infrastructure, and your security team's communication channel.

To wire this into an application, build a thin orchestration layer that performs the following steps: First, gather the required inputs—the raw injected payload, the full system prompt, the model's response, and any relevant tool-call logs—from your production tracing system. Second, populate the prompt template's [INJECTION_PAYLOAD], [SYSTEM_PROMPT], [MODEL_RESPONSE], and [TOOL_CALL_LOG] placeholders. Third, call a capable model (GPT-4o or Claude 3.5 Sonnet are appropriate for this analytical task) with response_format set to a strict JSON schema that matches the expected postmortem structure. Fourth, validate the returned JSON in your application code, checking for required fields like injection_vector, defense_gaps, and regression_tests. If validation fails, retry once with the error message injected into the [CONSTRAINTS] field before escalating to a human. Finally, log the full prompt, response, and validation result to an immutable audit store for compliance and future regression testing.

The most critical part of this harness is the human review gate. The model's postmortem is a starting point for an engineer's investigation, not a final report. After validation, the output should be posted as a draft comment on the incident ticket and a notification sent to the on-call security engineer. The engineer must confirm or revise the root_cause and approve the remediation_steps before any are applied. Do not automate the deployment of new system prompt hardening rules directly from this analysis. Instead, use the regression_tests generated by the prompt to expand your automated eval suite, ensuring that any hardening changes you make manually are verified against the specific injection vector that caused the incident.