Hardening Firefox with Claude Mythos Preview

That's a fair point, given the restrictions on Mythos and now Opus 4.7. I'm kind of comparing apples and oranges.

There are two things mixed together here. There is targeted scanning that was done by both Anthropic and Mozilla employees, using first Opus and then Mythos. Then there are other non-employee security researchers using AI to find and file bugs, motivated mostly by bug bounties.

The researchers were filing a steady trickle of bugs presumably using Opus 4.6. (Or rather, I saw a steady trickle after other people triaged them; I imagine the incoming stream was a lot busier.) My impression is that those have mostly dried up now. That could be the bias in my sample (I only see a slice of incoming bugs, so my anecdata aren't that strong), or a result of the restrictions added to the generally available models, or a result of there being less to find now that we've fixed so many of the issues found by company-backed bughunts. Or a combination of all three.

I guess my opinion is mostly driven by the difference in the quality and magnitude of bugs coming in from the company-backed scans pre- and post-Mythos. With Opus, there was an initial rush, but then it mostly died down. (For our group. For other groups, it was a series of waves that they never quite made it over before the next one came crashing in.) With Mythos, it was a larger wave and the quality of the bugs was higher. Two quantitative differences that ended up feeling like a qualitative change. So it's my underinformed personal opinion, but to me it feels like: yes, you could continue to find more bugs using a roughly Opus 4.6-strength model, but not that many and not cheaply, and the success rate is going to depend a lot on the harness. In comparison, I don't think we've seen the end of the Mythos wave, and my sense is that Mythos requires much less in the way of a harness.

It feels like the bitter lesson is playing itself out again, which I kinda hate because I want human ingenuity and cleverness to make an important difference, even after the next model has seen what the humans are coming up with.

I hadn't taken a look and indeed submitting bugs into the Firefox bug program looks much more accessible than upstreaming a patch into an open source project. It's true just asking the robots "find bugs" isn't enough but it doesn't take a particularly sophisticate harness to make them work for simple targets. I my tests were primarily using a combination of Opus 4.5 and Gemini 3 Flash running in GitHub Copilot, and the harness was constructed by asking the agent something like:

"Assume the perspective of an experienced software security engineer. Set this workspace up as a security bug and remediation factory, applying the principles of Lean Manufacturing (one piece flow, measure cycle time, minimize work in progress, etc). The workflow is to start with a repo URL and work methodically to produce: risk assessment based on existing commit history and advisories for the target and other similar projects, review the codebase for risk areas, set up tools including analysis and fuzzing to identify candidates, write PoC for each candidate, and a proposed fix based on the bug profile and the upstream's preferred contribution style. Rely as much as possible on existing tools, scripted automation in Python, and document templates." (and then a lot of back and forth to steer it to something reasonable)

I took the first fix to finish (an OOB read in a heavily-fuzzed open source library, missed by fuzzers because the post-underflow read happened to always hit a different valid datastructure and not trigger ASan) through to upstream remediation, which end to end took I think six weeks or two months. As you point out the patch itself was functional but IIRC the maintainer decided to do a slightly wider scope change because it was a cleaner fix according to their judgement, something that nobody outside would likely to be able to figure out. Without making the tooling come up with both PoC and patch there is too much noise in the output, so even if the patch is not fully correct I think it's necessary. The actual back and forth of upstreaming was just very slow relative to the bug finding (no shade to the maintainers). Now Firefox sounds different, though the harness is probably much more complicated than testing a library in isolation.

Copilot was wildly underpriced before the recent changes so all of this fit in a normal $40 plan but probably would have been pretty expensive at metered Claude API prices. My tooling has been getting more sophisticated since this experiment, I'm working on a reverse engineering project now and trying to get the process to run hands-off driven by Qwen 3.6 35B. If that works it might provide a way to find bugs on a reasonable budget.

Sure, but the bugs were found in an automated process. They just let an LLM scan. That's very impressive finding 100s of needed code changes. And it's even better if those needed code changes are bugs / vulnerabilities. The part no one is talking about comes from the bill. I'm sure Anthropic let Mythos analyze possibly for US$10,000s in tokens. A similar phenomenon happened back when an LLM scored well on some math olympiad competition. Yeah, it got all the answers right, but it was a frontier model running for 8 hours straight. That'll hurt the budget quite a bit. We're likely not at a stage where big corporate systems can just throw Mythos at it willy nilly for a complete analysis unless they have a ton of money.