The state of AI for security: Measuring what matters most for building trust

What it claims

Deception Benchmark asks a model, in one pass with no hints, whether a code sample is vulnerable or safe. The safe samples carry a real vulnerability pattern plus a mitigation that closes the exploit path. Under direct prompting, models catch up to 95% of real vulnerabilities but flag 41–99% of safe code as vulnerable. Proof-of-exploit prompting trades false alarms for misses. No configuration of the 12 general-purpose models tested got both FPR and FNR under 10%.

How it works

There are two challenge types:

• Code-level (6,988 samples): vulnerable and safe variants differ by a subtle fix. An example is a Flask query that looks like SQL injection but uses parameterized statements.
• Environment-gated (2,707 samples): the code is identical and only the deployment context differs. For example, a Kubernetes Network Policy blocks an SSRF path, or an IAM boundary prevents privilege escalation.

These two counts sum to the 9,695 scored samples. The other 5,127 samples are unscored decoys mixed in with them. Labels are not released, so all scoring goes through submission.

Samples were built in a generate → test against frontier models → harden loop. Samples that models got right easily were dropped. The authors say this cost tens of billions of tokens.

Labels then went through a convergent audit loop. The key rule is that a disputed sample is never relabeled. It moves to the unscored pool instead, so a bad challenge can remove a sample but cannot introduce a wrong label.

flowchart TD
  L[Label] --> R[Multiple blind reviewers]
  R -->|agree| S[Scored set]
  R -->|disagree| A[Adjudicate vs original reasoning]
  A -->|resolved| S
  A -->|unresolved| H[Human review]
  H -->|still disputed| U[Unscored pool, never relabeled]
  H -->|resolved| S
  S --> C{Disputes under threshold?}
  C -->|no| R

The loop stops when fewer than 3% of scored samples are still contested in independent review, with a target of under 1% surviving human adjudication.

Evidence

• Balance: the set is roughly half vulnerable and half safe, so random guessing scores about 50%.
• Direct prompting: precision ranges from 52% to 71% and clusters in the mid-50s. Recall reaches up to 95%, and FPR is 41–99%.
• Proof-of-exploit prompting: FPR drops by 17–74 points, but FNR rises to 7–44%.
• Environment-gated samples: results are worse. Models flag the code and ignore the adjacent Network Policy. No per-type numbers are given.
• Label quality: a human check of 100 random scored samples found no label errors.
• Not on the page: the 12 models and five providers are not named, and there is no per-model table. Both may be in the whitepaper.

How to use it

The dataset, evaluation workflow, whitepaper and submission instructions are on GitHub. You run your system on all 14,822 samples and submit predictions for verified scoring. You cannot score locally, because the labels are withheld.

The page gives no repo URL, commands or licence.

Report FPR and FNR separately rather than accuracy. The authors' production bar is under 10% on each.

Limits

• Single-turn only. Agentic or tool-using systems with multi-step validation were not measured. The authors invite such systems to submit.
• They doubt scaffolding fixes this. Agentic verification has mostly been proven on offensive tasks, where success can be checked. Judging code safe has no such check, so extra passes re-sample the same judgment.
• Synthetic samples. All samples are purpose-built and "grounded in" real patterns, not drawn from real codebases. This avoids contamination but may not match your own code's distribution.
• Light published label validation. The human spot check covered 100 samples. The full process is only in the whitepaper.