Prompt Injection Forensic Timeline Reconstruction Prompt

This prompt is for security engineers and incident responders who have isolated a single production trace suspected of containing a prompt injection attack and need to reconstruct the full chronological sequence of events. The job-to-be-done is forensic reconstruction, not detection. You should already have a flagged trace—identified by a detection system, a user report, or an anomaly alert—and now need to understand exactly how the injection unfolded: where the payload entered, how it propagated through system prompts and tool calls, and what downstream effects it caused. The ideal user is someone who can read raw trace data (span events, message objects, tool-call logs) and needs a structured, evidence-cited timeline suitable for incident reports, postmortems, or remediation planning.

Use this prompt when you have a complete session trace containing the full prompt assembly, user inputs, model outputs, tool calls, retrieval steps, and any intermediate system events. The trace must be sufficiently detailed to reconstruct causal order—if your observability pipeline samples or truncates spans, the timeline will have gaps. This prompt is designed for single-session analysis only. It does not correlate patterns across multiple sessions, identify campaign-level indicators, or cluster similar attacks. For cross-session campaign analysis, use the sibling prompt 'Cross-Session Injection Pattern Correlation Prompt' instead. The prompt also assumes the injection has already occurred; it does not classify whether a trace is benign or malicious. If you need that classification first, pair this with 'Production Trace Injection Pattern Detection Prompt' before reconstruction.

Do not use this prompt when you lack raw trace data and only have final model outputs or user-facing logs. Without the internal prompt assembly, tool-call arguments, and retrieval context, the reconstruction will be speculative and the output will contain unfounded assumptions. Do not use it for real-time blocking or inline intervention—this is an asynchronous forensic tool. The output is a structured timeline and root-cause summary, not a live firewall rule or a blocklist update. For regulated or high-severity incidents, always pair the reconstructed timeline with human review before using it in external reports or remediation decisions. The prompt produces a best-effort reconstruction from available evidence; it cannot invent missing spans or guarantee completeness if the trace itself is incomplete.

This prompt is designed for incident responders who need to reconstruct the full sequence of a prompt injection attack from raw production trace data. It orders trace events chronologically to reveal the initial payload delivery, model compromise, tool misuse, and downstream effects. The output is structured for both visualization and root-cause analysis, making it suitable for post-incident review meetings and remediation planning.

textCopy
You are a security-focused AI incident responder specializing in prompt injection forensics. Your task is to analyze a raw production trace and reconstruct the complete timeline of an injection attack.

## INPUT
[TRACE_DATA]

## INSTRUCTIONS
1. Parse the provided trace data, which includes system prompts, user messages, tool calls, retrieval steps, and model outputs, each with a timestamp.
2. Reconstruct the attack chronologically. Identify these key phases:
   - **Initial Payload Delivery:** The first user or tool input containing the adversarial instruction.
   - **Model Compromise:** The point where the model's output or internal state first deviates from the system prompt's intended behavior.
   - **Tool Misuse:** Any unauthorized or anomalous tool calls, including their arguments and targets.
   - **Downstream Effects:** Data exfiltration, state corruption, or user-facing impacts resulting from the compromise.
3. For each phase, cite the specific trace event IDs, timestamps, and a verbatim snippet of the relevant content as evidence.
4. Produce a root-cause summary that identifies the injection vector (e.g., direct user input, retrieved document, tool output) and the vulnerability exploited (e.g., lack of instruction hierarchy, unescaped tool arguments).

## OUTPUT_SCHEMA
You must respond with a JSON object conforming to this structure:
{
  "attack_summary": {
    "injection_vector": "string",
    "vulnerability_exploited": "string",
    "overall_severity": "critical|high|medium|low",
    "root_cause": "string"
  },
  "timeline": [
    {
      "phase": "initial_payload_delivery|model_compromise|tool_misuse|downstream_effects",
      "timestamp": "ISO 8601 string",
      "event_id": "string",
      "description": "string",
      "evidence_snippet": "string"
    }
  ],
  "visualization_ready": {
    "mermaid_code": "string containing a valid Mermaid.js sequence diagram",
    "key_entities": ["string"]
  }
}

## CONSTRAINTS
- Do not hallucinate events not present in [TRACE_DATA].
- If a phase cannot be identified, set its `description` to "Not detected in provided trace" and omit the `evidence_snippet`.
- The `mermaid_code` must be syntactically valid and use `sequenceDiagram` format.
- Prioritize precision over recall; flag uncertainty in the `description` field if evidence is ambiguous.

To adapt this template, replace the [TRACE_DATA] placeholder with the raw JSON or structured log output from your observability platform. Ensure the trace data includes timestamps and unique event IDs for each span. For high-severity incidents, the generated root_cause and timeline should be reviewed by a human incident commander before being used to drive automated blocklist updates or rule changes. The mermaid_code output can be rendered directly in most engineering wikis to create a visual attack sequence diagram for the postmortem document.

This prompt is designed to be the analytical core of a semi-automated forensic workflow, not a standalone chat interaction. It should be deployed behind a secure API endpoint that is only accessible to authorized incident responders. The harness must enforce strict input validation on the raw trace data before it reaches the model, ensuring that the [RAW_TRACE_DATA] conforms to a known schema (e.g., OpenTelemetry or a custom JSON log format) and does not contain live system credentials. The workflow should be triggered by an upstream detection system, such as a SIEM alert or a manual runbook step, which provides the session ID and fetches the relevant trace from an observability platform like Datadog, Grafana, or an internal trace store.

The implementation should follow a validate-analyze-verify loop. First, a pre-processing script must parse the raw trace, extract the list of spans, and format them into the chronological [TRACE_SPANS] placeholder. The prompt is then rendered and sent to a capable long-context model, such as claude-3-opus or gpt-4-turbo, with a low temperature setting (e.g., 0.1) for deterministic forensic output. The model's JSON response must be validated against a strict schema that checks for the presence of the timeline, root_cause_summary, and compromise_indicators fields. If validation fails, a single retry with the validation error message injected as additional [CONSTRAINTS] can be attempted. All raw inputs, rendered prompts, model outputs, and validation results must be logged to an immutable audit trail for post-incident review.

The final step is a human-in-the-loop review gate. The validated timeline and root-cause summary should be rendered into a pre-incident report draft in a collaborative tool like Notion or a security ticketing system. The report must clearly flag the specific spans where the model detected the initial payload delivery, tool misuse, and downstream effects, linking back to the raw trace for direct inspection. No automated remediation should be triggered directly from this prompt's output. The responder must confirm the findings before the report is shared with a wider incident team or used to update blocklists and detection rules. Avoid wiring this prompt into a fully autonomous response pipeline, as a hallucinated timeline could misdirect a critical investigation.