Amazon Google Security Push Meets an AI Bug Reality Check

Amazon Google security partners joined an AI defense race built around a stark warning, yet only 1.3 percent of studied vulnerabilities reached real-world exploitation.

That number comes from VulnCheck’s analysis of 1,061 publicly attributed AI-assisted discoveries. Researchers matched those findings against evidence of attacks observed outside controlled environments.

The result challenges a central assumption behind the Amazon Google security campaign surrounding Anthropic’s Project Glasswing. AI can uncover flaws rapidly, but discovery does not automatically create an effective attack.

Anthropic still presents a serious case for urgency. Its Claude Mythos Preview system identified 23,019 vulnerability candidates while scanning open-source projects. The company estimated that 6,202 deserved high or critical severity ratings.

Those enormous totals have shaped predictions about an approaching flood of AI-generated exploits. However, the public record currently describes a different transition.

AI is multiplying possible security findings faster than humans can validate, disclose, patch, and prioritize them. Attackers still face the harder work of turning a technical weakness into a reliable operation.

That distinction changes where defenders should focus. The immediate problem is not simply that AI finds more bugs. It is that security teams must separate consequential exposure from expanding volumes of machine-generated evidence.

The Exploitation Data Changes the Story

AI-assisted discovery has increased vulnerability volume without increasing the observed exploitation rate.

VulnCheck examined 1,061 vulnerabilities attributed to Project Glasswing and the Berkeley Vulnerability Research Initiative. It then compared them with its Known Exploited Vulnerabilities database.

The company found 14 vulnerabilities with confirmed real-world exploitation. That equals 1.3 percent of the reviewed group, according to the published exploitation analysis.

VulnCheck said that rate was almost identical to the rate across its broader vulnerability dataset. AI-found flaws therefore appeared no more likely to face exploitation than conventionally discovered flaws.

The comparison matters because vulnerability discovery and exploitation measure different capabilities. A scanner identifies code behavior that might violate an expected security boundary.

A working exploit must trigger that behavior under practical conditions. It often needs to bypass mitigations, reach a valuable system, and operate reliably across target configurations.

Real attackers also evaluate economics. They consider access, development time, exposure risk, available targets, and the value of any data or control they might gain.

Many flaws fail that test. Some require local access, unusual configurations, or privileges that an attacker already needs. Others cause crashes without enabling useful control.

A vulnerability can remain technically valid while offering little operational value. Severity scores alone cannot explain whether criminals will invest in weaponizing it.

Project Glasswing makes this distinction especially important. Anthropic said Mythos Preview produced 23,019 candidates across more than 1,000 open-source projects.

Only 126 Project Glasswing findings had become published Common Vulnerabilities and Exposures records within VulnCheck’s reviewed public data. Just one had confirmed exploitation in the wild.

That narrower comparison does not prove the remaining candidates are harmless. Coordinated disclosure intentionally keeps some details private until software maintainers can distribute patches.

It does show that candidate totals cannot serve as a substitute for verified vulnerability outcomes. They certainly cannot measure how many findings have become dependable offensive tools.

VulnCheck researcher Patrick Garrity described the current impact as real but modest. He argued that AI-discovered vulnerabilities are not inherently more exploitable than traditionally discovered ones.

The findings also expose an important denominator problem. Project Glasswing’s candidate total includes medium and low severity issues alongside its highest-rated findings.

Public CVE counts represent a later stage. Those records generally require validation, coordination, and enough technical clarity to describe an affected product and weakness.

Known exploitation imposes an even higher standard. It requires credible evidence that someone actually used the vulnerability against a real target.

Comparing those stages without qualification creates misleading conclusions. A large candidate pool can coexist with a very small exploitation count because each stage filters different evidence.

The 1.3 percent rate therefore offers a reality check, not an all-clear signal. It says AI has transformed the supply of findings before it has transformed their average operational value.

Amazon Google Security Partners Still Have Reasons to Move Fast

Low observed exploitation does not remove the danger facing Amazon Google security teams and other Project Glasswing partners.

Anthropic introduced Project Glasswing to give selected defenders early access to Claude Mythos Preview. Initial participants included Amazon Web Services, Google, Apple, Microsoft, Cisco, Nvidia, and other infrastructure providers.

The project began with roughly 50 partners. Anthropic later said it was expanding access to approximately 150 additional organizations across more than 15 countries.

Participants use Mythos Preview to examine internal and open-source code before comparable capabilities become widely available. Anthropic calls this an asymmetric defensive advantage.

The company’s concern is straightforward. AI systems can examine far more code paths than a human research team can inspect manually.

A future attacker could apply the same scale without following coordinated disclosure rules. They could also concentrate scanning on internet-facing software with clear commercial targets.

The current exploitation rate describes public evidence, not every private activity. Criminal groups do not reliably announce successful zero-day operations or publish their technical methods.

Confirmed exploitation counts will therefore understate some activity. The uncertainty becomes larger when findings remain confidential during remediation.

Recent events show that AI-assisted offensive work is no longer confined to benchmarks. Google reported disrupting criminals who apparently used an AI model while identifying an unknown software vulnerability.

The operation caused no reported damage because defenders intervened. However, the case provided evidence that criminal actors were testing AI inside a real vulnerability workflow.

The gap between experiments and scalable exploitation remains significant. One detected operation does not establish that attackers can automate the entire process.

Yet defenders cannot wait for exploitation statistics to rise before preparing. Public confirmation usually arrives after an intrusion, forensic investigation, or vendor disclosure.

Amazon approaches the same problem from another operational angle. Its RuleForge system converts vulnerability information and proof-of-concept code into detection rules.

Amazon says the system improved rule-generation productivity by 336 percent. A separate evaluator reduced false positives by 67 percent while preserving true-positive detections.

Those claims come from Amazon’s own RuleForge results, not an independent benchmark. Still, the architecture illustrates how defenders can use AI beyond discovery.

RuleForge divides work among specialized agents for ingestion, generation, evaluation, and validation. Human reviewers retain responsibility for approving rules before deployment.

This workflow targets the missing middle between a disclosed vulnerability and an operational defense. Finding a bug does not automatically produce telemetry, detections, patches, or deployment guidance.

Google is pursuing faster discovery and remediation through CodeMender and Gemini 3.5 Flash Cyber. The specialized model is designed to find, validate, and patch vulnerabilities across large codebases.

Google says the model found 55 unique confirmed issues in its V8 evaluation. Mainline Gemini found 47, while Claude Opus 4.6 found 36 under the reported setup.

Provider benchmarks require caution because model configurations and safety policies differ. Google also notes that some competitor results were self-reported.

Even so, the direction is clear. Major technology companies are building systems that connect scanning with validation and repair.

The 1.3 percent exploitation rate does not invalidate those investments. It shifts their justification from counting bugs toward reducing the time between credible evidence and a deployed defense.

Discovery Is Cheap, but Exploitation Remains a Chain

The central reversal is that AI has weakened the discovery bottleneck without eliminating the exploitation bottleneck.

Modern codebases contain millions of lines, external dependencies, old interfaces, and undocumented assumptions. AI agents can divide that search space and test many hypotheses in parallel.

Anthropic reported that independent security firms assessed 1,752 high or critical candidates from its open-source scans. Of those, 1,587 were valid true positives.

That 90.6 percent validation rate suggests the system produced more than random noise within the reviewed subset. Reviewers confirmed 1,094 as high or critical severity.

Those results support Anthropic’s discovery claims. They do not establish that every remaining unreviewed candidate will survive expert analysis at the same rate.

They also do not show that confirmed flaws are equally useful to attackers. Exploitation depends on a longer and less predictable chain.

First, the attacker must understand the vulnerable component and determine whether reachable targets use it. A library flaw has little value when affected code paths remain disabled.

Second, the attacker must control the required input. Some bugs become reachable through a public request, while others require authentication or local execution.

Third, exploitation must produce a valuable effect. Crashing a service differs sharply from executing code, stealing credentials, or crossing a trust boundary.

Fourth, the exploit must tolerate differences among software versions and deployment settings. An unstable technique can expose an attacker before delivering useful access.

Finally, the attacker must integrate the exploit into an operation. That requires infrastructure, targeting, persistence, privilege escalation, and methods for removing evidence.

AI can assist with every stage, but assistance is not equivalent to autonomy. A model may generate plausible code that fails when environmental details change.

Models also struggle with confidence calibration. Amazon found that its rule-generation model rated almost every candidate favorably until a separate judge evaluated the output.

The same tendency affects vulnerability research. A model can describe an alarming path while missing a condition that makes the path impossible in production.

Anthropic attempted to address that weakness through independent validation. Its reported true-positive rate indicates that carefully designed tools and expert review can control substantial noise.

However, this review creates a new capacity limit. Every serious finding needs reproduction, impact analysis, maintainer communication, a fix, and deployment testing.

Anthropic said a high or critical Mythos finding takes two weeks to patch on average. Some maintainers asked the company to slow disclosures because they lacked sufficient review capacity.

This is where the security burden moves. Machine discovery increases the queue, but human institutions still determine how quickly that queue becomes safer software.

Open-source projects face the sharpest mismatch. Widely used packages often depend on small teams that cannot process hundreds of complex private reports.

Enterprise teams have better control over their own repositories. Anthropic said Claude Security users patched more than 2,100 vulnerabilities during the product’s first three weeks.

That claim suggests ownership and deployment access can shorten remediation. It does not show how serious those findings were or how many proposed patches required revision.

The mechanism therefore favors organizations with mature engineering processes. AI can accelerate work when teams already know their assets, owners, dependencies, and deployment paths.

Organizations with weak inventories will receive more findings without knowing which systems matter. The result can be a larger backlog and slower action on genuine threats.

The Real Risk Is a Triage and Patching Deficit

AI vulnerability discovery becomes dangerous when finding volume grows faster than validation and remediation capacity.

Security programs already manage thousands of scanner results, dependency alerts, configuration warnings, and penetration-testing findings. AI adds another source with greater scale and uncertain calibration.

A team that treats every machine-generated finding as urgent will exhaust its reviewers. A team that dismisses AI output as noisy can overlook a rare, high-impact path.

This creates a precision problem. Defenders need to identify the small set combining technical severity, reachable assets, attacker interest, and credible exploitation evidence.

Traditional severity scoring addresses only part of that decision. A critical flaw in an isolated test system can present less immediate danger than a lower-rated flaw on an exposed gateway.

Threat intelligence adds evidence about active scanning, public exploit code, criminal discussion, and observed attacks. Asset context shows whether the vulnerable component exists inside a valuable service.

The strongest workflow combines these signals. It deduplicates overlapping findings, verifies reachability, and assigns ownership before sending work to engineers.

Google’s risk-based vulnerability blueprint recommends blending vulnerability severity, asset importance, and current threat evidence.

That model addresses the central weakness in raw discovery counts. It asks which finding deserves action first rather than rewarding tools for producing the largest list.

The VulnCheck figures reinforce this approach. During the first half of 2026, the company identified 495 known exploited vulnerabilities across the wider software market.

Content management systems accounted for roughly one-third of those cases. Network edge devices also remained common targets.

Those products attract attackers because they are reachable, widely deployed, and valuable for initial access. Their exploitation economics often exceed those of obscure internal components.

Security leaders should not interpret the AI results as permission to delay patching. Instead, they should distinguish three separate queues.

The first queue covers confirmed active exploitation. These flaws need immediate containment, detection, and remediation because the threat already exists.

The second covers validated, reachable vulnerabilities with credible exploitation paths. Teams should patch these quickly even without observed attacks.

The third covers unvalidated candidates or findings on unreachable assets. Those still require review, but they should not displace evidence-backed threats.

This structure prevents the discovery surge from flattening every issue into one severity bucket. It also gives maintainers a defensible basis for negotiating disclosure timelines.

There is another risk behind the low exploitation percentage. The absolute count can increase substantially even if the percentage remains stable.

If AI produces ten times more valid vulnerabilities, a constant exploitation rate still creates ten times more exploited cases. Percentages can obscure that scale effect.

The reviewed data also reflects an early period. Attackers need time to adopt new tools, build reliable harnesses, and integrate them with reconnaissance systems.

Public access remains restricted for Anthropic’s most capable cyber model. That limitation reduces what the current exploitation data can reveal about widespread misuse.

Anthropic acknowledges that it has not created safeguards strong enough for general Mythos access. The company is limiting distribution while expanding controlled defensive programs.

That approach reduces immediate exposure but creates a measurement challenge. A restricted model cannot reveal how ordinary criminal groups would behave with equivalent capabilities.

The skeptical conclusion must therefore remain narrow. Current evidence does not show that AI-discovered vulnerabilities are inherently more likely to face exploitation.

It does not prove that future systems will preserve the same ratio. It also cannot guarantee that all existing exploitation has been discovered or publicly attributed.

The strongest policy response is neither panic nor complacency. It is building verification and patching systems that can scale before access to advanced cyber models expands.

Google’s Specialized Model Raises the Capability Ceiling

Google’s latest cyber model shows why today’s reassuring exploitation rate cannot serve as a permanent forecast.

Gemini 3.5 Flash Cyber is a lightweight model fine-tuned for vulnerability discovery, validation, and patch generation. Google plans limited access through CodeMender for governments and trusted partners.

The model’s design emphasizes repeated, lower-cost exploration instead of relying on one call to a larger general model. Multiple agents inspect code paths before combining their findings.

Google says this approach fits complex repositories where the search space exceeds what one analysis pass can cover. It also supports frequent scanning during commits and releases.

The company reported a more striking internal test. Gemini 3.5 Flash Cyber examined Google Cloud systems and found remote code execution flaws in public APIs within two hours.

Google says the model also found a memory corruption issue in a sensitive production service. It then generated a fully reliable exploit under the tested conditions.

According to Google’s cyber model results, that exploit bypassed Address Space Layout Randomization and Write XOR Execute protections.

Address Space Layout Randomization changes memory locations to frustrate attacks. Write XOR Execute prevents memory from being writable and executable simultaneously.

Bypassing both controls requires more than recognizing suspicious source code. It moves the system closer to the difficult validation and exploit-development stages.

The result remains a company-reported demonstration inside a controlled defensive program. Google has not disclosed the affected systems or enough detail for outside reproduction.

Still, it weakens any comforting claim that exploitation remains beyond current models. The better conclusion is that exploitation ability exists unevenly and under constrained conditions.

Google also has unusual advantages. Its security teams can access internal code, production context, historical fuzzing results, and detailed vulnerability databases.

That information gives agents better grounding than an outside attacker would receive. It also helps the company verify model outputs against real systems.

Attackers have different advantages. They can focus on exposed products, reuse leaked source code, inspect patches, and accept higher failure rates.

An offensive campaign does not need to understand every finding. It needs one reliable path against enough valuable targets.

This asymmetry explains why the Amazon Google security effort remains relevant despite VulnCheck’s findings. The industry is preparing for capability diffusion, not only measuring current attacks.

Project Glasswing gives selected organizations time to harden critical software before Mythos-level systems become generally accessible. Google is taking a similar limited-release approach.

However, controlled access cannot become the entire strategy. Open models, specialized tools, and improved agent frameworks will continue narrowing the capability gap.

Defenders therefore need systems that reduce exposure continuously. Scanning before release offers more value than adding another alert after vulnerable code reaches production.

Automatic patch proposals can shorten remediation, but humans must review changes affecting authentication, memory handling, cryptography, and trust boundaries.

The winning defensive architecture connects model discovery with reproducible evidence. It then connects evidence with tested patches, deployment ownership, and attack telemetry.

That is a more demanding standard than counting vulnerabilities. It is also the standard most closely tied to measurable security outcomes.

Three Signals Will Show Whether the Balance Is Shifting

The next phase will be measured through exploitation evidence, remediation throughput, and access to specialized cyber models.

The first signal is the proportion of AI-attributed vulnerabilities entering known-exploitation catalogs. VulnCheck’s current 1.3 percent result establishes a useful early baseline.

A sustained increase above the broader vulnerability rate would strengthen claims that AI produces unusually attractive targets. A stable rate would support the discovery-volume interpretation.

Attribution quality matters here. Researchers must distinguish vulnerabilities found by AI from exploits developed with AI after a human or conventional scanner found the weakness.

Those are different capabilities with different policy implications. Poor labeling can make either side of the debate appear stronger than the evidence allows.

The second signal is Project Glasswing’s public remediation ledger. Readers should watch how many candidates become validated advisories, patches, CVEs, or closed false positives.

Anthropic’s Glasswing update reported strong validation results for a reviewed subset. However, the broader candidate backlog remained much larger than its public CVE count.

A faster patch rate would show that disclosure and remediation systems are catching up with discovery. A widening backlog would confirm that human capacity has become the primary security constraint.

Patch quality matters as much as quantity. Rushed fixes can introduce regressions, leave alternate attack paths open, or disclose enough information for attackers to reconstruct an exploit.

Researchers should therefore track deployment and verification, not just patch publication. A fix protects users only after maintainers release it and operators install it.

The third signal is broader access to Mythos, Gemini Flash Cyber, or comparable specialized models. Anthropic and Google currently restrict their most sensitive capabilities.

Expanded availability would create the first meaningful test of how advanced cyber agents behave across a larger population. It would also increase pressure on safeguards and identity verification.

If access expands without a rise in confirmed exploitation, the current reality check grows stronger. If exploitation rises quickly, today’s low rate will look like an adoption lag.

Amazon, Google, and their partners should also publish more outcome-based measurements. Useful metrics include verified findings, time to patch, deployed fixes, and prevented attacks.

Candidate totals remain valuable for evaluating search coverage. They are insufficient for measuring whether a security program reduced practical risk.

For developers, the lesson is to demand reproducible evidence from AI security tools. A finding should include affected code, reachable conditions, impact, and a testable remediation.

For enterprise buyers, the priority is integration with existing assets and workflows. A tool that produces more alerts without ownership or context can increase operational risk.

For open-source maintainers, disclosure pacing and funded review capacity deserve greater attention. AI systems can now generate work far faster than volunteer communities can absorb it.

The Amazon Google security coalition is responding to a credible future threat. Yet current evidence says the immediate crisis is an overloaded defensive pipeline, not automatic mass exploitation.

That distinction should shape spending, product design, and policy. Teams need fewer unranked alerts and more verified paths from discovery through remediation.

Watch the exploitation ratio, the patching backlog, and specialized model access over the coming months. Together, those signals will show whether AI changes attack economics or mainly changes discovery volume.

The practical question for every security team is simple: can your organization validate and fix the most consequential findings before a larger queue hides them?