Prompt Injection Campaign Detection Across Sessions Prompt

This prompt is designed for security operations teams who need to move beyond single-session injection detection and identify coordinated, large-scale prompt injection campaigns. It operates on aggregated metadata from multiple user sessions that have already been flagged as anomalous by a per-session detector. The core job-to-be-done is threat actor attribution and campaign scoping: you have a batch of suspicious traces and need to determine if they represent isolated probing by different actors or a single organized attack targeting your AI system. The prompt analyzes three key signals—temporal clustering of injection attempts, payload fingerprint similarity via hashing, and patterns in the target endpoints or system prompts being attacked—to output a structured campaign alert.

Before using this prompt, you must have a prerequisite detection pipeline in place. Each input record must be a pre-processed session summary containing at minimum an injection confidence score, a payload hash (e.g., SHA-256 of the normalized user input or tool argument), and an endpoint identifier (such as a system prompt version, agent ID, or API route). Do not feed this prompt raw trace data, full conversation logs, or unprocessed request bodies. The prompt expects structured, aggregated metadata. If your input batch contains fewer than 10 flagged sessions, the clustering analysis will be unreliable, and you should instead use a single-session forensic prompt like Production Trace Injection Pattern Detection to investigate each case individually. This prompt is also not suitable for real-time per-request blocking; it is a batch analysis tool for retrospective campaign discovery and threat intelligence gathering.

The ideal user is a security engineer or incident responder who has received an alert about a spike in injection detections and needs to quickly assess scope. The output is a campaign alert containing a temporal scope (start and end time of the suspected campaign), a list of affected endpoints, and a confidence score for the campaign classification. Use this output to update your WAF rules, blocklist specific payload fingerprints, or escalate to your threat intelligence team. If the prompt returns a low campaign confidence score, it means the flagged sessions are likely independent events, and you should investigate them as isolated incidents rather than a coordinated attack. Always pair this prompt's output with human review before taking automated blocking actions, as false positives in campaign classification can lead to over-blocking legitimate but unusual user behavior.

This prompt template is designed to be wired into a security operations pipeline that processes batches of production traces. It expects pre-aggregated metadata—not raw trace bodies—to identify temporal spikes, shared payload fingerprints, and coordinated probing patterns that single-session detectors miss. Replace each square-bracket placeholder with data from your trace observability platform before sending the prompt to the model.

textCopy
You are a security analyst reviewing aggregated AI trace metadata to detect coordinated prompt injection campaigns.

## INPUT DATA
- Time window: [START_TIME] to [END_TIME]
- Total sessions in window: [SESSION_COUNT]
- Flagged sessions (injection detectors triggered): [FLAGGED_SESSION_COUNT]
- Aggregated payload fingerprints (normalized hashes of injection payloads): [PAYLOAD_FINGERPRINTS]
- Affected endpoints and hit counts: [ENDPOINT_HIT_COUNTS]
- System prompt versions targeted: [TARGETED_PROMPT_VERSIONS]
- Tool-call anomaly clusters: [TOOL_ANOMALY_CLUSTERS]
- User/session identifiers (anonymized): [ANONYMIZED_SESSION_IDS]
- Detection confidence distribution: [CONFIDENCE_DISTRIBUTION]

## TASK
Analyze the aggregated data to determine whether a coordinated injection campaign is underway. A campaign is defined as multiple sessions within the time window sharing one or more of the following: identical or structurally similar payloads, targeting the same system prompt version, probing the same tool endpoints, or originating from a shared infrastructure pattern.

## OUTPUT SCHEMA
Return a JSON object with these fields:
- `campaign_detected` (boolean): true if a coordinated campaign is identified
- `campaign_confidence` (float 0-1): confidence in the campaign assessment
- `campaign_clusters` (array of objects): each cluster represents a distinct campaign, with fields:
  - `cluster_id` (string): unique identifier for this campaign cluster
  - `fingerprint_match_type` (string): "exact", "structural", "tool-targeting", or "temporal-burst"
  - `shared_payload_signature` (string): the common payload pattern or hash prefix
  - `affected_session_count` (integer): number of sessions in this cluster
  - `affected_endpoints` (array of strings): endpoints targeted
  - `temporal_scope` (object): `first_seen` and `last_seen` timestamps
  - `severity` (string): "critical", "high", "medium", or "low"
- `isolated_events` (array of objects): flagged sessions that do not cluster with others, with fields:
  - `session_id` (string)
  - `reason_isolated` (string): why this event was not grouped into a campaign
- `recommended_actions` (array of strings): concrete steps for the security team
- `human_review_required` (boolean): true if any cluster has severity "critical" or "high"

## CONSTRAINTS
- Do not fabricate payload details beyond what the fingerprints provide.
- If fewer than [MIN_CLUSTER_THRESHOLD] sessions share a fingerprint, treat them as isolated events.
- Flag for human review if any campaign cluster targets a production system prompt version.
- If confidence is below 0.6, set `campaign_detected` to false and explain uncertainty in `recommended_actions`.

## EXAMPLES
[FEW_SHOT_EXAMPLES]

Adapt this template by adjusting the input fields to match your observability platform's schema. The [PAYLOAD_FINGERPRINTS] placeholder should receive normalized hashes from your injection detection pipeline—never raw user inputs—to avoid propagating sensitive data into the analysis prompt. The [MIN_CLUSTER_THRESHOLD] should be tuned to your baseline traffic volume: too low and you'll get false campaigns from noise; too high and you'll miss small coordinated probes. The [FEW_SHOT_EXAMPLES] placeholder should contain 2-3 labeled examples of campaign vs. non-campaign patterns drawn from your own historical trace data to calibrate the model's clustering behavior.

This prompt is designed to operate as a batch analysis job within a security monitoring pipeline, not as a real-time request classifier. It expects aggregated trace metadata from a defined time window—typically 1-hour, 6-hour, or 24-hour buckets—fed from your observability platform's injection detection logs. The prompt should be invoked on a cron schedule, with the input payload assembled from a query that collects all traces flagged with injection_confidence > 0.5 or equivalent detector scores during the window. Do not send raw trace bodies; send only the structured metadata fields specified in the prompt template: session IDs, timestamps, detector scores, payload fingerprints, target endpoints, and user/session identifiers. This keeps token consumption predictable and prevents accidental PII exposure in the analysis payload.

Wiring the pipeline: Construct a pre-processing step that queries your trace store (e.g., ClickHouse, Elasticsearch, Datadog, or a custom observability database) with a time-bounded filter for injection-flagged sessions. Normalize the results into the [SESSION_BATCH] JSON array structure expected by the prompt. Apply a minimum batch size threshold—if fewer than 5 flagged sessions exist in the window, skip the LLM call and log a LOW_VOLUME_SKIP event to avoid noisy alerts on sparse data. For batches above threshold, send the assembled payload to a model with strong reasoning capabilities (GPT-4o, Claude 3.5 Sonnet, or equivalent) with temperature=0 to maximize deterministic clustering and severity assessment. Set a max_tokens limit appropriate for your expected campaign count (2048–4096 tokens is usually sufficient). Implement a retry wrapper with exponential backoff (3 attempts max) for API failures, and log each attempt with the batch window identifier for debugging.

Post-processing and validation: Parse the model's JSON output and validate it against a strict schema before acting on it. Required fields include campaign_detected (boolean), campaigns (array of objects with campaign_id, fingerprint_signature, temporal_scope, affected_endpoints, severity, and evidence_summary). If the output fails schema validation, log the raw response and the validation error, then retry once with a repair prompt that includes the schema and the malformed output. Do not auto-escalate on parse failure—flag it for manual review. For valid outputs where campaign_detected is true, route each campaign object to your alerting system (PagerDuty, Slack webhook, SIEM) with the severity field mapped to your internal incident priority levels. Include the fingerprint_signature in the alert payload so your blocklist automation can consume it. For severity: critical campaigns, trigger an immediate human review notification with the full evidence summary and a link to the raw trace batch for verification before any automated blocking action is taken.

What to avoid: Do not use this prompt as a real-time per-request classifier—it is too slow and expensive for inline detection. Do not feed it raw user inputs or full conversation transcripts; the prompt is designed for metadata-level campaign correlation, and including raw text risks both token blowout and privacy incidents. Do not skip the human review gate for critical-severity campaigns; false-positive campaign alerts can trigger unnecessary incident response and erode trust in the detection pipeline. Finally, maintain an audit log of every batch analysis run, including the input window parameters, the model response, the validation result, and any alerts generated. This log is essential for tuning detection thresholds over time and for post-incident review when a campaign is confirmed.