Safe code fooled all 12 models AWS tested in its Deception Benchmark

A deception sample holds a real vulnerability pattern next to a control that prevents exploitation, and the model gets no hint which is which ^[11]. The environment-gated set pushes that decision outside the file: the same code runs under different deployment conditions, and a Kubernetes Network Policy may block an SSRF that looks reachable from the source alone ^[12]. Those 2,707 samples ask whether a model can read code and deployment together ^[4].

The set is filtered to be hard. AWS generated candidates, ran them against frontier models, made them harder when models classified them correctly, and excluded the easy ones; refining the samples consumed tens of billions of tokens ^[10]. So 41% to 99% is a false-positive rate on code selected for difficulty, not a rate you should expect against your own repository ^[6].

Anshumali Shrivastava, an Amazon Scholar, and Neha Rungta, Applied Science Director at AWS Identity, said: "Production tools rely on multi-step loops and agentic workflows to compensate, but that scaffolding masks whether the model itself understands the code. This benchmark strips the scaffolding away and asks the model to make the call in a single pass, so what it measures is understanding, not how many tries a harness takes to get there" ^[9]. AWS charted 12 models across two prompting strategies against its bar, and by its own account no model reaches it ^[18].

The scored set is roughly balanced, so random guessing scores about 50% ^[8]. That puts roughly 4,850 safe samples in the 9,695 scored ^[2]. At the low end of the range a model flags about 1,990 of them; at the high end, about 4,800 ^[2]. Precision ran from 52% to 71%, which at the bottom means 48 of every 100 findings handed to an analyst are safe code ^[1].

Labels stay with AWS. Predictions are submitted for verified scoring, and 5,127 unscored samples are mixed into the public release to make tuning against the set harder ^[5]. Each label went to multiple independent reviewers who could not see other reviewers' decisions or the original reasoning; AWS repeated the loop until fewer than 3% of scored samples were still contested, targeting under 1% surviving human review, and moved the still-disputed samples to the unscored pile instead of relabeling them ^[13]. A human review of 100 randomly selected scored samples found no labeling errors ^[14].

Existing benchmarks measure adjacent skills: CyberGym carries more than 1,500 realistic tasks, Meta's CyberSecEval covers exploit generation, CYBENCH runs capture-the-flag, and ExploitGym tests whether a model can turn a finding into a working exploit ^[15]. AWS is asking the narrower question a triage queue actually turns on, which is whether the model is right when it calls code vulnerable ^[1]. Security teams already point models at triage, penetration testing, threat modeling, incident response and code review ^[17]. On the safe-versus-vulnerable call, the published numbers support keeping a reviewer on it.