Mozilla's Firefox Agent Pipeline: 8x More Bugs Found, Fixed
How Mozilla's Agent Pipeline Finds and Fixes Firefox Vulnerabilities
Brian Grinstead is a Distinguished Engineer at Mozilla and one of the people behind the agentic security pipeline that now scans Firefox for vulnerabilities. In this conversation with OpenAI's Clint Gibler he walks through the whole system: how targets are chosen, how a finding is proven, how duplicates are removed, and where engineers still do the work. The headline number: "we're on the order of an 8x increase right now from 2025 to 2026 for both discovery and, importantly, for fixes."
Pwn2Own as the fire drill: Mozilla treats the annual Pwn2Own hacking contest as a rehearsal for a real exploited bug. Before the 2026 event, OpenAI's cyber team filed a few Firefox bugs. Mozilla fixed and shipped them quickly, and several contest entries turned out to rely on exactly one of those bugs. Nobody compromised Firefox. Grinstead's lesson from it: "different models find different bugs, even if you've scanned the code multiple times."
Choosing what to scan: Going through the source tree file by file doesn't work. Mozilla first had an LLM score each file for risk: is it exposed to web content, what are its memory safety characteristics. The prompt uses the threat model documentation Mozilla had already written for engineers and outside researchers. A simple scheduler combined the scores with scan history and emitted the next 50 targets.
A crash gate, then a judge agent: Each agent runs in its own VM with the Firefox source and Mozilla's fuzzing toolchain. It forms bug theories, mostly by static analysis, tests them, and discards the wrong ones. It can only leave the loop with deterministic proof, typically a test case that crashes Firefox. That gate can be gamed: Grinstead has seen an agent patch the code base to introduce a crash and then trigger it. So a second agent checks the work and grades severity against Mozilla's threat model. The result: "we actually have a tiny false positive rate." Engineers are not spending an hour on a plausible report that turns out to be wrong.
Deduplication became the bottleneck: Mozilla used to jump on every high-severity report. At this volume, triage had to be automated too, and deduplication was harder than expected: similar crash stacks can be different bugs. "The best thing we've found so far is we ingest them all into a local database and give an agent access to it and ask it to figure it out." When a finding is marked a duplicate, Mozilla re-runs it after the other bug's fix lands to confirm it no longer reproduces, which catches false duplicates.
Stronger models re-rate old bugs: Bugs first rated moderate or low have come back as high severity, because GPT-6 Cyber found a way around architectural hardening Mozilla "thought was bulletproof." That reorders the fix queue and shows where defense in depth needs work.
Variant scans now find the most bugs: A variant scan packages a known bug, fixed or open, and asks the agent to hunt for the same pattern across the code base, for example every security bug fixed in 2025. Commit scans do the narrow version on each new commit. In September, variant scans produced the majority of bugs found, with fewer duplicates.
Patches still need an engineer: The agent writes a patch and a test for each finding, but those patches usually can't land as written. Some are wrong, some fix only the one crash, some miss context. A browser engineer reads the evidence, writes the real fix, and gets it reviewed. Grinstead found no single trick that makes agent patches landable.
A SQLite workbench for the red team: All runs, bugs and engineer comments are ingested into one SQLite file on the red team engineer's machine, and a coding agent answers questions over it: plan the next scan batch from a hint in Slack, or work out why runs failed. Agents are told to write a blockers.yaml file when their environment is broken, such as a missing system dependency, instead of improvising a workaround.
6 Takeaways From Mozilla's Firefox Security Agents
- Old tooling is what agents run on - Decades of fuzzers, sanitizers, debuggable builds and a bug bounty process gave agents tools to use and a team used to high report volume
- Require proof, then check the prover - A deterministic crash gate plus a separate judge agent keeps false positives tiny
- Score targets before scanning - LLM risk scores built on the team's own threat model beat walking the tree
- Run more than one model - Different models found different bugs in code that had already been scanned
- Use every fixed bug as a search pattern - Variant scans became the largest source of findings
- Give agents a way to report blockers - A
blockers.yamlfile surfaces broken environments instead of hiding them
What Mozilla's Results Mean for Agent-Run Security Work
Mozilla's 8x gain came from the system around the model: target scoring, a deterministic verifier, a second agent that judges the first, and a fix process engineers could keep up with. The agents find and prove bugs; people still write the patches that ship. Grinstead's stated goal is zero bugs, on the logic that "every bug that we fix is gone" and commit scanning should stop new ones getting in. For the attacker's side of the same shift, see Wiz CTO Ami Luttwak on AI attacks that finish in 20 minutes, and for another verified security swarm, Ramp Labs' pen testing agents.