Adversarial Session Replay Detection Prompt

This prompt is built for abuse detection engineers who already have a session-level risk extraction pipeline producing structured risk vectors. If you are running a production AI system and your safety team is seeing repeated attack patterns across sessions or accounts—credential-stuffing scripts, jailbreak templates, or multi-turn social engineering sequences—this prompt compares a new session's risk signature against a library of known adversarial fingerprints. It outputs a match confidence score, a pattern family classification, and recommended countermeasures. The core job-to-be-done is replay detection: identifying when an attacker is reusing a known technique rather than crafting a novel attack, so your team can apply pre-built mitigations instead of investigating from scratch each time.

The ideal user is an abuse detection engineer or security operator who maintains a fingerprint library of known adversarial session patterns. You should have a pipeline that extracts session-level risk features—topic drift metrics, refusal override attempts, sensitive entity accumulation, instruction hierarchy violations—and packages them into a structured vector. This prompt expects that vector as input alongside your fingerprint library. It is not a single-turn classifier, not a real-time injection detector, and not a replacement for per-request safety filters. If you are still building single-turn detection, start with the Session Context Risk Vector Extraction Prompt before layering on this replay detection capability. If your system cannot yet produce structured session risk vectors, this prompt will not help you.

Do not use this prompt when you need real-time blocking on a single turn. It operates on completed or near-complete sessions and is designed for asynchronous abuse analysis pipelines, review queues, and retrospective investigation. Do not use it as your only detection layer—adversaries will eventually use novel techniques that have no fingerprint match. This prompt should sit behind your real-time classifiers as a second layer that catches repeat offenders and accelerates operator response. Also avoid using it when your fingerprint library is empty or contains only one or two patterns; the value comes from matching against a curated, versioned library of known adversarial session signatures. Without a library maintenance process, the prompt becomes a novelty rather than a production defense.

Before deploying this prompt, verify that your session risk vector extraction produces consistent, schema-validated output. Inconsistent feature formatting will cause false negatives in fingerprint matching. You should also establish a human review step for high-confidence matches before automated countermeasures fire—misclassifying a legitimate power user session as adversarial can cause account lockouts and support escalations. The next section provides the copy-ready prompt template with placeholders for your risk vector, fingerprint library, and output schema.

The prompt below is designed to be integrated into a session risk pipeline. It receives a structured representation of the current session's risk features and a library of known adversarial fingerprints, then returns a match analysis. Replace each square-bracket placeholder with structured data from your upstream detection systems and fingerprint database before sending the request to the model.

textCopy
SYSTEM: You are an adversarial session replay detection engine. Your job is to compare a current session's risk signature against a library of known adversarial session fingerprints and determine if the current session matches a known attack pattern.

INPUT:
- Current Session Risk Signature: [SESSION_RISK_SIGNATURE]
- Fingerprint Library: [FINGERPRINT_LIBRARY]

INSTRUCTIONS:
1. Parse the current session risk signature, which includes turn-by-turn risk features, cumulative scores, and behavioral markers.
2. Compare this signature against each entry in the fingerprint library. Each fingerprint contains a pattern family label, a sequence of expected risk features, and a typical risk trajectory.
3. Identify the best match, if any, based on feature overlap, sequence similarity, and trajectory alignment.
4. If no fingerprint exceeds the minimum match threshold, return a no-match result.

OUTPUT_SCHEMA:
{
  "match_detected": boolean,
  "top_match": {
    "pattern_family": string | null,
    "pattern_label": string | null,
    "confidence_score": number (0.0 to 1.0) | null,
    "matched_features": [string] | [],
    "trajectory_similarity": number (0.0 to 1.0) | null
  },
  "alternative_matches": [
    {
      "pattern_family": string,
      "pattern_label": string,
      "confidence_score": number
    }
  ],
  "evidence_summary": string,
  "recommended_countermeasures": [string]
}

CONSTRAINTS:
- Minimum confidence threshold for reporting a match: [CONFIDENCE_THRESHOLD]
- Do not fabricate matches when evidence is weak. Prefer false negatives over false positives.
- If the session signature is incomplete or malformed, return an error field instead of guessing.
- Cite specific fingerprint entries and matched features in the evidence summary.

To adapt this prompt, replace [SESSION_RISK_SIGNATURE] with the structured output from your session risk vector extraction prompt, including turn-by-turn risk scores, detected probing patterns, and cumulative policy violation counts. Replace [FINGERPRINT_LIBRARY] with a serialized array of known adversarial fingerprints, each containing a unique label, pattern family classification, and the expected sequence of risk features. Set [CONFIDENCE_THRESHOLD] based on your operational tolerance for false positives—start with 0.7 and tune after reviewing production matches against human-labeled ground truth.

Before deploying, validate the output schema against malformed model responses. If the model returns a confidence score above threshold but the evidence summary is empty or contradictory, flag the result for human review rather than auto-activating countermeasures. Log every match decision with the full prompt payload, model response, and reviewer disposition to build an audit trail for threshold calibration and pattern library updates.

The adversarial session replay detection prompt is designed to operate as a post-session analysis step, not a real-time interceptor. Wire it into your abuse detection pipeline after a session concludes or when a cumulative risk score crosses a configurable threshold. The prompt expects a structured payload containing the current session's risk signature and a library of known adversarial fingerprints. In practice, you will maintain a fingerprint library—a versioned collection of attack pattern vectors extracted from confirmed abuse incidents—and pass the most relevant subset as [KNOWN_PATTERNS] to keep context within token limits. The prompt should be invoked by a dedicated worker that assembles the session signature from your existing session risk scoring infrastructure, queries the fingerprint library for candidate matches, and submits the prompt to a model with strong instruction-following and structured output capabilities.

Model choice and output validation are critical. Use a model that reliably produces the expected JSON schema—GPT-4o, Claude 3.5 Sonnet, or equivalent—and configure response_format to enforce the output structure. After receiving the model response, validate the output against a strict schema: match_confidence must be a float between 0.0 and 1.0, pattern_family must be drawn from your defined taxonomy, and evidence_turns must reference actual turn indices present in the session. If validation fails, retry once with the validation error injected into the prompt as additional context. If the retry also fails, log the failure and route the session to a human review queue with the raw model output and validation errors attached. Never silently accept malformed outputs in an abuse detection pipeline—false negatives here allow adversarial patterns to propagate.

Logging and observability are non-negotiable. For every invocation, log the session ID, the fingerprint library version used, the model response, the validation result, and the final disposition (match confirmed, no match, or escalated). This audit trail enables retrospective analysis when a new attack pattern is discovered later—you can replay sessions against updated fingerprint libraries to find missed detections. Store match results in your abuse detection database with a TTL appropriate to your investigation window. If the prompt returns a high-confidence match, trigger your incident response workflow: flag the account, attach the match evidence to the case, and feed the confirmed pattern back into your fingerprint library to strengthen future detection. Avoid treating this prompt as a fire-and-forget classifier; it is a detection signal that feeds a broader investigation and response loop.

Performance considerations matter at scale. The fingerprint library comparison is the most token-intensive part of this prompt. Implement a pre-filtering step that uses lightweight similarity measures—cosine similarity on session risk vectors, or a fast embedding lookup—to select the top-K candidate fingerprints before passing them to the prompt. This keeps [KNOWN_PATTERNS] compact and reduces both latency and cost. If your session volume is high, batch non-urgent sessions for offline processing and reserve real-time invocation for sessions that cross a high-risk threshold. For model routing, consider using a faster, cheaper model for the pre-filtering step and reserving the full prompt with detailed pattern comparison for sessions where the pre-filter returns plausible candidates. The next step after implementing this harness is to build a regression test suite using known adversarial session replays to verify that pattern library updates do not degrade detection on previously caught attacks.