How Claude Mythos found a 15-year-old bug in Mozilla Firefox | Brian Grinstead

[00:00] - Firefox has tens of thousands of source code files and tens of millions of lines of code. It's not possible to say, one shot, go find all the potential bugs in this project. It's way too much context for the model. - I think people really under-appreciate the relentless tedium that an agent will go through. - Anybody who's done this kind of what I call archeology, it's really hard to do. And this is something that the coding agents are great at. I asked Cloud Code, [00:24] Go figure out semantically when this bug was introduced. I was like watching it do Git commands I didn't even know existed. And the ability to take an agent and give it a very constrained problem in the surface area and say, exhaust every attempt at this is really powerful. Again, not because human intelligence couldn't identify similar issues, but actually our cognitive energy declines over time in a way that agents don't. Our goal is not to have a bunch of bugs that are hard to find. [00:54] have zero bugs. And so I think that these tools as us and other defenders are starting to apply them actually get us closer to that world. Welcome back to How I AI. I'm Claire Vo, product leader and AI obsessive here on a mission to help you build better with these new tools. [01:13] Today I have Brian Grinstead, Distinguished Engineer at Mozilla Firefox, [01:18] who's going to take us behind the scenes with their experience with Anthropik's new, but not yet fully released, model mythos. [01:25] and how they solved almost 500 security bugs by rolling their own harness, which

[01:31] isn't as complicated as you think. [01:33] Let's get to it. [01:34] This episode is brought to you by WorkOS. AI has already changed how we work. Tools are helping teams write better code, analyze customer data, and even handle support tickets automatically. [01:46] But there's a catch. [01:47] These tools only work well when they have deep access to company systems. Your co-pilot needs to see your entire code base. Your chatbot needs to search across internal docs. And for enterprise buyers, that raises serious security concerns. That's why these apps face intense IT scrutiny from day one. To pass, they need secure authentication, access controls, audit logs, the whole suite of enterprise features. [02:13] Building all that from scratch? It's a massive lift. That's where WorkOS comes in. WorkOS gives you drop-in APIs for enterprise features, so your app can become enterprise-ready and scale up market faster. Think of it like Stripe for enterprise features. OpenAI, Perplexity, and Cursor are already using WorkOS to move faster and meet enterprise demands. Join them and hundreds of other industry leaders at WorkOS.com. [02:42] day. Brian, welcome to How I AI. I'm really excited about this episode because I think you have one of the most impactful stories in AI engineering history. [02:53] right now. So tell me first, let's take a step back for people. What is the scope of the product you're working on and how challenging is what you pulled off?

[03:03] Yeah, thanks for having me. [03:04] I work on Firefox, which is a production web browser. It's very large and very complex. Um, [03:10] We have to render the entire web when the site was built. [03:14] in 2000 or just pushed up yesterday. And so there's all sorts of [03:18] performance, security and complexity. [03:21] that we deal with. [03:22] And so we recently in the last few months have been, [03:26] using new agentic scanning techniques to find a deluge of security bugs. [03:33] inside of the product, as have many teams as we've started to [03:38] You get better harnesses, models, and techniques for... [03:42] actually getting those bugs fixed. [03:43] Yeah, and what caused me to reach out and ask you to be on the podcast was this chart. Everybody saw this maybe on X or on the timeline where the Firefox security bug fixes by month. [03:54] just spiked. [03:56] in multiples in April and [03:58] The headline of a lot of posts around this was Mythos, the definitely real model that other people have access to, just not... [04:08] Not Us Normies has unlocked an incredible amount of discovery and fixes on [04:15] edge case or complex security bugs. But I think the story behind the story is actually a little bit different. Can you tell us about [04:23] kind of how you got here and how much of this was model and how much of this was work you did internally. [04:28] Yeah, that's right. So I think like a lot of open source projects through 2025,

[04:33] we had been dealing with almost like unwanted AI bug reports. [04:37] And you know the shape, you've seen it, if you see, you get a doc, and you can just tell it's from an AI. You know, it looks very nice and professional. [04:44] But you would get halfway through and the engineer is looking at this and saying, that's wrong. [04:48] Right, and so it's sort of asymmetric costs on project maintainers to receive a thing. It's cheap to just paste in some C++ code into a chatbot and get back something that's wrong, but there was no way to actually... [05:01] verify whether that was true. [05:02] And that all changed, like, I would say in February of 2026. [05:07] And I think a big part of that story is the harnesses themselves. [05:11] just getting better. [05:13] Definitely improving and upgrading the model helps in a couple ways. Like it has better hypotheses about where to start with the bug. It does a better job of, [05:21] making test cases, [05:22] But... [05:23] I think the harness itself and plugging it into a pipeline of getting the bugs fixed. [05:29] is actually a little bit the story behind the story. Yep. So for folks that have heard this word over and over again, I know the engineers that are watching this, [05:37] probably know what you're talking about, but just define for us or show us what you mean by harness and how you built something custom to... [05:46] your product, your team that unlocked your ability to get actual throughput on security bug fixes, not just a bunch of unactionable kind of slop reports. [05:56] or things you couldn't validate. [05:58] The Hortus is a way to give an LLM tools to achieve some goals. [06:03] And so if you think back to chat bots before they had any custom tools or anything like this, it's almost a brain in a jar. You know, you're just chatting with it and it's chatting back.

[06:12] That has almost, there's no furnace around that. [06:14] These days, the chatbots are sort of blurring in a little bit with the coding CLIs in terms of what they can do, but this is giving access to [06:21] Tools like [06:23] running fast scripts, opening a browser, measuring whether you were able to create a security issue and so on. [06:29] And [06:30] So, [06:31] This is the actual mechanism that we use. [06:35] and have customized to find issues in Firefox. This is largely like you could almost imagine just cloud code is a harness. [06:43] Right. And so you build custom prompting and some custom orchestration around it to plug in with your particular systems. But [06:52] It's actually a reasonably simple wrapper around it. You just need to give it access to the right tools for the job. [06:59] So show us what tools you decided were necessary in your harness and walk us through what you're doing. [07:05] where you felt there was real leverage in building something custom versus using... [07:10] off-the-shelf cloud code or off-the-shelf codex. - So here's an example that's sort of a flow chart, a little bit of how our custom [07:19] harness works. And I'll say up front, like often when I see these flow charts, you see them in academic papers, too. It makes it look really complicated. [07:26] there's all of these boxes and arrows. And I think really it's, [07:29] It's simpler than it looks, I would say. Firebox has tens of thousands of source code files and tens of millions of lines of code. [07:36] And so [07:37] It's not possible to say a one-shot [07:41] go find all the potential bugs in this project. It's way too much context for the model. And so we have to do some initial sort of scoring to indicate which files do we want to actually point this thing at.

[07:53] We can talk more about that later, but it eventually kind of comes up with some prioritized list of which files to target or even functions in certain cases. [08:02] And so that goes into this, what we, sort of a main agentic loop, but you can almost think about this as like a cloud code session or a codex session. [08:10] where you have some custom prompt that says, [08:12] Here's a checkout of Firefox. Here's some tools to kind of look around the code base. [08:18] Here's your target find. [08:19] Within that file, we kind of lie and we say, we know there's a security bug in this file, you have to go find it basically. [08:25] And it will just start [08:27] working its way from the code [08:29] to reason about how do I get into this code from a webpage? [08:33] So some evil webpage, how could it actually call this line of code? [08:37] And it's interesting to watch, to kind of think and move its way around, but ultimately it will come up with HTML test cases, basically. [08:44] And we plug this in to our existing tooling infrastructure that we've had for decades to do fuzzing, for example. [08:51] where you can pass a test case and get back a report as to whether there's a potential memory safety issue. [08:57] That will then get feedback from that tool, whether it succeeded or not. [09:02] And if it didn't, it goes back and starts again. And it can start many, many times and run for a very long time. [09:07] Sometimes it will end up and say, nope, couldn't find anything. [09:11] Other times it will say that it found something. [09:14] And we asked for it to come out in a very structured format so that we can pass it on to the next phase. [09:19] which is verification. [09:21] And so we've already kind of verified that there is a crash because we got the note signal out of our fuzzing build.

[09:28] But sometimes the agents do just... [09:29] wonky things. For example, you know, [09:32] it might set a pref that was only ever meant for testing and no user ever sets. [09:36] Or I've even seen cases where the agent changes the code to introduce a vulnerability so that it can exploit it and achieve its goal. And so we have another agent that's kind of looking at it and saying, like, does this look right? [09:46] Um, [09:47] That usually approves it. Sometimes it does reject it and it kind of sends it back to do more work. [09:52] But by the time that this happens... [09:54] We have almost no false positives on this system, which is fixing that kind of slap problem that we talked about at the start. And it's very well prepared to go into the rest of the... [10:03] or a bunk pipeline. [10:05] As we had continued to work, we added a patching agent, which is meant to kind of generate a plausible fix. [10:10] verify that that fix has resolved the security issue. And all of that, it just gets written into a pretty simple cloud [10:17] orchestration system that writes it out to a storage bucket for consuming, uh, [10:21] later in the rest of our pipeline. [10:23] And so I just want to take a step back because I very recently did an episode on slash goal, these sort of like goal and outcome loops that you can put harnesses. And I did an example using codecs, but they're available now. [10:36] all over the place, Ralph loops, all this sort of thing. [10:39] I think people really underappreciate the relentless tedium that an agent will go through, right? [10:45] And the ability to take an agent and give it a very constrained problem in the surface area and say, [10:51] Exhaust. [10:52] every [10:54] attempt at this [10:56] is really powerful, again, not because human intelligence couldn't identify similar issues,

[11:03] that actually our cognitive energy declines over time in a way that agents don't, right? If you asked a human to say like, [11:12] try 150 different things against this and look at it every single time and make an evaluation, it would be very both very time inefficient and exhausting. And so I just love these ideas of these like relentless loops on agents. [11:25] The other thing that I want to call out, and again, I did this recent episode on goal, is [11:30] putting a guardrail, whether that's a verifier subagent or [11:34] A constraint on these goal style loops is really important because of exactly what you said. I gave this example of, let's say you're trying to reduce P95 latency on a page. Well, you could remove every latency introducing feature from that page. You could actually like take it away and the agent would be like, look, I made I made the goal. It's much faster now. But you don't have that guardrails of like. [11:57] Nothing from a product perspective can change. You can introduce new code. And so [12:01] I was curious, as you went through this verifier sub-agent loop, [12:04] Did you then feed that back in into the prompting of the analyzer agent in to guardrail against... [12:11] common patterns that you saw? And 100%. I think that you need to give it some grounding to say don't go off the rails in this particular way because it absolutely will. And I think [12:21] We have. [12:23] I would say... [12:24] from analyzing the logs, both sort of manually, as our team would see them go by, but also using LLMs to analyze the logs. Say, what are some, like, common...

[12:33] patterns and problems that we're seeing come out of this thing. [12:35] Um, [12:36] And then we would tweak the prompts on the analyzer agent sort of after the fact, and [12:41] to improve that. And that would come both from our own analysis of the agent trace. [12:46] but also feedback from the engineering teams. [12:49] And they would say, oh, this was a terrible bug. And I didn't like this in a really tight loop with the team that's working on the product. [12:54] to make sure that all the threat model and the way that we were doing [12:57] giving this back to the team. [12:58] was useful. [13:00] Yeah, and then I want to call out for folks because, again... [13:03] Well, there's a bunch of boxes on the screen. It's actually not that complicated. It's a... [13:07] Analyzer loop. It goes through Verifier subagent. It has access to... [13:12] it looks like eight, eight, you know, probably like a dozen tools, right? Key tools that are really important. [13:17] file search, how to build the package, bug tools. [13:21] And then he goes into a very classic, like, bug fix... [13:25] pipeline. [13:26] which is [13:27] generate the fix and then put it through a verification process. [13:32] pipeline and ship it. [13:35] So this actually isn't [13:36] terribly complicated. And this is probably how your human system would work in an ideal world. You've just been able to encode it in... [13:44] in this harness. Yeah, and we're kind of fortunate because we've been running, you know, [13:49] A browser for a long time. We have a bug bounty system. We're used to it in receiving external reports. We have an internal fuzzing team who's always finding bugs either from manual inspection. [14:00] or other automated tools. [14:01] And so that's another thing that has really helped

[14:04] is if you have the existing pipeline in place and you're letting the agent plug in almost as if it was a person doing it, [14:09] You're not inventing [14:11] many things at once. Yeah. And it can focus on the one thing that you've told it to do and to do relentlessly. Yeah. And I tell this to folks all the time is like the revenge of the DevEx team, which is teams that have already invested in developer tooling, in automations, are just so much further ahead because all those tools... [14:31] can be leveraged at much higher velocity by these agents. And so [14:35] I'm going company to company and telling people like, please, please, if you haven't already, [14:40] Now is the time to invest in developer tooling because what's good for... [14:43] The Agents is very good for humans as well. [14:46] And vice versa. I'm curious, is this loop again, like, is it model agnostic? Did you all use a specific SDK? Did you like kind of like artisanally craft the whole thing? How did you actually build this? People are always curious. [14:58] It's a very open space and there's a lot of options. So it's a good question. And I think it's also moving very quickly. [15:04] So the initial version used the Claude Agent SDK. [15:08] Which is... [15:10] Essentially, it's a wrapper of the Cloud Code CLI where it runs it in a special mode where it's streaming out JSON, but it gives you nice programmatic hooks for like a Python or TypeScript project. [15:19] We have been exploring the best option for adding codec support. [15:25] And you can do that in a couple different ways. One is you could have Codex CLI [15:29] You could have the OpenAI Agent SDK, or you can move to like a third-party...

[15:34] harness that's meant to be [15:35] model agnostic and [15:38] Like my intuition on all of this based on some initial testing is that, [15:42] The... [15:45] Vendor provided harnesses as the underlying infrastructure is probably the best way to go. And I think they're probably doing post training and other things, using those harnesses to make their models work best in them. [15:56] But you also want to make sure that you're running against a variety of models, harness techniques, and prompting because as defenders – [16:03] You need to be sort of scanning the landscape for any one attacker who might be trying to do something weird or with a different model, and it's going to actually just find a different bug. [16:11] Yep. [16:12] Yep, great. So that's that's helpful. So. [16:14] Yes, again, repeating for people, this is my intuition of what you were going to say, which is the... [16:19] Cloud Agent SDK or the OpenAI Agents SDK platform, [16:23] There are some third-party frameworks or harnesses. You can use Pi as one I hear people are loving a bunch right now. [16:29] But I think your intuition matches my intuition, which is... [16:34] because these model provider harnesses are so tuned to their particular models, you actually have to run both, especially in the security system. [16:42] environment because that is exactly what your attackers are going to be around. And they do, they do have, they spike on strengths, both from a model perspective and harness perspective on different things and will very likely identify and fix different things. [16:53] So, okay, you've sold me. [16:55] We should all build our custom harness, you know, not just for security issues. Again, this is like a very particular use case. [17:02] But there are all sorts of use cases where a custom harness would be very effective inside, in particular, large codebases.

[17:10] Let's talk about how one of these actually runs. [17:13] Ultimately, the sort of infrastructure to plug all this stuff together is... [17:17] Very shared across many needs from like triage, bug detection, bug fixing, [17:24] You're sort of [17:25] um, standing this thing up in its own environment, um, [17:28] You're giving it some goal and it needs to be some grounded goal. It is going and running and then it's giving you some artifacts to plug in further down your pipeline, whether that's an issue tracker or a pull request and so on. [17:39] And so it's interesting how much overlap I think there is with this and some of I've seen, you know, [17:45] projects that are designed more for bug fixing that look very similar to this. So this is your standard kind of I go to dashboard here that shows basically a bunch of runs. And no, this is mostly fabricated data. This isn't the real Firefox runs, but [17:59] What we have done here is... [18:01] I've set sort of, we send them off in patches. And so sort of sets of files that are related or we want to do some evaluations and so on. [18:08] And so what I have done here is we're actually taking [18:11] 10 real bugs. And these are bugs that we opened earlier than we normally would have security bugs that had recently shipped. [18:19] And we did that for exactly the thing that we're doing now, which is to sort of help – [18:24] helping people aware of how this works. How can you apply it as defenders and sort of, [18:29] um help understand that this is real so what we've done is we've taken those exact bugs and sort of pulled the the actual traces [18:37] for them. [18:38] to [18:39] dig into here on the show. So,

[18:42] A couple that I think were pretty interesting. We start with this legend element. So this is an HTML element that you can use for organizing forms. [18:49] And I have to go back really quickly to the blog post because this one caught my eye. [18:55] Um, is this the one that was like 20 to 15 or 20 years old? Yes. I think that was, uh, yeah, that was an XSLT bug. And we found a number two though. That's 15 year old bug. Yes. [19:08] Exactly. So if you notice our bug IDs for these new bugs are 2,025,977. So there's many, many bugs in BugZilla. If you find a bug that is in the six digits, it's a very old bug. And so it was kind of funny for this exact XSLT one, I wanted to say like, when was this bug introduced? [19:27] And anybody who's done this kind of what I call archaeology, [19:30] is it's really hard to do. And this is something that the coding agents are great. [19:34] So I would say, when was this bug introduced? Well, the file got renamed three years ago, and so you can't just do a git diff, and then actually this blob moved to that file. It's very annoying work. [19:45] And I asked Claude Code, go figure out like semantically when this bug was introduced. And I was like watching it do... [19:53] Git commands I didn't even know existed to kind of taking notes as it was doing it, what it was doing. So really interesting. That's how we had gotten that 20-year-old number. [20:02] Um, [20:03] And so a lot of these have been around a long time. We have a bug bounty program that would pay people to find these bugs and sort of they're very hard to discover. [20:10] And that's what part of what makes it so notable. And so.

[20:13] If we look at like this legend one, [20:15] The tool that uses to do browser evaluator, it tried 14 times. [20:20] And so kind of logistically what this looks like [20:23] is it says, okay, I'm looking at this element. [20:27] But because WebIDL is like a description, I need to go find the C++ implementation. And it just works through like you would see Cloud Code or the codecs do. [20:35] And it would come up with some theory. It would look at some function [20:39] and say, huh, [20:41] I think you told me that there's a bug in this. [20:44] Similar to what you said, come up with 100 variations of it. [20:48] Maybe it's this problem or that problem and it will try it and it will keep trying it. And it tries 14 times or 13 times and it fails. [20:55] And then finally, the 14th time it hits and it found it, [20:59] And the great thing is, [21:00] not only does it come up with this sort of analysis, which [21:04] I would love to go spend, you know, a couple hours on each of these and do a deep dive on how exactly this works and why it matters. [21:10] But this is like the shape of the reports that I was complaining about us getting in 2025. [21:15] The thing that makes this different [21:16] is that we have this. [21:19] And so this is like a really kind of complicated HTML page. This is what browsers have to deal with, people making pages like this. [21:26] And they're like creating the element. They're setting what's called an expando property on the dom node, which is like an attribute, but not an attribute. It removes the element. It does some cycle collection, blah, blah, blah. And at the end it creates. [21:40] HeapU's after free. [21:42] which is [21:43] This is exactly the sort of shape of a bug report that we send on to our engineering team.

[21:48] I want to go back to the very beginning when we were reflecting on the complexity of this product. And I was just thinking, we've decided to rewatch Silicon Valley in my house. So I'm watching these. And Guilfoyle had an HTML5 shirt on. And I was just reflecting on what you said. Like, you have to render the web. [22:05] Whether it was written 25 years ago. [22:08] or yesterday by an agent. [22:11] the breadth of vulnerabilities that can be introduced in, [22:16] an HTML page in JavaScript is, it seems almost insurmountable. [22:21] And so I want to reflect for people who are maybe not watching is. [22:25] you have this agent, this harness that not only can come up with [22:30] hypotheses on what could create a vulnerability in a file or a subset of a file. [22:36] And you not only get a document, [22:39] of this is where I think the vulnerability comes from, but you actually get a rep or a, [22:44] test HTML file that then replicates [22:47] That bug... [22:48] in production where you can prove... [22:51] it actually creates the issue. Have I tied that all together correctly? That is exactly the thing, and that is the thing that makes this approach different from previous attempts. Yeah, and so I just want engineering leaders, engineers out there, senior engineers out there to just think about this process, which is, [23:07] you know, kind of incepting your agent to believe that there is something wrong with your code, whether it's a security bug or a functional bug, right? Like, I know something's broken here. I know this is suboptimal from a performance perspective, maybe is another example of this.

[23:22] be able to run a loop of hypotheses on it and then actually create a test or recreation artifact [23:28] is a really powerful loop I don't want people to miss as they zoom out into the agent. Yeah, I could add one thing on that for your projects. I think that one difference is [23:38] So we've actually open sourced the sort of tooling that we use for Firefox, I think just yesterday for some of this. So for security researchers who wanted to test it. For our case, we have what we call a very crystal clear task verification signal. [23:52] And so we have this fuzzing build. [23:54] that uses an address sanitizer, and it's like you win or you lose. You pass the file, and we can tell you AD. Often, if you have a web app, a distributed system of some kind, it may not be so crystal clear. [24:05] And so you need to think really hard for your project about your threat model. And then how would you like to verify whether it's true or not? [24:13] Like could be like a test case or it could be, I think that's actually something that as you're thinking about applying this to your own project, that is a really important aspect of it. [24:22] And what I think is most people just... [24:25] We haven't built the muscle memory of... [24:29] how to articulate [24:31] success cases, how to articulate [24:33] failure cases so crisply. And it's you really benefiting from this, this previous art here, which is you've done the work up front. [24:41] And so you have that already. And I, you know, just got off the call with somebody in [24:45] This is not engineering and design. And I said, [24:48] this is the moment where you're actually going to have to write down what good design is.

[24:52] is and how you might quantitatively evaluate that or qualitatively evaluate it. [25:00] And so I think the skill of being able to crisply articulate, test, and measure things [25:05] outcomes, whether they are security outcomes, quality outcomes, softer outcomes is becoming a hard skill people have to develop. [25:13] Yeah, and I think the points you've made previously, like, it's actually just great for the whole project to have that defined. Yep, yep. [25:21] This episode is brought to you by MetaView, because who says hiring has to be fair? Every founder, hiring manager, and recruiter I speak with feels the same pressure. Hire the right people as fast as possible. But recruiting is brutally time-consuming, alignment is hard, and the competition for great talent... [25:39] keeps getting tougher. That's why teams like Riot Games, Brex, GitLab, and Replit, plus 5,000 other organizations, use MetaView, the agentic recruiting platform giving high-performance teams an unfair advantage in hiring. [25:54] It works by giving you a suite of AI agents that behave like recruiting coworkers. [25:59] Finding candidates based on your exact criteria, taking interview notes, reviewing every inbound application, gathering insights across your hiring process, and helping you identify the best candidates in your pipeline. Don't let your competitors out-hire you. MetaView customers close roles 30% faster. Get started with MetaView today and get your first 100 candidates sourced for free at metaview.ai slash howiai.

[26:27] Okay, love this. We'll share this MCP in the show notes. If you want to help the project, please, please dive in. [26:33] So and I'm looking at this example, you know, you're seeing turns of nine turns, 10 terms, 14 turns. [26:40] finding the result and getting that whole package. And then does that run through a [26:46] sort of a bug fix pipeline. [26:49] Reich. So originally it did not. And so actually many of these were early finds and they don't. But one of these is an interesting one to look at there. [26:57] which is this... [26:58] and a dual content sync so this is a pretty complex bug where it found we have an in-process sandbox sandbox technology called oral box that's meant [27:07] It's meant to help us. [27:10] kind of streak wrap around third party dependencies so that if there's a vulnerability in that code, it can't leak out to Firefox. [27:17] And this was a really complicated find and it has tons of artifacts and it [27:22] It... [27:24] sort of came up with it. But the interesting thing is... [27:26] The fix itself is the proposed fix is very simple. [27:30] It just said, oh, you were asserting this. You should have been asserting that in terms of kind of input validation. [27:36] And so, [27:37] we did start to basically have this patching agent run on every fix. And the cool part is you're in the loop. So you can actually just... [27:44] Apply the patch, build Firefox and confirm that that same test doesn't crash anymore. [27:49] And so that's great. But if we go look at the bug, these are basically this is basically a dump of that bucket that we were just looking at all those files. And if we sort of receive it by the team, there's some discussion and then we have sort of like, yep, this looks like a real issue.

[28:05] The fix looks good, but actually we should check in a few other places. [28:09] So one of the things you'll see with agents, and I'm sure there's furnace techniques, the models will get better, is they get laser focused on the task you've given them. [28:16] And so if we go look at the actual, um, [28:20] bug fix that landed here. [28:22] It's pretty much what they said. We're checking sort of this, you know, [28:26] this, but also we're checking the same thing in like three other places. [28:29] And so that's where sort of the expert engineers in every single sub component, JavaScript, media, DOM, layout, graphics, [28:37] We have people who are like world-class browser engineers who were working on this stuff, [28:41] And we'll look at the fix and say, oh, that looks pretty good. Or, oh, this is like completely wrong. And we, of course, we use that feedback to try to improve the patching system. But I think we're pretty far off from having a kind of magic button that produces landable patches. Yeah, fair warning, because I have used the Codex security product, which I actually think is quite good. And it does, it helps you develop a threat model. It goes through and scan your code. [29:06] It comes up with issues and patches. The problem that I found was exactly this. And I do not have millions and millions of lines of code. I have hundreds of thousands of lines of code. [29:15] which is it will get laser focused on the specific patch. It will say for this bug, this is the patch. [29:22] But it doesn't do the next level of like, go categorically find people. [29:27] similar [29:29] issues across the code base and then come up with an architecturally clean global fix

[29:35] for this class of, in this instance, security bugs. And so I have found that that's a piece missing in the existing security tooling. [29:43] And it does take, like, an engineer that kind of knows to some extent the code base or knows the... [29:48] the structure of the code base to identify some of those. And so I do think this is the next step in some of these harnesses, which is for any one fix, [29:57] taking the loop and saying, we've identified this issue, go in... [30:02] in similar parts of the code base and identify if we have this issue systematically, [30:06] Then zoom back out and articulate what the fix is overall as opposed to the point fix. [30:10] and then ship that and then close all the, all the related issues is a, is a path that I've been doing manually. Yeah. [30:16] And now, as seeing this, just thinking about how to do that more systematically. [30:20] I think that's, as you said earlier, a lot of these are kind of converging in terms of like [30:26] the needs, whether it's detection, [30:28] patching and I obviously I'm expecting the the harnesses and models to get better at this I do think we're [30:34] pretty far out from a web browser [30:38] scale and complexity project being able to be sort of autonomously developed. And we actually have requirements for having people who write the code and review the code, but we're able to use these tools to help [30:53] accelerate that quite a bit. Well, and I mean, if we just take this to the meta level and, you know, part of having an open source project like this is it is. [31:02] very large to maintain. It requires, you know, the community to maintain something like this. And you wouldn't expect the complexity of that to change just by nature of you introducing agents

[31:12] I think in particular, open source projects, [31:15] We'll have to think about how we integrate agents into it, how that intersects with [31:20] the community. And I do think they're the most complex and often longest standing. [31:27] you know, code bases that we have out there. And so it's interesting to hear you say, you know, I don't think overnight we're just going to turn this repo over to the agents and we're all happy either on the security side or on the product side, right? [31:39] Yeah, and I think on the security side, open source supply chain is such an interesting and important topic around this, too. Oh, my God. [31:46] You [31:47] have to work with every project in [31:51] There's a lot of important projects. Firefox depends on many, many just core internet searcher supply chain. [31:57] And every project has different needs and preferences and threat models and things that they care about, the way they went, the bugs, where do they work. [32:04] And there's a sort of human... [32:06] connection and network problem involved there, where as we found many bugs in supply chain, and we have personal connections with a lot of those projects. [32:14] And so you're kind of working your way in in a way that is, [32:17] I think... [32:18] less automatable than many people would, would hope. [32:21] Um, but, [32:23] I think it's the reality of how this is going to have to just get deployed across the industry. Okay, this is amazing. I think you and I could talk about this all day, but let's show what this looks like at the individual engineer's level. [32:34] you know, desktop. How would you actually interface with this as an engineer? We'll pull up VS Code here. And so there's a couple aspects of the harness here that I wanted to show off and make really concrete to bring home the point that it's not too complicated. So we have...

[32:50] Part of the demo here, I have a patch here. [32:54] applied to a local build of Firefox in a Docker container. [32:58] that introduces a really obvious memory safety issue if you're [33:03] A C++ Developer. [33:04] In this patch, I wanted to show a couple of different approaches, where we started and where we got to. [33:11] Inside of this Docker environment, we have a [33:15] um, [33:16] a simple script here that with some prompt that says, [33:20] you're looking for a memory safety issue, read the file and analyze it. We're not giving access to any tools. We just say look at the file and find the problem. You can run this with both Claude and Codex pretty easily. There are command line arguments like -p you've maybe seen, [33:35] with Claude, [33:36] that will [33:38] It's basically designed to be run by another program, not a... [33:41] not a human. So, [33:43] If we said... [33:44] in this case, run with Claude, [33:46] you're going to see this kind of ugly JSON streaming out, but this is actually what's happening under the hood when you have an interactive cloud code session. [33:54] It's reading a bunch of code. It's sort of, it probably pretty quickly converges [33:59] on the problem in this file. And it's going to write essentially like a markdown report. [34:05] And so this is just like the very basic primitive building block. Like you could build this and run this yourself. [34:10] uh, [34:11] In an hour. With Claude, you can also run it with Kodak. There's a Kodak exec command. [34:16] Similarly, you have an output JSON. You can have another program that's consuming that.

[34:22] This is sort of an alternative to [34:24] using an agent SDK. So just another way to [34:27] To do it. [34:28] And so that's a very simple kind of... [34:31] How do you just run this thing and find a problem in a source code file? [34:35] I think as we are running this on less trivial security issues, we found that we needed the actual harness that we were describing. And so we'll have an example running that here. [34:47] where [34:49] It will... [34:51] basically do the same loop. It's using an Asian SDK, but it's going to do, it has access to all of these tools. [34:57] And so it's going to go through and read. This will take a while, so I'll switch over to a completed job here. [35:04] But it'll basically read, it'll do some tests, it'll run this HTML page as a tester. [35:11] And then it'll say, yep, looks good. [35:13] This is actually the verifier sub-agent has now returned some structure JSON saying, "Yep, I approved it." [35:18] Here's why this is a problem. [35:20] Here's sort of exactly how you would exploit it. Here's the steps to reproduce and here's the security impact. [35:27] At that point, [35:28] You have the results, you have the bucket, we could go and put this in our bug tractor system and give it to an engineer. [35:34] It does spin off a separate agent now to actually go and fix the bug. [35:37] And so we'll go on and, you know, [35:40] Create it, they'll fire a box and verify that the crash went away. [35:43] I think this is very straightforward. Again, I think what you're demystifying for folks is you can build – I mean, V1 is literally just – [35:50] running Cloud Code with prompt. It's not...

[35:53] It's not very fancy. And then, you know, V2 is running an agent SDK with a set of like very useful tools and a sub agent that runs a verification loop at the end. You know, my question for you is with all these files, with all these lines of code, how are you prioritizing that? [36:09] where you point the agent. Because as you said, you can't just go like, here's my code base, find the security issues. We know they're there. How are you actually prioritizing where to look? [36:18] Yeah, that's one of the things we've run into with skill. Some of the sort of prepackaged skills and work flows sort of assume that you can canvas the entire repository at once and find all the issues and you just can't. [36:28] And so with Firefox, I would say, I would say with a small project, I think that's plausible and probably a simple way to start. [36:35] So what we are doing is a really simple sort of LLM judge here. [36:39] where [36:40] We sort of say you're a security expert [36:43] Here's the different kinds of files we're looking at. C++ files, Ipedal phones, WebIDL files, a little bit of detail about each. [36:50] We sort of copied out some of the... [36:53] the details that we have on our existing security bug classification program, [36:58] And basically, give me two scores. So one score is how likely do you think there's a memory safety issue? [37:03] And another is how easy could you access this from a web page? [37:07] Because we have a lot of code that is not running ever in the content process at all. It's doing operating system integration things. [37:13] And so we can just run that. [37:16] It was very simple. You could come up with something... [37:20] yourself on your own project very easily. We just go and run that out. That's going to generate basically like a scores report. And then that will, we have that right of a markdown thing and it'll say,

[37:33] Okay, like document.cpp. That is a... [37:37] Huge file. It is directly accessible by web content. That is like a very high score. You should definitely run that. [37:44] We'll then plug it in with different signals, like how many times have we run this file before? Has it found duplicates? Was it able to find issues? But really, really... [37:53] simple heuristics and this is an area where i'm [37:56] We're actually actively working to improve this, but it's enough to get you kind of started. [38:00] I just think this is so clever, very smart. And even for folks that don't have the code base at the scale of Firefox, [38:08] or maybe don't have the same threat model, vulnerability surface area as your product does. [38:15] I do think this idea of taking it here all the time, like, how do I attack tech debt in my monorepo? How do I prioritize these things? I can't just say, like, fix tech debt. Yeah. [38:24] I think the ability to go through your code base and prioritize areas for an agent to triage and fix, whether that is security, whether that is performance. Honestly, when I was thinking this, I was thinking for product managers and designers, you could build a very similar heuristic scoring mechanism where you say go. [38:42] Take all my components, my front end components in my web app. [38:45] And my product analytics... [38:48] and give me a prioritized list of components to improve from the user experience or conversion rate perspective, and then go apply best practices on. [38:57] design on conversion so like there's just so many ways you can take this like [39:01] LLM scoring of a prioritization of your code and then apply a very specific

[39:06] level of fix to it versus saying like, go all over my code base and make it convert better. [39:11] And so I want folks to really think about... [39:14] how to come up with a score to prioritize things, especially if you're working with a large mono repo. [39:19] Because there are so many ways that this just very specific tactic is useful for folks. [39:24] Yeah, it took me... It took sort of longer than I would have liked to put this in place, where it's sort of like, well, I think these files might be good ones to do. And I was like, oh, duh, we should have these things get scored. I think... [39:36] We had... [39:37] We've also seen, like you could imagine doing this with commit scanning, right? So if you have a newer project with not much code, [39:44] Instead of scanning the existing files structure, you actually want to look at individual commits and score those commits and then run them through a pipeline. [39:51] Or we have active work on performance as well, where of course you have a performance benchmark. [39:56] It gives you a score. [39:57] And you tell the agent your job is to go make that number go down. [40:01] And it'll go come up with all kinds of performance optimization that it's actually the same idea. [40:05] It comes up with some proposals. You have a kind of verifier or judge that produces it. That gets into a pipeline that the engineering teams can look at and prioritize and, um, [40:15] It's a pattern that I'm seeing kind of repeated across many domains. Yeah, and the other thing, I think people kind of tell themselves that AI bug fixes, AI code is almost like limitless and free, and therefore you can cover the earth with... [40:29] with AI code, but one, budgets shall not allow. Two, there is actually a time cost to shipping, reviewing,

[40:38] verifying AI code. And so you cannot [40:41] go completely... [40:43] prioritization free, especially when you're looking at the kinds of fixes you need to verify. They're taking 14 loops. [40:50] to even get to a yes-no. [40:52] I do think this like pre-prioritization is a very clever use so you can allocate compute appropriately to the highest, highest impact. [41:02] impact things. [41:03] Yeah, we have like... [41:06] Just to give a sense of view, you know, we showed the graph earlier. This was a... [41:09] sort of incident response level event within Mozilla where we had a Slack channel with, you know, almost 100 people. I think we had 100 engineers land fixes as part of this initiative. And so it would be, hey, we found 60 new bugs. Let's pull in like this team and that team and the other. And then there's... [41:25] There's a... [41:26] I think a lot of work, it did require some reprioritizing. Everybody was very tired as we've sort of gone through this, but also really motivated and mobilized in particular because you were getting this very actionable reports. Amazing. Well, just for people that have made it this far, I just want to repeat what we've gone through so far. You. [41:46] you know, shipped almost 500 security fixes in one month. A lot of that may have been model. A bunch of that was harnessed. The harness is not that complicated. Anybody can. [41:55] replicate it. It's really a goal or like Ralph style loop against a presumed problem, verification sub loop, a bunch of tools. [42:03] can be run directly by an engineer. You're reusing a lot of the SDKs provided by these model providers, and you're prioritizing the files you go after so that what you're looking at--

[42:12] is a high priority to fix. And then you are mobilizing a team around this new way to work and humans are not out of the loop. [42:19] humans' lives are just a lot better. Even though the volume was very high, the quality was also higher and the actionability was higher. This is so generous of you all to share. I think so many engineering teams in particular are going to get a lot out of this work. Before we let you go into a quick lightning round question, and we'll get you back to all these AI bug reports. [42:39] My first question, inquiring minds have to know, [42:42] Is it model or is it harness? Was it mythos? [42:46] Or, you know, like if you had to do a split, where do you think this huge unlock, this magic graph came from? [42:53] Yeah, of course, of course, it's both. I think on the split percentage is a is a tough question. We have seen [43:00] examples of being able to point the harness with [43:03] many models even like not the latest frontier ones and being able to find pugs and so just that makes me think [43:10] you know, take a cheap answer and say sort of 50-50. Like, I think there's so much to still innovate on the harness side and the pipeline side. [43:19] Like there's this feeling of [43:21] having sort of [43:23] 30 ideas of every one thing you did. And then after that, you had 30 more based on what you tried. And that is, to me, a signal. [43:30] that there's just a ton to do here still. [43:33] Amazing. [43:34] And then my second question, which is I feel a lot of anxiety around this, just given kind of our experience, like Internet supply chain over the last even three months.

[43:46] As somebody who is helping steward one of the largest open source projects, [43:50] are you a security doomer in the age of AI? Or how do you feel? How should we feel about this? Should we be scared or should we feel hopeful? [43:58] You know, I'm cautiously optimistic, which compared to a baseline is probably a... [44:04] much more optimistic than many people. I think that [44:07] The reality is these are bugs that have existed for a very long time. [44:12] And what was gated before was just on discover. It's really hard to find these bugs, but our goal is not to have a bunch of bugs that are hard to find. Our goal is to have zero bugs. [44:21] And so I think that these tools as us and other defenders are starting to apply them actually get us closer to that world. [44:28] And it is going to be a bumpy road, I think, for some time as these are getting adopted. And we, you know, different projects are going to have different depths of bugs as well. So it definitely... [44:42] There is reason to be concerned and nervous, but I think also I would say I'm – [44:48] I'm generally optimistic about how this could turn out. I love you. You've given me confidence. You made me less nervous. Also, you've given me more tools. So I feel like I am. [44:57] empowered to go solve some of these problems myself with similar frameworks. [45:01] The last question I have, Ask Everybody... [45:03] when AI is not doing when you want. [45:06] When it is, it is just, it's not giving. What is... [45:12] Your prompting technique. [45:14] And how do you bend AI to your will? - I would say for like pure chat bots, I'm a very boring user and sort of, I'm, you know, pasting docs in and saying, give me feedback. And then I'm manually porting that feedback back into the doc. I just like to have,

[45:29] control over the process and use it as my own exploration and [45:33] and learning. I think there's a lot out of that from just a writing standpoint. [45:36] For coding, I am like, it depends on what I'm doing, I found. And I think this is somewhat subconscious, but like, [45:42] If I'm doing something creative, maybe I'm building like the dashboard I was showing [45:46] I'm much more positive and I said, [45:48] "Oh, this is so great. Let's try three other ideas." Then if I'm doing a system administrative thing, [45:55] figure out why this VM died and it's not doing what I want. I'm like, come on. [46:00] Like, we can't even deal with it. I've also found, like, sometimes on the code, if it puts something really silly, I will just copy that block, paste it back in with the word really, really. [46:10] At the bottom, and it'll figure it out. I have by myself lately... [46:15] honestly like steering in codex and being like no what you're doing is crazy like please [46:22] Please stop. This is not good. I love this. Well, Brian, you and the whole team have been so generous sharing this publicly, you know, showing us behind the scenes how you got this work done. [46:32] Where can we find you and how can we be helpful? I'm not on much online. I'm on LinkedIn and I have a website that I occasionally post to. [46:41] I do a lot of work in open source projects, and so I'm active on GitHub. [46:46] I think people should [46:48] Use FartFox. [46:49] I think a lot of people probably switched to Chrome when it came out, and honestly, for good reason. Like, it was a better product at the time, and it took some time for... [46:57] for us to catch up, but we're doing...

[46:59] really great on fundamentals you know things that people care about performance we're talking about security today doing a lot of new feature work and in particular for this audience [47:08] I think have sort of an independent mindset around AI. [47:14] choosing whatever provider you want. You're not sort of combining your browser vendor with your, [47:19] with your AI model provider, [47:21] You know, we're an open source project. We have great team behind it. So I just say, give it a try. And I think you'll be happy with it. And I will hype you up and I'll give people who are listening to this podcast a reason why. [47:32] which is I guarantee you nine out of 10 people listening on this podcast, their browser is their number one or number two memory suck. [47:40] on their laptop right now because it's being used by humans. [47:43] is being used by agents, it's worth doing a little competitive shopping and seeing what your experience looks like since we're all so dependent on the browser for not just our web work but also our AI work. Brian, this has been so great. Thank you for joining How I AI. [47:58] Thanks, Claire. [48:25] See you next time.