AWS AI Vulnerability Detection Catches Bugs, but False Positives Expose a Trust Gap

AWS tested 12 general-purpose AI models and found a sharp conflict: they caught most vulnerabilities, yet often labeled safe code as dangerous.

The new Deception Benchmark puts AWS AI vulnerability detection claims under a harder test than another bug-finding leaderboard. It asks whether a model can recognize when suspicious code is actually protected by a working mitigation. Under direct prompting, tested models flagged between 41% and 99% of safe samples as vulnerable.

That result shifts the argument around AI security tools. Finding suspicious patterns is not enough when every alert consumes engineering time. The real contest is now between fast pattern recognition and evidence-based verification, with security teams paying the difference.

AWS released the benchmark on September 9, 2026, with 14,822 samples across 16 programming languages and more than 70 Common Weakness Enumeration categories. No tested configuration met AWS's stated minimum of keeping both false-positive and false-negative rates below 10%.

AWS Built a Benchmark Where Safe Code Looks Dangerous

The benchmark tests whether a model understands exploitability, not whether it recognizes a familiar vulnerability pattern.

Many security evaluations start with vulnerable software and ask an AI system to identify or exploit the flaw. That approach reveals useful offensive capabilities, but it gives an incomplete picture of defensive performance. A production reviewer also needs to dismiss code that resembles a vulnerability without creating a real attack path.

AWS designed Deception Benchmark around that distinction. Its safe samples contain realistic frameworks, dangerous-looking data flows, and recognizable security smells. A subtle mitigation closes the exploit path, leaving the model to determine whether the protection actually works.

One example described in the benchmark release involves a Flask endpoint that accepts user input and queries a database. The surrounding pattern resembles SQL injection. However, parameterized statements prevent the input from becoming executable query syntax.

A model that stops after recognizing the pattern will report a vulnerability. A model that traces the entire data flow should classify the sample as safe. That difference determines whether the output becomes useful evidence or another alert requiring manual investigation.

The benchmark includes 6,988 code-level challenges. These present vulnerable and safe variants that differ through a subtle repair. Both versions can look suspicious, but only one remains exploitable.

Another 2,707 challenges add deployment context. The source code might appear vulnerable while an infrastructure control blocks the attack. Examples include a Kubernetes Network Policy stopping server-side request forgery or an identity boundary preventing privilege escalation.

These environment-gated cases matter because enterprise security rarely ends at one file. Exploitability depends on configuration, network reachability, permissions, runtime behavior, and compensating controls. A scanner that ignores those conditions can describe a plausible attack that cannot happen in the deployed environment.

AWS says every sample was created for the benchmark and grounded in real security patterns. The company used an adversarial development loop that generated challenges, tested them against frontier models, hardened easy cases, and repeated the process.

That method makes the dataset intentionally difficult. It also means the results should not be treated as a representative failure rate for every source repository. The benchmark selects cases designed to expose shallow reasoning, not a random sample of everyday code reviews.

Its value comes from isolating a specific capability. Can a model follow an exploit chain far enough to distinguish an actual weakness from a convincing decoy? That question sits at the center of trustworthy AWS AI vulnerability detection.

The public benchmark repository contains all 14,822 samples. AWS scores 9,695 of them and leaves 5,127 unscored. Those held-out samples include disputed or deliberately ambiguous cases.

Labels are not publicly included. Participants must submit predictions for every sample, including explanations, before AWS returns accuracy and error-rate results. This approach is intended to limit memorization and benchmark-specific tuning.

AWS also says independent reviewers repeatedly examined the labels. Disputed samples moved into the unscored pool instead of receiving corrected labels. A human review of 100 randomly selected scored samples found no errors, according to the company.

That does not make the dataset beyond criticism. Independent researchers still need to examine its construction, category balance, scoring process, and real-world transfer. However, the release gives outside teams a common target for comparing systems under the same adversarial conditions.

The AWS AI Vulnerability Detection Results Reveal Two Bad Choices

Direct prompts produce too many false alarms, while stricter proof requirements cause models to miss more real vulnerabilities.

AWS evaluated 12 models from five providers using two prompting strategies. Direct prompting asked each model to classify code as vulnerable or safe. Proof-of-exploit prompting required it to construct a concrete exploit before declaring a vulnerability.

The benchmark separates two error types because they create different operational failures. A false positive labels safe code as vulnerable. A false negative classifies a real vulnerability as safe.

Under direct prompting, the models generally favored sensitivity. They caught as much as 95% of real vulnerabilities, according to AWS. However, they also flagged 41% to 99% of safe code as vulnerable.

This bias can make a model look active and cautious. It is also an easy way to protect recall, which measures the share of real vulnerabilities found. A system that calls everything vulnerable will never miss a vulnerability, but it will bury users in useless alerts.

Mistral Large illustrates that failure mode. Its direct-prompt configuration recorded a 99% false-positive rate and a 0% false-negative rate. It found the vulnerable cases by treating virtually every safe case as dangerous.

Several other direct configurations behaved similarly. GPT-5.6 Sol recorded a 92.5% false-positive rate and a 0.9% false-negative rate. Claude Haiku 4.5 reached a 92.1% false-positive rate while recording no false negatives.

Amazon's own Nova 2 Lite was not exempt. With direct prompting, AWS reported an 89.2% false-positive rate and a 1.2% false-negative rate. The inclusion of Amazon's model helps make the release more than a comparison aimed at outside providers.

Claude Opus 5 produced the strongest direct-prompt balance among the listed systems. It reached 77.3% accuracy, with a 41.5% false-positive rate and a 5.2% false-negative rate. Even that result remained far beyond AWS's stated production threshold.

Accuracy alone obscures these differences. The benchmark is approximately balanced between safe and vulnerable cases, so a classifier that always answers “vulnerable” can score close to 50%. Its apparent accuracy hides the fact that every safe sample becomes an alert.

AWS therefore set what it called a generous minimum bar. A production-ready configuration should keep both error rates below 10%. None of the tested configurations reached that target.

The direct results show why AI vulnerability detection cannot be evaluated by recall alone. Catching nearly every real flaw sounds reassuring until a team learns that most safe code also triggered warnings.

This is not a cosmetic quality problem. Every false alert enters a workflow. Someone must inspect the code, reproduce the alleged path, check configuration, consult the owning team, and document why the finding can be closed.

At enterprise scale, that review cost can erase the speed advantage promised by automation. It can also create alert fatigue, where engineers begin dismissing findings because too many previous alerts were wrong.

The security consequence is uncomfortable. A high false-positive rate can indirectly raise risk even when the model has excellent recall. The important alert competes for attention with dozens of convincing mistakes.

Earlier academic work identified the same pattern. A 2024 security evaluation tested eight language models across 228 code scenarios and reported high false-positive rates. Models sometimes continued flagging vulnerabilities after the tested code had been patched.

That study also found non-deterministic answers and fragile reasoning under simple code changes. AWS's larger release extends the concern across more languages, weakness categories, models, and adversarially constructed safe examples.

Proof of Exploit Reduces Noise but Creates a New Blind Spot

Requiring evidence improves discipline, yet the tested models often bought that precision by overlooking genuine vulnerabilities.

Proof-of-exploit prompting asks a model to move beyond suspicion. Before labeling code as vulnerable, it must describe a concrete path an attacker could use. This changes the decision threshold from “this looks dangerous” to “I can explain how the attack works.”

AWS reported that this strategy reduced false-positive rates by between 17 and 74 percentage points. That is a meaningful improvement. It also increased false-negative rates, which ranged from 7% to 44% under the stricter approach.

GPT-5.4 offers the clearest example of the tradeoff. Its direct configuration produced an 81% false-positive rate and a 1.5% false-negative rate. Proof-of-exploit prompting lowered false positives to 10.1%, but false negatives rose to 33.6%.

Llama 3.3 70B followed a similar pattern. Its false-positive rate dropped from 84.2% to 10.2%. Its false-negative rate climbed from 1.1% to 44.2%, meaning the configuration missed almost half of the scored vulnerabilities.

Claude Opus 5 recorded the highest overall accuracy, 79.3%, under proof-of-exploit prompting. Yet its 24.9% false-positive rate and 16.8% false-negative rate still missed AWS's threshold on both sides.

The results do not mean proof-of-exploit prompting is ineffective. They show that prompting changes which mistakes a model makes. Security leaders must decide whether their workflow can absorb more false alarms, more missed flaws, or a carefully measured combination.

That decision depends on the application. A review of an internet-facing authentication service should tolerate fewer missed vulnerabilities. A low-risk internal repository might prioritize precision to avoid exhausting a small engineering team.

Severity should influence the threshold too. A system could route high-confidence critical findings for immediate human review while handling weaker warnings through lower-priority validation. One global classification threshold is unlikely to fit every codebase.

This is where the benchmark's single-turn design becomes important. AWS deliberately removed agent scaffolding, external tools, and repeated validation loops. The goal was to measure the base model's intrinsic reasoning instead of a complete commercial security product.

Therefore, the results do not establish that every agentic scanner has the same failure rates. A product could combine language models with static analysis, dynamic testing, repository context, policy checks, and deterministic exploit validation. Those components can change the operating point.

AWS explicitly recognizes that distinction. Its benchmark accepts agentic submissions separately from single-turn model results. That separation prevents a tool-assisted system from being presented as equivalent to an unsupported model call.

The caveat does not make the baseline irrelevant. Every agentic workflow inherits some limitations from its underlying model. Repeating a weak judgment can create a more elaborate explanation without adding the missing technical fact.

A system needs a reliable source of new evidence. It might execute a test, trace data across files, inspect a deployment policy, or verify whether an endpoint is reachable. Multiple model calls alone do not guarantee deeper understanding.

The hardest task is proving safety. Offensive testing often provides a visible result because an exploit succeeds or fails. A failed attempt does not establish that no other exploit exists, so the absence of success remains difficult to interpret.

AWS's environment-gated examples sharpen that problem. A model must reason across code and infrastructure, then recognize that a mitigation blocks the route it first noticed. AWS says models frequently saw the risky pattern but ignored the nearby control.

That behavior resembles a common human bias in security review. Once a reviewer recognizes a familiar vulnerability shape, confirmation can arrive faster than disproof. Language models amplify the problem because pattern recognition is central to how they generate answers.

For buyers, the practical lesson is specific. Ask whether an AI security product verifies exploitability and how it measures both error rates. A recall figure without false-positive data reveals little about the workload the product creates.

AWS's Own Security Systems Show Why Architecture Matters

AWS's production claims rely on layered agents, deterministic checks, and human approval, not an unsupported model deciding whether code is safe.

The benchmark arrived months after AWS described two agentic security systems. Those earlier disclosures provide an important counterpoint because they show how Amazon attempts to manage the limitations now measured directly.

RuleForge generates detection rules from publicly available exploit examples. AWS says the system increased rule-production productivity by 336% over a manual process during the final four months of 2025.

Its architecture divides the task among specialized stages. One component ingests and prioritizes vulnerability information. Generation agents propose several detection rules. A separate judge evaluates them, synthetic tests exercise them, and traffic data supports further validation.

A security engineer remains the final approval gate. That human role matters because RuleForge does not treat an AI model's confidence as sufficient evidence for deployment.

AWS said the generation model rated almost every rule highly when asked to judge its own work. Moving evaluation to a separate model reduced false positives by 67% while preserving the number of true-positive detections, according to the company's RuleForge analysis.

The judge also received domain-specific questions. Instead of asking whether a rule looked correct, the system asked whether it might miss malicious requests. It also tested whether a rule captured the vulnerability mechanism or merely a correlated surface feature.

That distinction mirrors Deception Benchmark. A loose expression might match inputs containing a single quote, but matching the character does not prove SQL injection. The rule must distinguish exploit behavior from benign traffic that shares the same feature.

AWS Security Agent uses a related strategy for automated penetration testing. Specialized agents explore applications and produce candidate findings, while validators demand evidence of exploitation.

AWS reported that its system achieved a 92.5% attack success rate on CVE Bench v2.0 when it received capture-the-flag instructions and grader feedback. The rate fell to 80% without those aids and reached 65% with a model whose training cutoff preceded the benchmark.

These numbers measure offensive success, not defensive precision. CVE Bench contains vulnerable applications and tests whether agents can exploit known flaws. It does not answer how often the system would accuse safe code.

Still, the agent architecture illustrates a credible response to the benchmark's weakness. Candidate findings undergo deterministic and model-based checks, while reports include exploitation evidence and technical context.

This creates an apparent contradiction only if “AI vulnerability detection” is treated as one technique. The base-model benchmark exposes weak judgment in a single pass. AWS's production systems claim value from workflows that gather evidence and constrain that judgment.

The comparison supports a more precise conclusion. General-purpose models are useful components for security automation, but the system surrounding them determines whether their output deserves operational trust.

A vendor cannot close the gap by placing an agent label on repeated prompts. The relevant questions concern tools, evidence, calibration, failure handling, and human oversight. Buyers should ask what changes between the first suspicion and the final finding.

Does the product run the allegedly vulnerable path? Does it inspect infrastructure controls? Can it trace data across repository boundaries? Does it compare results against deterministic analyzers? Can a reviewer see why the finding survived validation?

Teams also need durable context during investigation. Architecture notes, prior exceptions, threat models, and remediation decisions often sit across documents and conversations. A searchable engineering knowledge base can help reviewers recover that context, although it does not replace technical validation.

Procurement evaluations should distinguish three layers. The first is the underlying model, where Deception Benchmark offers a common baseline. The second is the validation architecture, which determines how the system gathers additional evidence. The third is the operating process, including review ownership and acceptable risk.

A product can perform well at one layer and poorly at another. A capable model can be weakened by vague prompts and missing context. A less capable model can become more useful when narrow tools and strict validation constrain its decisions.

AWS's disclosures also contain company-reported results, not independent audits of production performance. The 336% productivity claim and 67% false-positive reduction describe RuleForge under Amazon's evaluation. They should not be generalized to unrelated repositories or products.

That uncertainty strengthens the case for a public benchmark. Vendors can submit their complete systems to Deception Benchmark and report separate agentic results. Customers can then compare claims made under a shared task instead of relying on incompatible case studies.

False Positives Turn AI Speed Into Human Work

The business risk is not that AI finds nothing; it is that plausible mistakes consume the people needed to confirm real findings.

Security tools have long struggled with false positives. Traditional static application security testing scans source code for dangerous flows or constructs, often without full runtime context. AI promises better semantic reasoning, but AWS's results show that recognizable patterns still exert a strong pull.

Consider a development team receiving an urgent SQL injection warning. An engineer pauses planned work, finds the relevant owner, reviews the query path, and confirms that parameter binding prevents injection. The alert then needs closure notes so it does not reopen during the next scan.

One mistake seems manageable. Thousands of repositories and frequent scans change the calculation. A high false-positive rate converts automated detection into a recurring manual verification queue.

That queue creates several forms of cost. Engineering work slows because remediation interrupts feature delivery. Security teams spend time defending scanner credibility. Application owners learn to treat alerts as unverified suggestions.

Eventually, confidence erodes. A real vulnerability can arrive through the same channel and receive the same skeptical response. The detection system still “found” the flaw, but operationally it failed to produce timely action.

False negatives create the opposite danger. A stricter system can reduce interruptions by reporting fewer issues, yet its silence becomes less trustworthy if it misses a large share of genuine flaws.

This is why AWS's dual threshold matters. Measuring only precision rewards conservative systems that report almost nothing. Measuring only recall rewards aggressive systems that flag almost everything. Production decisions need both values, segmented by vulnerability severity and code context.

Teams should also ask how a vendor established ground truth. Vulnerability labels are difficult because code can be safe for reasons outside the visible function. Dependencies, configuration, authentication, network controls, and deployment state can alter exploitability.

The Deception Benchmark team tried to limit label errors through repeated independent review and by excluding contested cases from scoring. That is a thoughtful design choice, but it introduces another question. How closely do its cleanly adjudicated samples resemble the ambiguity of real enterprise systems?

Real repositories contain incomplete tests, undocumented assumptions, stale configuration, generated code, and ownership gaps. A tool may need to say that evidence is insufficient instead of forcing a binary vulnerable-or-safe answer.

The benchmark currently asks for that binary decision. Detailed explanations are required, but abstention is not listed as a scored outcome. Future evaluations could examine whether calibrated uncertainty helps teams allocate review effort.

Latency and cost also deserve attention. A multi-agent system might reduce false positives by running tests and inspecting broader context. That improvement could require more compute, longer review times, and access to sensitive code or infrastructure.

Those tradeoffs do not invalidate agentic verification. They determine where it belongs. High-risk changes can justify deeper analysis, while routine code may need cheaper screening followed by selective escalation.

Security leaders should avoid replacing one vanity metric with another. An overall accuracy score hides error direction. A dramatic productivity figure can hide review burden. An impressive exploit success rate says little about safe code.

A credible evaluation should disclose at least five things: false-positive rate, false-negative rate, coverage, validation method, and performance by weakness category. It should also identify refusals and invalid outputs instead of silently removing them.

Coverage affected one AWS result. Most configurations returned valid answers for at least 98% of samples. GPT-5.6 Sol under proof-of-exploit prompting covered 93%, because a provider safety filter declined some exploit-construction requests.

That detail shows another production constraint. Security agents sometimes need to reason about harmful techniques to validate defenses. Model safety controls can block legitimate evaluation, creating missing results that must be measured rather than ignored.

For enterprise buyers, the best near-term position is controlled assistance. Let AI prioritize, explain, and assemble evidence. Keep human verification on high-risk code paths, especially when deployment context or business logic determines whether an attack works.

The value proposition then becomes narrower but more defensible. AI can reduce search time and surface hypotheses. It should not receive unilateral authority merely because its output contains confident technical language.

What Security Teams Should Watch Next

The benchmark becomes consequential only if vendors test complete systems, publish balanced error rates, and show that gains survive real repositories.

The first signal is participation. AWS invites developers to run all 14,822 samples and submit predictions for verified scoring. Multi-step systems with tools are evaluated separately from single-turn models.

Independent submissions will reveal whether agentic verification closes the measured gap. If complete systems push both error rates below 10%, the results would support AWS's view that architecture can compensate for weak baseline judgment. If they do not, the trust problem runs deeper.

The second signal is reproducibility. Researchers should examine the released samples, challenge categories, unscored pool, and hidden-label process. Comparable evaluations from independent groups would show whether the model rankings and failure patterns persist outside AWS's construction method.

The third signal is production evidence. Vendors should disclose how many alerts users investigate, dismiss, reopen, and ultimately remediate. Those workflow outcomes matter more than a model's isolated classification score.

The benchmark also gives buyers a better request for proposals. Ask vendors to submit their systems and share verified false-positive and false-negative rates. Then ask how their validation process changes for critical code, environment-gated findings, and unsupported languages.

Developers should watch how tools present uncertainty. A useful reviewer should separate confirmed exploit paths from plausible concerns and missing context. Treating those categories as identical produces avoidable work and hides the system's actual confidence.

AWS AI vulnerability detection research has not shown that AI security review is useless. It has shown why detection without disciplined verification remains expensive and risky.

The next test belongs to product teams and buyers. Demand evidence that a finding survives code tracing, environmental checks, and reproducible validation before it reaches an engineer as urgent work. Will your security vendor publish both kinds of mistakes, or keep selling speed without disclosing the review queue behind it?