Mythos Found 271 Firefox Bugs; Remediation Couldn't Scale

In Brief

Mozilla attributes 271 Firefox 150 vulnerabilities to its Claude Mythos discovery pipeline, and reports fewer than 15 false positives in total.
For memory-corruption findings the filter is a deterministic success signal: the agent iterates until an Address Sanitizer build crashes, and candidates that never crash never reach triage. Validation signals for the other disclosed bug classes are not publicly documented.
Findings reach human review deduplicated and triage-ready, but remediation stayed at two engineers per patch — a loop Mozilla reports it has not found automatable.
On the evidence in the public reporting, replicating the pipeline turns less on model access than on existing infrastructure: sanitizer builds, a fuzzing harness, bug-tracker integration, and the headcount to absorb the patch flow.
Compute spend, finding-filtering mechanics, and per-commit CI economics remain undisclosed in public reporting.

Why This Matters

Mozilla’s Behind the Scenes Hardening Firefox with Claude Mythos Preview post is the first detailed operational case study of a working production AI-assisted vulnerability-discovery pipeline at the scale of a tier-1 codebase. Mozilla’s main-blog framing piece — “The defects are finite, and we are entering a world where we can finally find them all” — situates the engineering story inside Mozilla’s broader security posture. The case study answers what it takes to integrate frontier-model vulnerability discovery into a working security organisation. The answer: more existing infrastructure than capability, with the model itself a smaller part of the working system than the trade-press framing suggests.

The headline numbers are the marketing surface: 271 Mythos-attributed vulnerabilities in Firefox 150’s release, 180 of them rated sec-high, and 423 total security fixes shipped in April 2026 against a prior-year April baseline of 31.

Number	What it measures
271	Mythos-attributed vulnerabilities in the Firefox 150 release
180	of the 271 rated sec-high
423 vs. 31	total security fixes, April 2026 vs. April 2025
Fewer than 15	false positives reported across the discovery campaign
100+	contributors to the Firefox 150 remediation effort
2	engineers per patch — one writing, one reviewing

Key Findings

1. The Success Signal Is the Whole Trick

Mozilla Distinguished Engineer Brian Grinstead’s framing of the architecture is the cleanest practitioner-shaped explanation of why this pipeline works where earlier AI bug-finding deployments failed. Per Help Net Security’s reporting, Grinstead’s verbatim statement: “This pipeline is extremely reliable at filtering out false positives, so long as you have a clearly defined success condition to validate against. Memory corruption issues are especially easy to validate: either you trigger Address Sanitizer or you don’t (in which case you tell the agent to keep working until it does).”

This is the claim the whole operational story rests on, and Grinstead’s qualifier, memory corruption issues, carries real weight. The sanitizer crash is the success condition for that class specifically. Mozilla has not publicly documented the validation signals for the other classes it disclosed. The general principle is the clearly defined success condition; the sanitizer is its cleanest instance. For the memory-corruption class, the agentic harness is permitted to keep iterating until the sanitizer build crashes: modifying its hypothesis, generating new test cases, patching Firefox source to construct exploit conditions. A crash is the discriminator between speculative hypothesis and real vulnerability; a non-crash discards the candidate without ever entering the triage queue. The harness does not need to be right on first attempt. It needs to keep iterating until the deterministic signal flips.

The reason so few false positives survive — fewer than 15 in total, per Grinstead’s reporting in Help Net Security — is that the gate is mechanical, not judgement-based. Mozilla has not disclosed how many candidates the pipeline rejected upstream of that count, so the figure is a count, not a rate.

The practitioner consequence: this pipeline architecture is only available to security teams whose codebase has a working sanitizer build that can be exercised reliably in CI (AddressSanitizer for memory-safety bugs, ThreadSanitizer for concurrency, UndefinedBehaviorSanitizer for spec violations). Mozilla has that because Firefox has been instrumented for sanitizer-driven fuzzing for years.

Teams whose security posture is “we run a static-analysis tool nightly” do not have the deterministic success signal that makes the iterative-until-it-crashes loop work. The corollary for greenfield deployments: budget the sanitizer-build effort first, not the model integration.

The 15-false-positives detail is itself instructive on what does break. Per Grinstead via Help Net Security: “We did see a small handful of false positives, primarily caused by changing some precondition in order to trigger an issue that would otherwise be valid (e.g., enabling a testing preference or using a private API). We’ve seen fewer than 15 of these total, and when we see them we update the harness to prevent similar issues in the future.”

The failure mode is the agent constructing exploit preconditions that real attackers couldn’t reach — toggling a debug flag, calling a private API. The fix is harness-level guardrails on what the agent is permitted to modify, evolved each time a false positive is observed. This is harness engineering at the source-code-modification level, not at the prompt level.

2. The Architecture Is Ephemeral-VM-Per-Target-File, With Hard Containment Boundaries

Mozilla’s Mozilla Hacks post and Help Net Security’s reporting together establish the pipeline shape. Jobs are parallelised across multiple ephemeral virtual machines, each VM assigned to hunt for vulnerabilities within a specific target file, with findings written to a bucket and the VM destroyed after analysis completes.

Grinstead’s verbatim containment description, per Help Net Security: “Any source code changes made to craft sandbox escapes are only used to generate bug reports. They never land in the upstream Firefox source code, nor are they published anywhere outside of the bug tracker. Scanning happens entirely within isolated VMs that have a local copy of Firefox’s open source codebase, with no means to publish their changes. After completing the analysis, any findings are written into an internal database and the VM is destroyed.”

The pipeline shape as described in public reporting: a sanitizer crash gates memory-corruption discovery, findings are deduplicated and triaged in the bug tracker, and humans write and review every patch — adapted from the Mozilla Hacks post and Help Net Security.

The decomposition is one VM per target file — not one VM per agent, and not one VM per run. It is the same shape as the harness primitives the platform layer shipped the same week (sandbox per task, per-tenant durable code, isolated execution), applied to the target axis rather than the tenant axis. It is also the natural concurrency boundary for a discovery campaign: the deduplication and triage layer downstream does the work of combining findings across files into a coherent bug-tracker view.

Two operational details matter for replicability. First, the VMs need read access to the full Firefox source tree, because the agent has to be able to reason about cross-file interactions — but no write access that escapes the VM. The model is permitted to patch the local Firefox tree to construct sandbox-escape proofs; that is how it demonstrates exploitability of latent flaws. Those patches die with the VM and never reach upstream.

Second, Mozilla VP of Security Stephanie Domas, quoted in Stiennon’s writeup, reports that Mythos repeatedly tried to pursue “prototype pollution escape paths” and was thwarted by architectural changes the team had already made. That’s the success signal doing its job in reverse: defensive measures that work register as “agent kept trying, never crashed the sanitizer,” which is correctly classified as “not a finding.”

The scan’s scope is narrower than the codebase-sweep framing in some coverage suggests. Per the Mozilla Hacks post: “Today, our scanning is largely focused on specific areas of the code (files, functions) where we instruct the system to look, based on a mix of human judgement and automated signals.” Mozilla has not published how many target files ran, how many VMs the campaign provisioned, or what it spent on compute.

AISLE’s published numbers on adjacent kernel scans — under $100 in total API cost for FreeBSD and OpenBSD kernel scans plus benchmarking — put a hard number on the inference side alone; AISLE publishes no comparison against labor or infrastructure costs, and Mozilla discloses neither. Still, for a smaller security team starting from a no-sanitizer-build, no-fuzzing-harness baseline, a sub-$100 API bill is hard to read as anything but the cheapest line item.

3. Findings Reach Humans Deduplicated and Triage-Ready

The piece of the pipeline that determines what the human triage queue actually sees is the filtering-and-deduplication layer. What is established by the Mozilla Hacks post and the The Decoder writeup is that the pipeline integrates “deduplicating against known issues, tracking bugs, triaging them, and getting fixes shipped,” and that the inputs to the human triage queue arrive pre-filtered and deduplicated against the existing bug tracker.

TechCrunch’s coverage adds Mozilla’s own account of why the filtering works at all now: the latest generation of tools has turned a corner “particularly now that agentic systems can assess their own work and filter out bad results.” Self-assessment inside the discovery loop, plus the mechanical sanitizer gate, is what keeps LLM-report variance out of the human queue.

Mozilla’s public reporting does not describe the filtering stage’s internal mechanics — the rubric, the rejection-rate distribution, or how much of the filtering is the agent’s own self-assessment versus downstream tooling. This is the same validation problem that’s emerged in agent-CI/CD discussions (GitHub’s defense-in-depth model) for non-deterministic output, ported to the security domain.

4. The Remediation Pipeline Is the Bottleneck, and It Resists Automation

The discovery side scales with compute. The remediation side does not. Grinstead’s verbatim framing, per TechCrunch’s coverage: “For the bugs we’re talking about in this post, every single one is one engineer writing a patch and one engineer reviewing it. We have not found it to be automatable.”

Per the Mozilla Hacks post, over 100 people contributed code to the Firefox 150 remediation effort. The shape of the load follows from Grinstead’s description: 271 bugs, each needing a patch author and a reviewer, some requiring deeper investigation and longer fix windows than others. Mozilla has not said how many engineers worked in parallel or how long a typical fix took, so the throughput of that remediation pool cannot be derived from the reporting.

Mozilla absorbed the April 2026 spike — 423 total fixes versus 31 in April 2025 per TechCrunch and 76 fixes in March 2026 per The Register’s coverage — through what the Mozilla Hacks post describes as “a lot of work and long days over the last few months”: beyond writing and reviewing patches, contributors were building and scaling the pipeline, triaging, testing fixes, and managing the release process for each bug.

This is the operational fact most likely to surprise teams planning their own Mythos-class deployment. The discovery side of an AI-assisted vulnerability program is a budget question: provision the VMs, pay the inference bill, instrument the sanitizers. The remediation side is a headcount and team-discipline question, and nothing in Mozilla’s reporting suggests it scales with discovery throughput: every fix still consumed one engineer to write it and another to review it.

The Register’s coverage frames this as a feature of Mozilla’s approach rather than a limitation — “the agentic harness – the middleware mediating between AI and the end user” is doing the real work of converting frontier-model capability into shippable patches, and the middleware is human as much as it is machine.

The Hacker News piece Mythos Changed the Math on Vulnerability Discovery generalises the practitioner observation: “finding a vulnerability and fixing it are two entirely different workflows, and the gap between them is where most security programs quietly bleed out.” For procurement teams: any Mythos-class capability deployment has to be costed across both sides of the workflow. Discovery is cheap; integrating into the existing bug tracker and doubling patch throughput without quality loss is not.

5. The 20-Year and 15-Year Bug Specifics Are the Capability Signal

The trade-press headline numbers point to capability. The technical specifics of the two long-standing bugs are the evidence that this isn’t just a fuzzing-throughput story.

The 20-year-old XSLT vulnerability (Mozilla bug 2025977), per the Mozilla Hacks post: “reentrant key() calls cause a hash table rehash that frees its backing store while a raw entry pointer is still in use.” This is a use-after-free that requires reasoning about (a) the XSLT spec’s key-function semantics permitting reentrant calls, (b) the implementation’s hash-table-with-incremental-rehash strategy, and (c) the lifecycle of a raw pointer held across the rehash boundary.

The detection path is not “fuzz inputs at the XSLT parser and watch for crashes” but “reason about which API patterns can trigger the reentrancy path and construct a reproducer that exercises the pointer-aliasing window.”

The 15-year-old <legend> element bug (Mozilla bug 2024437), per the same source, was “triggered by meticulous orchestration of edge cases across distant parts of the browser, including recursion stack depth limits, expando properties, and cycle collection.” The reasoning span here is across three subsystems that wouldn’t normally co-occur in a single fuzz target.

Digit.in’s analysis frames the distinguishing pattern as “combinatorial reasoning” — bugs where multiple individually-innocent behaviours combine to create a vulnerability, and where the combination space is too large for random fuzzing to navigate efficiently.

Simon Willison’s read of the Mozilla pipeline post foregrounds Mozilla’s own framing of the shift — just a few months ago, “AI-generated security bug reports to open source projects were mostly known for being unwanted slop” — and the dramatic recall improvement happens to land in exactly the bug categories that conventional tooling has historically failed to surface.

The practitioner takeaway: Mythos’s capability surplus over earlier fuzzing-and-static-analysis tools concentrates exactly in the bug categories that have historically been the residual cost of mature security programs — the bugs that survive because they require reasoning about non-local interactions. For security teams running long-running fuzz campaigns against mature codebases, the question is no longer whether the residual bug-fixing backlog is reachable, but whether they can absorb the throughput when the residual starts being surfaced systematically.

6. Replicability Is About Existing Infrastructure, Not Model Access

Mozilla’s deployment is reproducible by other security teams in principle. Mythos itself is gated under Project Glasswing’s allowlist — a dozen launch partners plus the 40+ additional organisations Anthropic has extended access to, roughly fifty in all, per Anthropic’s Glasswing page.

SecurityWeek’s earlier coverage of the 271-bug result names the launch partner list — AWS, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorgan Chase, Linux Foundation, Microsoft, NVIDIA, Palo Alto Networks — and Firefox CTO Bobby Holley’s framing of the capability cliff, “Encouragingly, we also haven’t seen any bugs that couldn’t have been found by an elite human researcher.”

The frontier-capability ceiling is broadly reachable from a second vendor (the AISI evaluation of GPT-5.5 found a similar level of performance overall — ahead of Mythos on its Expert-tier tasks, behind it on the corporate-range attack simulation). What is not broadly reachable, on the evidence in the Mozilla pipeline post, is the operational substrate that turns the model into useful security work.

Stiennon’s analysis is direct on the point: software vendors with mature codebases can replicate Mozilla’s approach immediately using available frontier models, but the gating factor is existing infrastructure — sanitizer builds, fuzzing harness, bug tracker integration, dedicated security-engineering capacity to absorb the patch flow. The Implicator essay takes the argument furthest: even after Mythos goes broadly available, smaller software vendors will lack the codebase-specific wrapper that turns frontier capability into shippable security work, because they lack the substrate Mozilla spent years building.

AISLE’s nano-analyzer work offers the strongest counter-evidence to the “you need Mythos” framing. Their published numbers: under $100 in API cost for full FreeBSD and OpenBSD kernel scans plus benchmarking, using GPT-5.4-nano (roughly 100× cheaper than speculated Mythos pricing) and GPT-OSS-120B (open-weights, roughly 600× cheaper). Two maintainer-confirmed bugs in FreeBSD NFS RPCsec_gss code, plus a separate 26-year-old memory-corruption flaw in networking-related kernel code (AISLE-2026-8073), responsibly disclosed with severity pending vendor analysis. AISLE’s thesis — “a thousand adequate eyes looking everywhere should find things that one brilliant eye looking selectively misses, even if each individual eye is less perceptive” — is that throughput-via-parallelism on adequate models can match capability-via-depth on frontier models for the long-tail-of-bugs use case.

The implication for practitioner teams is structurally identical to Mozilla’s: the harness, not the model, is the working primitive. But the two harnesses are not the same shape. nano-analyzer’s three-stage pipeline (context generation → vulnerability scan → skeptical triage with grep validation, all parallelised at the file level) shares Mozilla’s file-parallel decomposition and nothing else — AISLE describes it as “one Python file, no agentic loop”, where Mozilla’s defining mechanism is an agent iterating against an executable success signal inside an isolated VM.

7. The CI Integration Story Is the Next Phase

The Decoder’s coverage reports Mozilla’s stated plan to integrate the pipeline “directly into its development process so that every new piece of code is automatically checked before it gets committed.” The Mozilla Hacks post states the same plan in Mozilla’s own words: “In the near future, we intend to integrate this analysis into our continuous integration system to scan patches as they land in the tree.” The shift from periodic discovery campaigns to per-commit scanning changes the operational shape materially.

The economics differ between the two modes. Campaign mode is a parallelisable burst: scan the targeted file set in parallel, surface the existing residual bugs, then remediate over months. Per-commit mode is a streaming workload: every PR triggers a scoped scan against the changed-file set and their reachable dependencies, with a latency budget short enough to gate the CI pipeline.

The agent’s iterative loop — “keep trying until the sanitizer crashes” — has to terminate inside that budget when the scan finds nothing. That means a different harness profile: shallower exploration depth, fewer iterations per file, tighter early-exit conditions when no candidate hypothesis crashes after some configurable number of attempts.

For teams planning their own pipeline trajectory, this is the budget reality check. Campaign-mode scans against a static codebase set the floor for what’s findable; per-commit scans set the floor for what’s preventable — bugs that would have been written but are caught before merge. The two modes are complementary, not substitutable: the campaign surfaces existing latent bugs, the per-commit gate prevents new ones. Public reporting on Mozilla’s per-commit cost model and latency budget remains thin.

8. The Mozilla Pipeline Is the Inflection Point for the “Remediation Capacity” Question

The practitioner question facing security teams in 2026-Q3 is no longer whether AI-assisted vulnerability discovery is a procurement decision. It is whether the rest of the security organisation can absorb the throughput. The Rapid7 analysis on Project Glasswing names the gap explicitly: 48,185 CVEs recorded in 2025, roughly 40% rated high or critical, and — in its own words — “the challenge has not necessarily been a lack of findings, but instead converting a growing stream of findings into measurable risk reduction” — before the AI-throughput multiplier compounds.

The Hacker News piece on the post-Mythos math makes the practitioner reframing concrete: “if the organizational infrastructure for triaging, prioritizing, communicating, and verifying fixes hasn’t kept pace, faster discovery just means a faster-growing backlog of unresolved critical issues.”

CSO Online’s coverage carries Holley’s blunt version of the capability-side framing — “Computers were completely incapable of doing this a few months ago, and now they excel at it” — alongside SOCRadar CISO Ensar Seker’s note that defenders are realizing the attack surface is larger and “more rapidly discoverable than previously assumed.”

Mozilla’s pipeline absorbs the discovery throughput because Mozilla had the substrate to absorb it: 100+ contributors, established sanitizer infrastructure, mature bug-tracker integration, a security-engineering culture organised around fast turnaround. Most enterprise security organisations operating in 2026 do not have that substrate at that scale.

The infrastructure investment list for a security organisation planning a Mozilla-equivalent deployment, derived from the cross-referenced public reporting, breaks into four budget categories:

Category	What you need	What it costs
Discovery substrate	Sanitizer build of the target codebase (AddressSanitizer minimum, ThreadSanitizer and UBSan for broader coverage); existing fuzzing harness to integrate with; ephemeral-VM orchestration that can spin up and tear down at file-target granularity	Months of engineering work if not already in place; ongoing operational maintenance
Pipeline software	Agentic harness with iterate-until-success-signal loop; deduplication against existing bug tracker; severity classification	Public reference implementations are emerging (AISLE’s nano-analyzer is the closest thing to a portable open-source example); custom integration with your bug tracker is bespoke
Inference budget	LLM API spend for discovery (high-volume, high-iteration)	Not disclosed in public reporting for Mozilla’s tier-1-codebase campaign; per-commit mode is a different cost curve
Remediation capacity	Engineering headcount with security context to write patches and engineering headcount to review them; release-management discipline to ship the surge without quality regression	The hardest line item; not buyable with capex

A scoping note: this matrix omits the trust model — how much agency the agent gets within the sandbox, what credentials it has access to, and how its proposed patches are validated before reaching the upstream tree. That territory is covered by the agent-containment scout series and is structurally separate from the discovery-pipeline question.

Practical Implications

What to Build

Sanitizer-driven success signals are the first investment. If your codebase doesn’t have an AddressSanitizer build that runs in CI, the iterate-until-it-crashes loop has nothing to gate on, and the false-positive rate of any agentic harness you bolt on top will inherit whatever variance the LLM provides. Mozilla’s “either you trigger Address Sanitizer or you don’t” test — its success condition for memory-corruption findings — travels to C and C++ codebases broadly, and to Rust via the compiler’s nightly-only sanitizer support, subject in every case to whether the relevant code can actually be instrumented.

For managed-runtime targets, the equivalent is a runtime fault detector — segfault handler, assertion-as-crash, Valgrind-style memory-tracker — that produces a binary signal. Without a deterministic gate, agentic discovery degrades to LLM-generated bug-report slop.

The harness, not the model, is the practitioner-facing artifact. Mozilla’s harness is not open-sourced — the Mozilla Hacks post describes the pattern but not the implementation. AISLE’s nano-analyzer is a portable reference for the file-parallelised, three-stage (context → scan → skeptical-triage) shape, tuned for memory-safety bugs — though a self-described v0.1 research prototype, not a production tool.

The Project Zero / Big Sleep documentation and Google’s Cloud CISO Big Sleep coverage describe a related but distinct pattern — a code-comprehension agent with sandboxed Python script execution for fuzz-input generation, applied to widely-deployed open-source targets including SQLite. OpenAI’s Aardvark launch (October 2025) puts a third vendor on the same architectural shape, with GPT-5 as the discovery model and per-commit CI integration as the deployment mode. The three vendor deployments converge on the same primitives: deterministic verification, per-file parallelism, human-reviewed patch loop.

Budget headcount before model access. The first dollar of value from an AI-assisted vulnerability program comes from the remediation side. A security organisation that can write and review 50 patches per week with current headcount cannot absorb a discovery campaign that surfaces 271 patches in a month.

The practitioner pre-deployment audit: how long from existing-pipeline discovery to verified fix? How many high-severity findings sit in “being worked on” states for more than a week? Can you re-test post-remediation, or do you just close tickets? These questions, raised in The Hacker News piece, don’t require Mythos access to answer meaningfully. They establish whether your organisation has the substrate.

What to Buy

Model access is the cheapest line item. Mythos is gated, but the AISI evaluation of GPT-5.5 finds a second vendor’s model reaching a similar level of performance overall. AISLE’s published benchmarks establish that nano-class and open-weights models can match frontier discovery on a meaningful subset of memory-safety bugs at 100×–600× lower per-token cost. The model is not the procurement bottleneck.

Existing managed-vulnerability-discovery services are increasingly relevant. GitHub’s Copilot Autofix ships an end-to-end CodeQL-detection-plus-LLM-remediation loop with published operational numbers — median time-to-fix dropping from 1.5 hours to 28 minutes per GitHub’s reporting.

The architecture is structurally different from Mozilla’s — CodeQL static-analysis as the discovery primitive rather than agentic-with-sanitizer — and covers a different bug class: alert-shaped findings rather than memory-corruption-class exploitable vulnerabilities. But for teams running on GitHub-hosted code the operational baseline is already there. The right framing: Mythos-class deployments are the new ceiling for discovery throughput; CodeQL-plus-Autofix is the new floor.

What to Avoid

Per-commit scanning without a campaign mode first. The pipeline shape Mozilla used — discovery campaign first, then plan for CI integration — is the right sequencing. A team that turns on per-commit scanning against a codebase with years of accumulated latent bugs will find that the gate fires on every PR, because the agent is surfacing pre-existing flaws, not regressions introduced by the PR.

The campaign mode flushes the residual bugs in a controlled burst; per-commit mode then catches regressions against a clean baseline. Reversing the order produces a CI gate that nobody can deploy past.

Treating the discovery pipeline as a security-product procurement. Mythos-class deployments are not turnkey products. The ArmorCode playbook and related vendor materials are written in a procurement frame — buy the unified-exposure-management platform, integrate with your existing 350+ security tools, deploy “risk-based prioritization.”

That framing is honest about the symptom (vulnerability data needs management at scale) but misleading about the cause: the harness work, the sanitizer substrate, and the remediation-pipeline staffing are not buyable. The procurement decision exists; it is downstream of the build-and-staff decision.

Automating the patch-writing loop ahead of the evidence. Grinstead’s framing — “every single one is one engineer writing a patch and one engineer reviewing it. We have not found it to be automatable” — is the operational bottom line from the Mozilla deployment. Other vendors will ship marketing claims about end-to-end discovery-to-patch automation; the published evidence from the largest production deployment to date is that the patch-writing loop is the human-in-the-loop floor, not the next-quarter automation target. Teams that staff toward the automation premise rather than the human-in-the-loop reality will under-resource their remediation side.

A Note on the Anthropic Gating Posture

Mythos’s gating posture — Project Glasswing’s allowlist, up to $100M in committed model-usage credits, explicit non-availability for general use — is a vendor choice this deployment story depends on. Mozilla is a Glasswing partner; without that, the Firefox campaign as documented could not have happened.

For the broader practitioner population not currently on the partner list, the operational architecture remains reproducible against a second vendor’s frontier model, but the specific Mythos-named numbers don’t generalise. A second vendor reaches a similar performance level per the AISI evaluation; the vendor relationship that includes access plus engineering collaboration is not. The procurement decision for security teams: lobby for Glasswing-equivalent access, build against a generally-available frontier model, or invest in the throughput-via-cheaper-models approach AISLE demonstrates.

Open Questions

The compute-cost curve at production scale. Mozilla’s published reporting does not disclose the inference spend on the Firefox 150 discovery campaign, nor the VM-compute spend across the parallelised scan. AISLE’s adjacent kernel-scan numbers (under $100 in API cost for FreeBSD and OpenBSD scans plus benchmarking) come from a far smaller target, and reporting on Mozilla’s specific compute spend, the per-finding cost curve, and how the campaign-mode budget translates to per-commit-mode budget remains thin.
The filtering-stage implementation. Mozilla’s public reporting establishes that findings reach the human triage queue pre-filtered and deduplicated, but does not describe the mechanics — how much is agentic self-assessment versus downstream tooling, or what the rejection-rate distribution looks like. For practitioners designing their own equivalent layer, the published architecture is suggestive rather than reproducible.
Per-commit operational metrics. The CI-integration phase Mozilla has flagged as the next step is the operational mode most practitioner teams will actually deploy against, but no production reporting on per-commit Mythos-class scanning at tier-1-codebase scale exists yet. The latency budget, the per-commit hit rate, the false-positive rate against deltas (versus against full files), and the cost-per-PR-scanned are all open empirical questions.
The threshold codebase size for replicability. The Mozilla pipeline is documented on a multi-decade-old, tier-1-scale codebase with mature fuzzing infrastructure. The smallest codebase against which the same architectural pattern produces meaningful capability uplift over conventional static-analysis-plus-fuzz is not established in public reporting. AISLE’s nano-analyzer demonstrates the pattern works on tens-of-thousands-of-lines kernel modules; the curve between “kernel module” and “Firefox” is uninvestigated.
The harness as portable artifact. Mozilla has not published its harness code, and there is no public indication of whether it will. For the moment, practitioners replicating the architecture are building from the structural description plus AISLE’s reference implementation. Whether a community-maintained open-source harness emerges, and which licence and governance model it adopts, is the next open ecosystem question.

Since publication

2026-09-01 — Anthropic’s Project Glasswing expansion announcement (June 2, 2026) reports that many Glasswing partners now use the model to write patches, and extends the partnership to roughly 150 additional organizations beyond the initial cohort — moving patch-writing, treated above as remaining on the human side of the automation floor, into the model-assisted column for at least part of the cohort.
2026-09-01 — Mythos 5 shipped June 9, 2026 with published API pricing of $10/$50 per million tokens, replacing the speculated Mythos Preview pricing that the 100×–600× cost-multiple comparisons above are computed against; the cost argument’s direction stands, but its magnitudes now have a real denominator.

Scout: Operationalising AI-Assisted Vulnerability Discovery — What Mozilla's Mythos Pipeline Actually Requires