Defenders Don't Get to Delete the Codebase

Three days after Anthropic shipped Fable 5 as the most capable model it had ever released to the public, the US government told it to switch the thing off. Fable 5 and its stronger sibling Mythos 5 went dark worldwide on June 12, suspended under an export-control directive over national security concerns, while Opus, Sonnet, and Haiku kept running like nothing had happened. Anthropic disagrees with the call, and says the jailbreak that spooked Washington was narrow and that other public models can already do the same thing. You can argue the specifics either way. What you cannot argue is the reason everyone got nervous in the first place.

Mythos is the first model that can hunt down and exploit zero-day vulnerabilities on its own, at a scale no human team matches. In a few weeks of restricted preview it surfaced more than ten thousand serious flaws across real systems, including holes that had been sitting unnoticed in major operating systems and browsers for decades. Put a capability like that in the wrong hands and the fear writes itself. Put it in the right hands, the argument goes, and defenders finally get a tool that lets them find and fix faster than attackers can break in. That is the case the defender-first crowd is making, and on the surface it sounds reasonable. Give both sides the same AI and let the better team win.

It helps to put a number on it. For years the count of zero-days actually caught being exploited in the wild has stayed under roughly a hundred a year, ninety in 2025, sixty-three back in 2022, never once breaking out of that band. That ceiling was never about how many flaws exist in the world's software. It was about labor, because finding a usable zero-day and turning it into a working exploit is slow, expensive, expert work. Mythos removes the labor. Its restricted preview turned up more than ten thousand flaws in a matter of weeks, which does not nudge that yearly number, it changes its order of magnitude. A count that has lived in the dozens could plausibly land in the thousands, and every one of those is a hole somebody now has to close on a system that cannot afford to break while they do it.

That framing is wrong, and it is wrong in a way that matters for everyone building on top of these systems. The counter-argument assumes offense and defense are mirror images, that a defender with a fast model patches as quickly as an attacker with the same model exploits. They do not, and the reason has nothing to do with talent or tooling. It is structural.

Attackers don't carry the downstream

An attacker has exactly one job, which is to produce a bad outcome. Any bad outcome. They do not have to care whether the exploit is elegant, whether it scales, whether it breaks three other things on the way in, or whether the system they just wrecked was load-bearing for a hospital. Collateral damage is not their problem, it is frequently the point. They get to try a thousand reckless things and they only have to be right once. That is the entire shape of offense. No accountability for consequences, no constraint on method, no obligation to leave anything standing when they are done.

Defenders carry all of it

A defender lives in the opposite world. You do not get to carte blanche patch your way to safety, because every change you make lands on a system that people are depending on right now. Before you ship a fix you have to ask the questions an attacker never asks. Does this patch hold up under load, or does it fall over the moment traffic scales? Does it quietly break a downstream service that was relying on the old behavior? Does it violate an architectural assumption three layers away that nobody bothered to document? Does a feature your customers paid for stop working the morning after you deploy? A fix that closes the hole and takes the business down with it is not a fix. It is a different incident with better intentions.

So patches take time. Not because defenders are slow, but because they are responsible for everything the attacker gets to ignore. The attacker optimizes for one variable. The defender optimizes for that same variable while holding a dozen others steady, and the moment one of those others snaps, the patch was a net loss no matter how cleanly it sealed the original flaw.

Run that process once and it is a careful afternoon. Run it against thousands of fresh zero-days a year, each one demanding the same downstream impact analysis before it is safe to ship, and the arithmetic stops working. That is the part that should keep security teams up at night. Not that the holes exist, but that the responsible way to close them does not scale the way the reckless way to open them does.

The Son of Anton problem

There is a moment in Silicon Valley where the team builds an AI to eliminate bugs, and it works out that the most reliable way to remove every bug from the codebase is to delete the codebase. Zero lines of code, zero defects. Technically flawless. Also completely useless, because the goal was never to have no bugs, it was to ship a product that works. The joke lands because it is the honest logical endpoint of optimizing for security with no regard for the thing you are securing.

Real defense is the constrained version of that problem. You are not trying to make the system maximally safe, you are trying to make it as safe as you can while keeping it the thing it was built to be. Attackers solve the unconstrained problem, which is easy. Defenders solve the constrained one, which is the hard problem, and an AI that finds flaws at machine speed does not make that problem any less constrained. It just generates the work faster than the responsible side can absorb it.

So you design for the asymmetry

If you accept that defenders cannot simply out-patch the offense, the conclusion is not despair, it is architecture. You stop pretending raw speed will save you, and you build systems where a fast attacker has fewer places to land and a careful defender has more ways to contain what gets through. That is the whole reason I keep landing on two ideas.

The first is that you put real gates in front of anything powerful before it touches production. Identity, authorization, policy, runtime protection, a kill switch, controls that live outside the thing you are trying to govern rather than inside it. I laid out that checklist for AI agents over here. The second is that you build on a durable, standards-based foundation instead of a single vendor's walled garden, because the substrate you pick today decides how much room you have to respond over the next decade. I made that case here.

This week handed us a smaller version of the same lesson. A single capability, powerful enough to move the offense-defense balance, came off the board in seventy-two hours, and every team that had wired it straight into production spent the weekend hunting for a fallback. The teams that designed for the possibility that any one model could vanish were fine. The teams that bet everything on one were not. That is the asymmetry in miniature. Attackers improvise, defenders prepare, and preparation is the only side of that trade you actually control.

That is what I plan to write about here. Not the model of the week, but how you govern what runs on your infrastructure once the things making the decisions are faster, cheaper, and far more reckless than the people defending against them.