This article describes a hands-on lab exercise where defenders build detection rules to identify when attackers are fingerprinting deployed LLM systems—probing for model identity, knowledge cutoff, tools, and system configuration before launching targeted attacks. The lab provides sample logs containing five fingerprinting sessions and three legitimate ones, and tasks the defender with creating a ruleset that flags at least four probes while maintaining zero false positives on normal users. The exercise teaches that early detection of reconnaissance is far cheaper and more effective than responding after an exploit has occurred.
- Fingerprinting is targeted reconnaissance activityAttackers fingerprint LLM systems by asking model-specific questions like 'what's your knowledge cutoff?', 'list your tools', and 'paste your system prompt' to identify the model, its capabilities, and configuration before selecting attack techniques. This reconnaissance phase differs fundamentally from legitimate user interaction, which focuses on task completion rather than system internals.
- Detection keys on intent and clustering patternsEffective detection rules target the intent behind questions—whether they probe model identity, configuration, or tooling—and observe that fingerprinting probes cluster across multiple turns within a single session. A good ruleset avoids matching on single innocuous words and instead scores behaviour at the session level to distinguish reconnaissance from legitimate curiosity without over-flagging.
- Session-level scoring prevents false positivesDefending against fingerprinting requires scoring at the session level rather than per-message, because probing behaviour patterns emerge across turns in conversation. This approach is more robust than single-keyword matching and allows defenders to catch at least four of five probes while maintaining zero false positives on normal user sessions.
- Defence must operate at every layerThe article emphasizes detecting reconnaissance across multiple layers—not only inside the model but also by logging and scoring inputs, rate-limiting and challenging suspicious sessions, and refusing to disclose model internals like knowledge cutoff, tool lists, or system prompts to users.
- Early detection is cheaper than responseCatching reconnaissance before an actual attack begins is presented as significantly more cost-effective than detecting or responding to the exploit itself. Catching the probe represents an earlier, cheaper line of defence in the attack chain.
- Lab contrasts probe from normal behaviourThe lab provides concrete examples: five fingerprinting sessions ask about model identity, knowledge cutoff, tool lists, or system prompt (often multiple such questions in one session), while three normal sessions show task-focused questions with no interest in system internals. This contrast trains defenders to recognize the structural difference between reconnaissance and legitimate use.
Bottom line: Fingerprinting detection relies on identifying clusters of internal-probing intent across a session rather than flagging individual questions, and deploying session-level behavioural scoring to catch reconnaissance before attacks begin. Defence in depth against LLM attacks starts with building detection for reconnaissance activity, not just for exploits themselves.
📋 In this walkthrough
What this lab teaches
Fingerprinting is reconnaissance: before attacking, an adversary identifies the model, its tools and its configuration so they can pick targeted techniques. Detecting that recon early lets you respond before the real attack. This lab is about building the detection ruleset, not evading it.
The lesson: defence starts before the exploit. Catching the probe is cheaper than catching the breach.
How attackers fingerprint an LLM system
You have a log of sessions — five fingerprinting sessions and three normal ones. Your task is a ruleset that flags at least four of the five probes while flagging none of the three legitimate sessions.
The attack approach
- Read the log and separate probing behaviour from normal use.
- Identify the markers of fingerprinting — questions aimed at model identity, tools, cutoff, or the system prompt.
- Write rules that match those markers without matching ordinary questions.
- Tune to catch at least four of five probes with zero false positives.
Full walkthrough (spoiler)
If you are catching probes but also tripping on normal sessions, tighten the rules — open the steps.
Show the step-by-step solution
- Characterise the five probe sessions: they ask about the model's identity, knowledge cutoff, tool list, or system prompt, often several such questions in one session.
- Characterise the three normal sessions: task-focused questions with no interest in the system's internals.
- Write rules keyed to internal-probing intent (identity/config/tooling questions, and their clustering within a session) rather than any single innocuous word.
- Tune thresholds so at least four probes are flagged and none of the normal sessions are. The lab marks you solved.
Why it works
Fingerprinting looks different from genuine use: it targets the system's internals rather than the user's task, and the probes cluster. A good ruleset keys on that intent and that clustering, so it separates recon from legitimate curiosity without over-flagging.
Where this happens in the real world
Model fingerprinting is a real pre-attack step against deployed LLM systems, and detecting it supports defence against the whole OWASP LLM Top 10 — you stop attacks before they begin. Behavioural, session-level detection is more robust than single-keyword matching.
How to defend against it
- Detect at every layer, not only inside the model — log and score inputs.
- Use session-level behavioural scoring, since recon clusters across turns.
- Rate-limit and challenge probing sessions rather than answering internal questions.
- Never disclose model internals (cutoff, tools, system prompt) to users.
Try it, then go further
Reading about it is the easy part. Open the lab, try your own approach before peeking at the spoiler, and see how many attempts it takes.
