Every AI security product publishes a detection rate. Almost none of them is a prediction about your deployment, because the number was produced on a fixed corpus, against a fixed set of attack strings, on traffic that was not yours. This is a protocol for producing your own numbers in a month. It is vendor-neutral; run it against us and against anyone else you are considering.
Why published numbers do not transfer
Two reasons, one statistical and one adversarial.
The statistical one: a false-positive rate is a property of a traffic distribution, not of a detector. A control tuned on customer-support chat will behave differently on a code assistant, where "ignore the previous instruction" is an ordinary sentence. You cannot inherit someone else's false-positive rate any more than you can inherit their base rate.
The adversarial one is sharper. Nasr and colleagues (Google DeepMind, OpenAI, Anthropic and ETH Zurich, 2025) took twelve published defences and attacked them adaptively, optimising each attack against the specific defence rather than replaying a static test set. Most fell with success rates above 90%, and most had originally reported near-zero. The conclusion is not that the defences are worthless; it is that an evaluation where the attacker cannot adapt systematically overstates robustness. Any protocol you run must include an adaptive phase or it will reproduce the same error.
Rule for the whole month: record what you did not measure. An evaluation that reports only what it tested reads as though the untested cases passed.
Week 1: baseline on your own traffic
Run the control in observe-only mode against production traffic. You are not measuring the control yet; you are characterising the input:
- Volume and shape: requests per second, prompt and response length distribution, how much of the context comes from retrieval versus from the user.
- How much of your traffic is attacker-influenceable at all. In most enterprise deployments this is far higher than teams expect, because retrieval corpora ingest email, tickets and crawled pages.
- A hand-labelled benign sample, a few hundred requests, drawn from real traffic. Without it you have no denominator for a false-positive rate, and every later number is unanchored.
Do not skip the labelling because it is tedious. It is the only part of this protocol nobody can do for you.
Week 2: build the adversarial set from your own surfaces
Generic jailbreak corpora measure generic robustness. What you need is a set derived from your architecture. Enumerate the surfaces where untrusted content reaches the model, then write attacks that use them: a poisoned document in the corpus you actually retrieve from, an injected instruction in the ticket format you actually parse, a tool-coercion attempt against the tools you actually expose.
Use MITRE ATLAS for technique coverage and the OWASP LLM Top 10 for outcome coverage, and treat both as coverage checklists rather than as scores. Aim for breadth of technique over volume of samples: a hundred attacks spanning fifteen techniques is a more informative set than ten thousand paraphrases of three.
Week 3: the four numbers
Everything else is commentary on these:
- Detection rate on your adversarial set, reported per technique, never as a single average. An average hides the one technique at zero, which is the one that matters.
- False-positive rate on your labelled benign sample. At production volume, a rate that sounds negligible in a demo is a queue nobody triages. Convert it to blocked requests per day before judging it.
- Added latency at p50, p95 and p99. The mean is decorative. Inline controls fail their deployment on the tail, and the tail is where the expensive detectors run.
- Behaviour under failure. Kill the detector, the policy store, the signing key. Does the system fail open or closed, and does it say which? This is the number most evaluations never take, and the one that most often determines the real security posture. A control that silently fails open is not a control.
Week 4: let the attacker move second
Take the attacks that were blocked in week 3 and try to get them through, with knowledge of how the control behaves. Paraphrase. Change encoding. Split a payload across turns or across retrieved documents. Phrase the instruction as though addressed to a human, which is precisely how EchoLeak walked past a production injection classifier in 2025.
Then measure the same four numbers again. The gap between week 3 and week 4 is the real finding of the exercise: it is the difference between how the control performs against attacks it has seen and against an adversary who has seen it. Controls that hold the line here are almost always the deterministic ones, capability gates, allow-lists and egress policy evaluated outside the model, because rephrasing does not change their behaviour.
Reporting
Write the result as three lists: what you measured and the numbers, what you attempted and could not measure, and what you did not attempt. The NIST AI RMF Measure function expects exactly this shape, and it is the form that survives contact with an auditor, because it is falsifiable.
One closing note on evidence. If your evaluation concludes that a control blocked 94% of a technique class, someone will ask you to demonstrate that six months later, in an incident review, about a specific request. If the control does not emit a verifiable record of each decision, you will be reconstructing that answer from logs you control, which is a claim rather than a proof.
Next: Why audit logs aren't evidence, or see Attack Simulation for running the adversarial phase continuously rather than once.