TL;DR · 30-second read
The Short Version
Google has built an artificial intelligence system trained to find security holes in software, and it is not releasing it to everyone. In one internal test, it found serious flaws in Google’s own systems within two hours, then wrote an attack that worked every time.
That is why only governments and trusted partners will get it at first, through a limited trial.
Google’s bet is that many quick, cheap checks can compete with one slow, expensive one. If so, protecting the apps you use could depend partly on how much computing time defenders can afford.
Google DeepMind announced Gemini 3.5 Flash Cyber on July 21, 2026. The lightweight model is built on Gemini 3.5 Flash and tuned to find, validate and patch software vulnerabilities. It will soon be available through Google’s CodeMender security agent in a limited-access pilot for governments and trusted partners, with access expanding over time.
Google said the model found 55 unique confirmed issues in the V8 JavaScript engine across a fixed number of invocations, or model calls, compared with 47 for mainline 3.5 Flash and 36 for Anthropic’s Claude Opus 4.6. Separately, Google is bringing CodeMender’s foundational capabilities to customers using generally available Gemini models through its Gemini Enterprise Agent Platform.
Executive Summary
Gemini 3.5 Flash Cyber is a specialized version of a smaller, faster model rather than a new flagship. Google positions it as a cost-efficient alternative to large, costly cybersecurity models, arguing that finding deep flaws is a search problem across an enormous number of possible paths through a program’s code. CodeMender calls the model repeatedly, lets sub-agents explore more of those paths, and then consolidates the results into a single report.
That design matters beyond one product launch. If Google’s results hold up, the practical limit on AI vulnerability discovery shifts toward how many model calls a defender can afford to run, and how often. The announcement offers persuasive signals for that view, but the evidence comes largely from Google’s own testing, and it does not include a price.
Access is the other major issue. Google describes the architecture as affordable and scalable, yet it is restricting this model because the same abilities that help defenders could also help attackers. Its exploit-writing result shows why that concern is more than theoretical.
Why the Model-Call Budget Becomes the Constraint
Google’s central technical argument is that finding vulnerabilities means exploring an immense execution search space, meaning the many routes a program can take as it runs. A single expensive call to a very large model can become a bottleneck. A lighter model can be invoked repeatedly, so that an agent examines more code paths and validates what it finds before producing one report.
The V8 test illustrates that logic. V8 is the engine that runs JavaScript, and across a fixed number of invocations 3.5 Flash Cyber found 55 unique confirmed issues, against 47 for mainline 3.5 Flash and 36 for Claude Opus 4.6. That is 17% more than the first comparison and about 53% more than the second. Ten of the 55 were missed by both other models, which supports Google’s claim that the tuned model casts a wider net rather than rediscovering the same flaws. Google also says the model keeps finding new code paths and vulnerabilities as invocations increase. If that holds at a useful rate, the number of calls a team can afford directly shapes how much code it can cover.
This is where security becomes a compute budgeting question. Google pitches the model for frequent scans, time-sensitive launches and commit scanning, which checks code changes as developers submit them. Those uses turn security analysis from an occasional audit into recurring machine workload that grows with a codebase and its pace of change. Security leaders, engineering teams and cloud buyers would need to weigh cost per scan, coverage and speed together. For infrastructure planners, the implied demand profile is many lighter calls rather than fewer heavy ones, although Google has not quantified that demand.
What the Benchmarks Establish, and What They Leave Open
The strongest elements are the V8 count and the Chrome production pipeline test. Google says the Chrome vulnerabilities were not publicly disclosed, which reduces the risk that models had already seen the answers in training data. The Big Sleep evaluation also targets hard-to-find flaws in complex codebases including Chrome and Safari, and Google reports that 3.5 Flash Cyber significantly surpassed both mainline 3.5 Flash and 3.6 Flash.
Each comparison needs careful reading. On CyberGym, a benchmark built around hundreds of real-world software vulnerabilities, the competitive result came from CodeMender calling the model up to five times for one final report, while competitor scores were self-reported by their providers. That is a comparison of differently run systems, not a strictly controlled head-to-head test. Big Sleep is Google’s own team, and those stress tests ran without safety guardrails. Raw counts of unique issues also say nothing by themselves about how severe each issue was or how much each run cost.
Competitor coverage is limited too. Google says newer competitor versions after Opus 4.6 refused the Chrome tasks because of built-in safety guardrails and so are not shown. The results therefore say little about how Flash Cyber compares with the newest competing models on that test. They do point to a separate buying consideration: a model’s usefulness for security work depends partly on what its safeguards allow it to do, and for whom.
Affordable in Design, Restricted in Practice
The clearest illustration of dual-use risk comes from Google’s Cloud Vulnerability Research team. In two hours, Google says, the model uncovered remote code execution flaws, which can let an outsider run commands on a distant machine, in public APIs, and found a memory-corruption flaw in a sensitive production service. It then generated a remote code execution exploit that Google calls 100% reliable and that bypassed two standard defenses: Address Space Layout Randomization, which shuffles where programs sit in memory, and Write XOR Execute, which stops memory from being both writable and executable.
That capability explains the limited pilot, and restricting it is a reasonable response to the risk. It also creates a practical tension with the announcement’s language about helping more defenders. For now, the specialized model is reserved for governments and trusted partners, while other customers get CodeMender’s foundational capabilities on generally available Gemini models. Those organizations are getting a related offering, not the same one, and Google’s own testing shows the tuned model outperforming mainline Flash models.
Finding Flaws Faster Does Not Close Them
Google opens with the concern that AI agents may find vulnerabilities faster than defenders can fix them. A cheaper discovery engine could widen that gap unless remediation scales as well. Each confirmed issue still has to be prioritized, patched, tested and shipped, often by people responsible for systems they cannot change quickly.
Google says the model is tuned to patch as well as find, and that CodeMender is already finding and fixing vulnerabilities in internal codebases including Chrome, Android, Cloud, Ads and YouTube. The published figures, however, emphasize discovery. For buyers, the more decisive measure may be how many fixes are accepted and deployed, and how much human review they need. A low cost per finding would capture only part of the economics.
Background
Google says it has invested in automated vulnerability discovery for years. Its security work includes OSS-Fuzz, an effort with more than 10 years of results; OSV.dev, a database spanning over 700,000 open-source vulnerabilities; the Big Sleep team, which built one of the evaluations used here; and CodeMender, its code security agent. Google says this data helps it train models on real security work rather than synthetic examples, including operating industry-standard tools and reading through millions of lines of code in projects such as Chromium.
Software vulnerabilities are flaws that attackers can use to crash systems, steal data or take control of machines. Defenders have long relied on automated tools to find them, and AI agents are extending that automation into longer and more complex analysis. Because the same skills can serve both defense and attack, access decisions have become part of how these models are released, as has the question of what safety guardrails allow them to do. Source: Introducing Gemini 3.5 Flash Cyber – Google DeepMind, Google DeepMind’s July 21, 2026 announcement of its lightweight cybersecurity model and limited-access pilot.Sources