Stronger with every update: How we’re making Chrome and the web safer in the AI Era

We’re living through a massive shift in the software security industry. Large Language Models (LLMs) are unlocking unprecedented capabilities for automated vulnerability discovery, scaling far beyond the limits of human security expertise, and requiring new approaches for staying ahead of attackers.

This means deploying AI models at scale to find and fix hundreds of security bugs, faster than ever, with the goal of achieving greater resilience and comprehensive remediation.

Here’s how we’re doing it.

The Life of A Bug

Some software bugs have security implications. While a purely functional bug might result in a frustrating UI freeze, a security bug (or vulnerability) can be used to build an exploit. Exploits allow attackers to perform malicious actions on a victim’s computer, such as reading private data, or controlling their machine without their knowledge.

Once a security bug enters the codebase, its life cycle proceeds as follows:

• The bug is found.
• The bug is triaged.
• The bug is fixed.
• A new update of Chrome with the bug fix is released.
• Chrome is restarted and the update is applied.

Our goal is for every one of these steps to happen as quickly as possible.

Finding vulnerabilities

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 there, we improved on our vulnerability finding agent harness by:

• 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.

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.

AI-powered vulnerability detection complements our existing security testing infrastructure. For example, fuzzing continues to be especially effective at finding bugs that arise from long-range interactions between disparate parts of our codebase, or those requiring a combination of seemingly unrelated operations.

We also want to continue to reward external researchers for their expertise and creativity in finding the most challenging and impactful vulnerabilities via the Chrome Vulnerability Reward Program (VRP). 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.

Triaging vulnerabilities

As we discover more security vulnerabilities with AI-powered tools, we’ve simultaneously used AI to scale and automate validating, triaging, and fixing bugs. 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:

1. 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.
2. 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.
3. 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.
4. 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.

Fixing vulnerabilities

Across Google, developers share the responsibility of prioritizing security fixes with the security team, but scaling bug discovery requires an equally scalable bug fixing process.

To achieve this, we rely on multi-agent workflows throughout:

• 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.

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.

Releasing fixes

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.

Even with this pace, proper public disclosure remains paramount. Every security bug that reaches Chrome Stable, regardless of whether it was discovered internally or reported externally, is documented and disclosed publicly as a standard best practice. We are working on automating the generation of release notes and CVE descriptions from security bug fixes to eliminate manual bottlenecks and shorten the window between vulnerability discovery and public disclosure.

Applying updates

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.

People have understandable reasons to delay restarting Chrome. A restart can be disruptive, requires scheduling in-between tasks, and is rarely the top priority at any given moment. To eliminate this friction, we are pioneering ways to shift the burden away from the user by:

• 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. Stay tuned to learn more as we research and develop this feature.
• Exploring ways to ensure a seamless session restore even in complex cases, by saving more state locally.
• Finding opportune moments to restart automatically, when we can guarantee a seamless session restore. 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.

Our long-term vision is a browser that is always up-to-date – continuously and dynamically patched, and automatically restarted during opportune periods of minimal disruption. While we’re working on this, you can keep your Chrome up to date by clicking on the update message in the top right corner.

For enterprise customers looking to keep Chrome up to date, we recommend that IT admins:

• Apply the RelaunchNotification policy which prompts users to restart Chrome to apply a pending update, escalating from a gentle reminder to a forced restart over a set timeframe.
• Utilize the Chrome Extended Stable Channel for highly sensitive environments where software changes must be vetted.
• Leverage the OS-agnostic dashboard provided by Chrome Enterprise Core or Premium to track fleet-wide browser versions and manage updates at a more granular level.

Prevention is better than cure

Beyond fixing individual security bugs, we’re also investing in the mitigation and elimination of entire classes of security bugs, as well as in preventing them from landing in the first place. With AI coding advancements, we believe there are exciting opportunities to accelerate projects that would have previously taken years, or never happened.

Memory safety mitigations

Chrome is executing on a two-layered memory safety strategy: hardening our runtime environment to neutralize legacy C++ vulnerabilities, while shifting to memory-safe languages for long-term architectural resilience.

The vast majority of the Chromium codebase remains in C++, making immediate toolchain and runtime mitigations our critical first line of defense. We have long prioritized memory-safety engineering at scale, deploying hardened standard template libraries and pioneering technologies like the MiraclePtr family to neutralize Use-After-Free (UAF) vulnerabilities. AI-powered vulnerability detection only reaffirms the need for such technology.

Our C++ defensive roadmap is focused on three pillars:

• MiraclePtr & MiracleObject Expansion. Having already driven a major reduction in UAF bugs via MiraclePtr, we are expanding this paradigm to more libraries such as Skia, ANGLE, Dawn, C++ iterators and std:: containers. We are also actively deploying MiracleObject with the aim of neutralizing up to 90% of UAF vulnerabilities on the GPU main thread, deliberately trading localized runtime performance for temporal safety.
• Spanification. To systematically eliminate Out-of-Bounds (OOB) spatial safety errors, Chrome has undertaken a massive "spanification" effort, migrating legacy pointer-and-size constructs to compiler-enforced std::span types. Currently, 97% of first-party Chrome code compiles cleanly with strict unsafe-buffer warnings. We are now pushing these requirements downstream, expanding spanification into foundational codebases like Skia, ANGLE, and Dawn.
• Structural & Allocation Hardening. We are working on integrating checked math for calculations tied to memory allocations to block integer overflow avenues. Concurrently, Chrome is implementing an additional level of heap partitioning to strictly segregate pointer-containing types from non-pointer types to make it harder to exploit UAF bugs.

While C++ safety enhancements provide an immediate shield, we believe that runtime mitigations will hit diminishing marginal returns within the next few years. Runtime checks are inherently more expensive than compile-time guarantees, and even a heavily mitigated C++ binary requires rigid, performance-throttling sandboxing to comply with the Rule of Two.

The long-term solution is shifting the codebase towards memory-safe languages like Rust, focusing on the following core tenets:

• Rust flywheel. Developers cannot be expected to entirely absorb the velocity friction of engineering in a new language ecosystem. As such, we are building a centralized Rust SDK that exposes foundational Chromium APIs and tooling directly to Rust. Our aim is to turn Rust into a routine, frictionless engineering choice for new components.
• Targeted “bug nest” eradication. Rust is being deployed strategically to replace code segments that exhibit high historical bug density (such as complex data parsers, image codecs, and font stacks).
• Enabling high-privilege modularization. By writing new modular components in Rust, Chrome can safely execute complex features inside high-privilege processes (like the browser process) without the performance penalties of sandboxing, breaking the constraints of traditional C++ architecture.

In addition to Rust, we are also exploring options like implementing the browser’s top-level user interface using HTML, CSS, and TypeScript to further reduce dependencies on traditional C++ frameworks.

Catching security bugs before they land

Bulk scanning of a code base cannot keep pace with Chrome’s high-traffic development velocity. To account for this, we’re also deploying AI-powered bug-finding capabilities to identify and prevent bugs as close to code submit-time as possible. Part of Chrome’s continuous integration (CI) and commit queue (CQ) pipeline, these defensive models automatically scan diffs to prevent new vulnerabilities by performing actions like suggesting spanification fixes, flagging dangling pointers, and enforcing numeric safety.

Additionally, a major challenge in large-scale software engineering is the “latent security issue.” Code that is safe and robust in isolation can be transformed into a critical vulnerability by an entirely unrelated, minor logic change elsewhere in the tree. By utilizing continuous, LLM-powered semantic analysis within the CQ, Chrome can intercept these compound risks before they land in the tree, catching the subtle or complex interactions that traditional static analysis misses.

Securing the internet

Keeping the web safe involves more than just securing Chrome. Google has been a long-standing supporter of open source projects and communities to ensure better security outcomes for all users. Most recently, Google joined others in donating $12.5M to the Alpha-Omega project in support of enabling maintainers to have access to the tools and support they will need in order to respond quickly to vulnerability reports. Google was also a founding member of the Akrites project, which aims to lower the burden on upstream maintainers by providing a centralized clearinghouse for vulnerability reports and a security incident response team.

On the Chrome team, we feel this responsibility acutely — the Chromium Project is the largest open source project on the planet. To put the sheer scale of this challenge into perspective, Chrome has more than 2,300 third-party dependencies across Chromium and satellite projects like the V8 JavaScript engine, the BoringSSL cryptography library, and foundational graphics components like Skia, ANGLE, and Dawn. About 1,700 of those are shipped to users in some capacity, woven into a wide spectrum of products from Android devices to edge computing platforms and massive cloud enterprise stacks.

To keep these dependencies patched, we rely on automated vulnerability scanning pipelines. These pipelines ingest data from Google's internal feeds as well as several external monitoring feeds, including the U.S. government's National Vulnerability Database (NVD) and the open-source focused Open Source Vulnerabilities (OSV) database.

Now more than ever, relying on reactive monitoring alone can leave a dangerous risk gap. Since the best way to stay on top of vulnerabilities and their patches is to keep third-party dependencies fresh, this year, we are starting to move all Chrome third-party dependencies onto automated update pipelines that proactively roll them to their latest upstream versions. Automation always requires guardrails, so we will also be using safety signals from projects such as Google’s Open Source Security Intelligence Platform (GOSSIP) to ensure that we are accounting for other risks in the third-party open source software ecosystem.

Moving forward

While this dramatic change in software security brought about by LLMs might be startling, an increase in bugs found and fixed is not a sign of failure. Every bug found and fixed is one less foothold for an attacker. But discovering and fixing a bug is only half the battle — we must also ship the fix and apply the update for users faster than adversaries can exploit the bug, and invest in projects that mitigate or eliminate classes of bugs through accelerated release cadences, dynamic patching, and opportune restarts, we are driving toward a browser that is continuously protected without disrupting the user.

The AI era has undeniably intensified the software security threat landscape, but by combining rapid deployment mechanisms with deep structural defenses, we are ensuring the advantage remains firmly with defenders. With this, Chrome and the broader web become safer with every update.