AWS Deception Benchmark Reveals Massive False-Positive Rates in AI Security Models

Amazon Web Services has publicly released its AWS Deception Benchmark, a dataset designed to evaluate how accurately artificial intelligence models perform AI vulnerability detection without falling for safe code that merely looks dangerous. Evaluating 12 general-purpose models across five leading providers, the findings highlight a persistent operational hurdle for application security: every tested model failed to meet standard production criteria, routinely flooding results with false positives or missing critical flaws when pushed to prove exploitability.

Security operations and AppSec teams have rapidly adopted large language models (LLMs) to accelerate vulnerability triage, static code review, threat modeling, and penetration testing. However, when automated scanners generate excessive false positives, security engineering teams suffer from severe alert fatigue, inflated ticket backlogs, and diminished trust in automated findings. AWS created the Deception Benchmark to test whether an LLM actually understands security logic and contextual guardrails or simply relies on surface-level pattern matching.

The Structure of the Deception Benchmark

Existing cybersecurity evaluation frameworks focus on specific operational niches. For example, CyberGym provides over 1,500 interactive execution tasks, Meta’s CyberSecEval evaluates offensive capabilities like exploit generation, CYBENCH tests capture-the-flag capabilities, and ExploitGym measures a model’s transition from vulnerability discovery to functional exploit generation.

In contrast, the AWS Deception Benchmark concentrates specifically on precision: distinguishing genuine, exploitable vulnerabilities from safe code constructs designed to look suspicious.

The dataset comprises 14,822 total samples spanning 16 programming languages and more than 70 Common Weakness Enumeration (CWE) categories. Generating and refining these test cases consumed tens of billions of tokens. To prevent models from cheating or tuning directly against published ground truth, AWS splits the dataset into scored and unscored subsets:

• Scored Samples (9,695 total): Divided into 6,988 code-level challenges and 2,707 environment-gated challenges.
• Unscored Samples (5,127 total): Mixed alongside scored test cases without public labels. Researchers submit raw model predictions directly to AWS for verified scoring.

Code-level challenges present two variants of a code block separated by minor structural differences—one containing an exploitable flaw and the other containing mitigating code. Environment-gated challenges evaluate identical code structures across different runtime environments. For example, a snippet might appear vulnerable to Server-Side Request Forgery (SSRF), but an external control, such as a Kubernetes NetworkPolicy or AWS IAM policy, renders exploitation impossible.

To ensure label accuracy, AWS implemented an adversarial evaluation loop. Multiple independent human and automated reviewers classified samples without seeing prior rationale. Disputed items underwent escalation, and remaining contested cases were moved to the unscored dataset. A validation check of 100 randomly chosen scored samples yielded zero labeling errors.

Testing Core Understanding Without Agentic Scaffolding

When commercial AI security tools run in production, they typically rely on multi-step agentic workflows, iterative re-prompting, and tool integration (such as static analysis tools or dynamic execution sandboxes) to verify findings. According to Amazon Scholar Anshumali Shrivastava and AWS Identity Applied Science Director Neha Rungta, that additional framework masks whether the underlying model genuinely comprehends the code logic.

The Deception Benchmark strips away all agentic scaffolding, requiring models to evaluate each sample in a single pass without hint prompting. This isolates raw contextual reasoning from the brute-force iterative capabilities of multi-turn agent systems.

Key Findings: The Precision vs. Recall Dilemma

AWS defined a baseline production threshold requiring models to achieve both a False Positive Rate (FPR) below 10% and a False Negative Rate (FNR) below 10%. Across all tested prompt strategies and model configurations, not a single general-purpose model met both metrics.

The evaluation highlighted a drastic trade-off depending on how models were prompted:

• Direct Prompting (High Recall, Poor Precision): When asked directly whether code was vulnerable, models successfully flagged nearly every real vulnerability. However, they misclassified safe code containing suspicious patterns as vulnerable between 41% and 99% of the time, resulting in overall precision scores between 52% and 71%.
• Exploit-Proof Prompting (Lower False Positives, High Miss Rates): When required to explain or prove how a flaw could be actively exploited before flagging it, models reduced their false-positive rates by 17 to 74 percentage points. However, this strictness caused models to miss actual flaws, pushing false-negative rates up to between 7% and 44%.

Models struggled most significantly with environment-gated challenges. Standard LLM training emphasis on syntax patterns leaves models ill-equipped to factor external security controls—such as network segmentation, input sanitization wrappers, or infrastructure access limits—into their analysis of whether code is genuinely reachable and exploitable.

Operational Impact for Application Security Teams

For enterprise security operations, relying on raw LLM output for code review or automated vulnerability triage introduces substantial operational friction:

1. Alert Fatigue and High Triage Costs: An engine that triggers false alarms on 41% to 99% of safe code snippets imposes a heavy resource burden on AppSec teams, forcing engineers to manually audit non-vulnerable code path variations.
2. Context Blindness: Flaws categorized under common weakness categories (such as SQL injection, SSRF, or path traversal) are frequently mitigated at the network, gateway, or framework level. LLMs that evaluate code without accounting for environment-level controls will continually generate low-fidelity findings.
3. Over-Reliance on Agentic Harnesses: While multi-pass agent workflows improve practical performance by allowing models to run code or query linters, the benchmark results demonstrate that the underlying logic engines still lack fundamental context awareness when evaluating dangerous code patterns.

Security teams incorporating generative AI into static application security testing (SAST) pipelines should treat LLM findings as preliminary indicators rather than authoritative verdicts. Organizations evaluating AI-driven code scanners can leverage the publicly accessible AWS Deception Benchmark dataset to benchmark vendor models against real-world adversarial safe samples before enterprise deployment.