What it took to get AI hunting for vulnerabilities
The Chrome Security Team writes that it has been using LLMs (large language models) for years. This announcement marks the point where that groundwork reached from "finding" through to "fixing."
The run-up started in 2023
It begins in 2023, with work on using LLMs to increase the coverage and performance of security fuzzing (throwing large volumes of random input at software to shake out faults). In 2024 came Naptime, with Project Zero, which gave LLMs specialized tooling for vulnerability research.
In 2025, working with DeepMind and Project Zero, they built Big Sleep—an AI agent for discovering vulnerabilities, which found real bugs in the V8 JavaScript engine and the graphics stack.
A bug nobody had noticed in over 13 years
The turning point is placed in early 2026. The team built an agent harness using Gemini (a harness being the scaffolding that gives a model its tools and procedure) and pointed it at the broader Chrome codebase, with higher efficiency and fewer false positives.
One of the bugs it surfaced was a sandbox escape: a flaw that would let a compromised renderer trick the browser into reading local files. It had been quietly living in the codebase for more than 13 years. That moment, the write-up says, cemented the potential of AI-powered vulnerability detection for many on the team.
The Chrome Security team has been using LLMs for years. In 2023 we developed ways to use LLMs to increase security fuzzing coverage and performance. In 2024, we worked with Project Zero on Naptime, giving LLMs specialized tools for vulnerability research. And in 2025, we collaborated with DeepMind and Project Zero on Big Sleep, an AI vulnerability discovery agent that successfully found bugs in the V8 JavaScript engine and graphics stack. / In early 2026, we built an agent harness that used Gemini to find vulnerabilities across the broader Chrome codebase with higher efficiency and lower false positives. One of the bugs we found was a sandbox escape that would allow a compromised renderer to trick the browser into reading local files — a bug that quietly survived in our codebase for more than 13 years! For many of us, this moment cemented the potential of AI-powered vulnerability detection. — from the account of the team's history with LLMs and the 13-year-old bug found by the Gemini-based harness
The accuracy gains came from around the model, not from the model
The striking part is what came next: the improvements concentrate on the surrounding information and structure rather than on swapping the model out. Five are listed.
First, support for model interoperability, so the distinct strengths of both open-weights models and proprietary ones could be used. Second, a knowledge base of Chrome covering every previously identified CVE (the identifier assigned to a known vulnerability) and Chrome's entire Git history—explicitly to extend the models' reasoning beyond their training data.
Third, SECURITY.md files. Developers are encouraged to add them so that models can understand trust boundaries (which parts of a system may be relied upon) and form an accurate view of the threat model. Fourth, a "critic" agent with its own separate context was added to consume those files.
Fifth, the ability to run the vulnerability-finding models over the codebase multiple times—covering both the fact that model output is not identical each run, and the fact that models themselves improve over time.
That the knowledge base includes Git history itself is telling: what was changed, and how, becomes evidence in its own right. The same habit works at a smaller scale—start by putting two versions side by side.
Adding support for model interoperability to leverage the unique strengths of both open-weights and proprietary models. / Building a knowledge base of Chrome, including all previously identified CVEs and Chrome’s entire Git history, to extend the LLMs reasoning capacity past its training data. / Encouraging developers to add SECURITY.md files, which help models better understand trust boundaries and develop an accurate view of the threat model. / Adding a “critic” agent with a separate context to consume these SECURITY.md files. / Introducing the ability to run vulnerability finding models over the codebase multiple times to account for model non-determinism and model improvements over time. — from the description of the five improvements made to the discovery harness
The analysis AI is kept off the network
The safety side is spelled out. Analysis runs strictly against source code at rest, on locked-down machines that lack general internet access. A dedicated setup for these internal scans intercepts every network request and enforces strict allowlists based on the initiating application and the destination, blocking suspicious model activity.
Beyond that, models are never run in an unrestricted mode. Subagents are strictly limited from modifying the local system or reaching files outside designated source-code directories.
This section is worth dwelling on. Anthropic's disclosure of real-world intrusions during evaluations landed in the same period, describing what happens when an AI agent gets outside its evaluation environment. Both are about the same thing: where you place the agent matters more than what you ask it to do.
We’ve built all of this with safety in mind, and have put in place guardrails to mitigate the risk of AI behaving unexpectedly. Our AI analyzes source code strictly at rest, operating on locked-down machines that lack general internet access. We also utilize a dedicated setup for these internal scans that intercepts all network requests, employing strict allowlists based on the initiating application and destination, blocking any suspicious model activity. Furthermore, we never run models in an unrestricted mode, and we strictly limit our subagents from modifying the local system or accessing files outside of designated source code directories. — from the description of the guardrails placed around the analysis AI
Automating the sorting and the fixing
The more bugs you find, the more the downstream clogs. Much of the announcement is really about how that downstream was handled.
Triage that took 5 to 30 minutes was split into four stages
Triage—sorting incoming bug reports—historically took anywhere from 5 to 30 or more minutes per report and relied primarily on human expertise. That has been shifted toward an automated approach blending rule-based systems with AI.
The process splits into four phases. Filtering out the noise (checking for spam, duplicates, and whether the report clearly describes a Chrome security vulnerability). Reproducing bugs (checking for a proof of concept, testing on the specific OS and browser versions affected, and attaching details such as stack traces). Enriching with metadata (when the bug was first introduced, and its severity rating). And automatic assigning (routing to the correct component and human owner).
The severity guidelines themselves were made clearer so they could be applied automatically. Developers can still modify a severity rating they believe is wrong, and can add context through SECURITY.md files.
The four phases of automated triage (per the official write-up)
Historically, triaging a single security report took anywhere from 5 to 30 or more minutes, and relied primarily on human expertise. We have been increasingly shifting our triage process towards an automated approach that blends rule-based systems with AI to increase throughput and accuracy. / The automated triage process is broken down into four key phases: / Filtering out the noise. The system checks if an incoming bug is spam, ensures it meets intake criteria (e.g. is not a duplicate), and verifies that it clearly describes a Chrome security vulnerability. / Reproducing bugs. Next, the system checks for a proof of concept. Reproducible bugs are tested on the specific operating system and browser versions they affect. Based on this, the system attaches further details such as stack traces to the bug to help inform the fix. / Enriching the report with metadata. The system adds essential metadata to the report, such as when the bug was first introduced and its severity rating. To help this process scale, we’ve made our severity guidelines clearer and easier to apply automatically. We continue to allow developers to modify the severity rating if they believe it is incorrect, and to add context to help models reason about security boundaries using SECURITY.md files. / Automatic assigning. The system automatically routes the issue to the correct component and human owner. / While it's hard to measure precisely, we estimate that this new process is saving hundreds of hours of developer time per month, allowing our team to focus on other security priorities. — from the account of prior triage times, the four automated phases, and the scale of time saved
One agent proposes the fix; another critiques it
The fixing side is a multi-agent setup. After initial build steps pull in context from the specific issue, a fixing agent returns multiple candidate fixes. Then a critic agent evaluates which fits best and produces further artifacts for developers to judge by.
The two run in a loop that mimics a typical code review—checking not only that the code is functional but that it complies with Chromium and Google style guidelines and other local conventions.
On top of that, test-writing agents write tests for the fixes. Because they can confirm tests pass across the full array of supported Chrome platforms and configurations before a developer reviews anything, this is said to save up to weeks of developer time.
After initial build steps that bring in context from a specific issue, we run a fixing agent that returns multiple candidate fixes. / A critic agent then evaluates which would be the best fit, producing other relevant artifacts for developers to evaluate the fix. / The fixing and critic agents work in a loop that mimics a typical code review process to ensure that code is functional and compliant with Chromium and Google style guidelines, as well as other local code conventions. / Test-writing agents help write tests for fixes. These agents can ensure that tests work across the full array of Chrome supported platforms and configurations before a developer reviews the fix, saving up to weeks of developer time. — from the description of the fixer, critic, and test-writing agent setup
1,072 in two versions—past the previous 23 combined
The result is the number from the top. At this point LLMs are generating candidate fixes for most vulnerabilities, dramatically increasing the rate of security fixes in recent Chrome releases.
Across Chrome 149 and 150, 1,072 security bugs were fixed—more than the total across the prior 23 milestones combined.
Integration into continuous integration (the practice of building and checking automatically on every code change) has progressed too. Big Sleep and CodeMender are natively integrated into CI, running every 24 hours across all code changes. In May alone, more than 20 vulnerabilities were blocked from reaching production, including one classified as a critical S1+ issue.
External reports have risen as well. All categories of bug reports increased gradually through early 2026, and by March the year's total had passed all of 2025. In response, Google reworked its Vulnerability Reward Program to steer researchers toward submissions that add to what is already being found internally.
At this point, we have LLMs generating candidate fixes for most vulnerabilities, dramatically increasing the rate of security fixes in recent Chrome releases: / In the last two milestones, Chrome 149 and 150, we have fixed 1072 security bugs, surpassing the total number of security bugs fixed across the prior 23 milestones combined. / We have partnered closely with Google DeepMind and Project Zero for years, including on BigSleep and CodeMender. These tools are natively integrated into our continuous integration (CI) system, running every 24 hours across all CLs to proactively detect security bugs. This integration has yielded significant results: in May alone, we blocked over 20 vulnerabilities from reaching production, including a critical S1+ issue. / In early 2026, we saw a gradual increase in all categories of bug reports, but by March, the shift was apparent: we received more bug reports than we had in the entirety of 2025. This led us to change our VRP to focus researchers on bug submissions that are additive to what we are finding internally, and easily ingestible by our newly automated processing pipelines. — from the fix counts, the results of CI integration, and the rise in external reports with the VRP change
Once it is fixed, getting it delivered becomes the weak point
Speed up the fixing and the next bottleneck surfaces. The back half of the announcement is spent there.
The moment you fix it, the attacker gets a hint
Once a fix lands and is visible in the public open-source codebase, attackers can reverse-engineer the diff and build an exploit before the fix reaches users' machines. These are "N-day" attacks, and the interval is commonly called the "patch gap."
Because fixes committed to the main tree typically take weeks to reach Chrome Stable, narrowing that gap is described as a critical part of the strategy. Depending on severity, fixes are merged directly from the main tree into the active stable release branch, which is continuously monitored for new crashes or regressions.
Delivery frequency is rising too. Major milestones are moving to a two-week cadence with weekly security updates. Even that is judged insufficient against fast-moving, AI-powered attacks, so a shift to two security releases per week is being piloted.
Once a fix has landed and is visible in the public open source codebase, attackers can start to reverse engineer and exploit the bug before the fix reaches users’ machines — so called "N-day" attacks. This is commonly referred to as the “patch gap.” Since fixes committed to the main “tree” typically take weeks to reach the Chrome Stable channel (what the vast majority of our users run), minimizing this patch gap is a critical part of our strategy. / Based on their severity, security fixes are merged directly from the main “tree” into the active Chrome stable release branch, which is continuously monitored to prevent new crashes or regressions. / We are in the process of transitioning to a two-week cadence for major Chrome milestones, with weekly security updates. However, in the face of fast-moving, AI-powered attacks, our delivery cadence must accelerate even further. To meet this moment, we are piloting a shift to two security releases per week. — from the explanation of the patch gap and the increase in delivery frequency
What is left at the end is the time users spend not restarting
Even with faster delivery, one gate remains. Chrome pioneered silent background updates in 2008: new binaries download and stage on disk with minimal user intervention, and apply at the next restart.
That is exactly the problem. Against the 1–2 days triage, fix, test, and release now take, the time spent waiting for a user to restart is a significant contributor to N-day exploitation risk. Everyone has reasons to put a restart off—it interrupts work, it needs scheduling, and it is rarely anyone's top priority.
Hence dynamic patching, which aims to eliminate the need for a full browser restart in most cases. It leverages Chrome's multi-process architecture to sequentially replace background child processes—the Renderer and GPU, for instance—with updated binaries on the fly.
Alongside that, work is under way on saving more state locally for seamless session restore, and on finding opportune moments to restart automatically. In Chrome 150, a change shipped that takes advantage of macOS keeping applications running in the background after all windows close: if Chrome detects a pending update in that windowless state, it restarts itself.
In 2008, Chrome pioneered the concept of silent, background software updates: new binaries are automatically downloaded and staged on disk with minimal user intervention. At the next restart of the browser, the update would be applied and the user would be protected. / However, compared to the 1–2 days it takes for triage, fix, test and release, the time spent waiting for the user to restart Chrome can be a significant contributor to N-day exploitation risk. / Investing in "dynamic patching" that will eliminate the need for a full browser restart in most cases. By leveraging Chrome’s multi-process architecture, dynamic patching sequentially replaces background child processes (like the Renderer and GPU) with updated binaries on the fly. / For example, in Chrome 150, we rolled out a change to take advantage of the unique application state on macOS where applications typically continue running in the background even after all windows are closed. Now, if Chrome detects a pending update while in this windowless state, it automatically restarts. — from the account of silent background updates, restart-wait risk, dynamic patching, and automatic restart
In closing: for Chrome's vulnerabilities, AI changed more than the speed of finding
The 1,072 figure draws the eye, but read as a system, discovery is not the only thing that changed. Sorting, generating candidate fixes, writing tests, delivery frequency, and even the restart wait were all pushed at once. The judgment behind it is visible: making discovery faster is pointless if the downstream clogs.
The other thing worth holding onto is that what the AI produces stops at a candidate fix, and humans decide what ships. Separate the fixer from the critic, run them through a loop shaped like code review, write the tests first, then hand it to a developer. What is automated is not the judgment—it is the work of assembling what the judgment needs.
In the same window, DeepSeek released a coding-focused model and a self-propagating prompt attack targeting Copilot was reported. AI writing code, AI fixing code, and attacks aimed at AI are all running in the same place. This announcement is a concrete demonstration that those three now share one worksite.
