With Mythos, a Fable as Old as Time
Mythos as Marketing
Back in the spring, a Senate staffer friend mentioned a rumor circulating on Capitol Hill: Anthropic’s prediction of cyber cataclysm from a free-range Mythos model was actually just some final boss-level marketing. Soon after he pointed me to a BBC podcast discussing it—the rumor had broken containment.
I don’t know if the claims about Mythos or successor Fable and any of the newer competitor models are true, any or all of them. Multiple things can be true at once. And a person, say, a frontier artificial intelligence (AI) lab engineer, can earnestly believe their latest model is a remarkable threat. That claim is neither refutable nor provable beforehand, so there’s some filling in the blanks from those in the best position to know. Maybe it doesn’t hurt that whether epistemically valid or marketing schtick, it all makes darn good copy.
Who Let You in Here?
Whether Mythos and its successors lived up to the marketing hype turns out to not matter for making the world a safer place. The last few months’ high-profile testing failures, at OpenAI and Anthropic, make that abundantly clear.
First off, the parties involved are among the most tech- and computer security-literate organizations on Earth: the AI lab itself (OpenAI), an elite software evaluation organization (METR), and the company that hosts half the world’s open models (HuggingFace). Yet, while the incident with OpenAI’s model going all Spring Breakers with the Hugging Face townies may have involved some of the ominous-sounding risks we’ve come to know—deception, misalignment, “going rogue”—the developer’s own telling admits that more diligent (but still basic) human monitoring would’ve caught it weeks earlier. Same for Anthropic, which, if it weren’t for taking notice of its rival’s incident, wouldn’t have caught its own rogue model (which the company did, only months after it happened).
Second, in OpenAI’s case, the failure was not exactly a model going astray. It was a failure to configure a testing environment correctly, according to globally accepted but voluntary standards. In particular, ISO/IEC 27001: 2022 Annex A control 8.31 and 8.22. According to respected cybersecurity expert Tony Vizza, “if your red-team range has a routable path to the production internet through a vulnerable internal proxy, the problem predates the AI.” Basically, OpenAI’s model broke free of its testing environment not by finding a new way to pick the lock, but because the testers failed to deploy the relatively old-fashioned locks long known to cybersecurity experts.
Or put another way, offense advances faster than defense. Not because of the technology itself, but because the humans running it don’t ever keep up. It’s natural to race ahead at full speed to push the capability frontier, while simultaneously forgetting to do the mostly mundane things we collectively refer to as security (information security and cybersecurity). Think of it as the flip side of the AI “verification tax”—the “extra human effort required to review, correct, and validate AI outputs”—that’s paid by end users.
For Anthropic, a “misunderstanding” led to a misconfiguration. No one skimps on the exciting new capabilities, but meanwhile Stanley in IT can’t get his budget approved to hire another information security specialist.
The Only Thing Stopping a Bad Guy With an AI Is a Good Guy With an AI
Faced with breathless exclamations of AI-midwifed doom and general techno armageddon-ry, the technology accelerationists frequently retreat to the axiom, “Technology is a tool. It’s neither good nor bad.” I’ve said it myself in media interviews.
However, it’s not always true. Some technologies, while not bad per se, have a purpose that runs only one direction in the first-order effect. A missile, for instance, has only a destructive purpose. There’s no benign ICBM program (unless it just doesn’t work). Of course we use that missile for a secondary purpose, like deterring worse destruction by an evildoer. The point is not that everything is so fully neutrum ex nihilo. (Woody Guthrie even accused his guitar of homicide.)
But we don’t have to be so obtuse. Seemingly every frontier model release precedes stories of developers befuddled by some emergent capabilities and “behaviors”: new modes of deception, shutdown resistance, and so on. Sure these things are not altogether bad—deception has productive uses—but it’s akin to a defense contractor discovering their missiles actually fly further and are much more explosive than they planned.
And it’s all because of, getting back to the Mythos conundrum, the Iron Triangle of Painful Tradeoffs. Whether we label one of the corners “safety,” “reliability,” “security,” or “predictability,” shortchanging that node results from plain old incentives. Indeed, “move fast and break things” is just the Silicon Valley ethos ignoring that corner of the triangle.
The very nature of large language models (LLMs), their randomness and unpredictability, means a vulnerability can remain invisible without intentional investment (including time) into discovering it—a model is neither “safe” nor “not safe” but rather within the bounds of acceptable risks only up to the point where you’ve stopped investing in testing it. Notwithstanding the user’s intent, an otherwise neutral aspect of a model is effectively a vulnerability—like not testing a missile under certain conditions. For example, it turned out window geometry in early commercial airliners led to “planes breaking apart in flight, killing all passengers aboard.” Not because manufacturers were irresponsible, but it hadn’t even occurred to anyone that oval windows are better at withstanding structural stress than the original rectangular ones.
In the case of software, a company doesn’t have to willfully ignore a bug, because it’s less profitable to discover if there even is one. And safety in this case isn’t like putting a bigger bumper on a car—it’s not even knowing where the bumper goes.
You see it all the time.
When’s the last time you read through a data breach notification? Even noticed one? In the pre-ChatGPT world, the nation’s cybersecurity was already woefully inadequate to the degree that major and constant breaches are treated like the cosmic background radiation of modern commerce. Yes, yes, the optimal number of almost anything is non-zero. So insurance structures emerge, tort law adapts, people die in car accidents, and the world keeps turning.
Besides, if it was really such a problem, says my imaginary male interlocutor made of straw, it would be a huge market opportunity for more secure software—the numbers may seem big, but maybe the market tells us they’re smaller than the unseen benefits. Plundering the info of 192 million UnitedHealth customers isn’t that big of a deal, is it? The IT department probably had other mission-critical priorities. Plus, you could improve security through numerous services and products. Except now even those are hacked (see, for example, SolarWinds, Okta, CrowdStrike).
We already live in a cyberinsecure world. In recent years we’ve witnessed hacks disrupting over 40 percent of the East Coast’s fuel supply (Colonial Pipeline), leaving 240,000 people without power (Ukraine), disabling potentially every Windows computer (WannaCry), or its reprise the next year that disabled TSMC (the world’s most important chip fabricator). Perhaps I tend to overindex the impact of compromising 22 million feds (Office of Personnel Management), having been one myself. I’ll concede the disruption at over 3,000 colleges “preventing” students from taking finals may be a net wash from their point of view.
It’s not surprising. It’s the incentives.
Not mustache-twirling execu-villains plotting to release dangerous software on the unsuspecting people of Gotham. Not even an unscrupulous non-mustachioed executive. Just a product manager telling a normal executive, “Given our time and manpower, there are no known vulnerabilities in this build.” Because finding bugs is hard! And thus expensive!
What to Do About It
In 2024, I proposed a federal incident reporting system—voluntary, but statutory—because that’s what reading the room would allow. In lobbying for this proposal, colleagues and I intentionally under-asked, informed by what we best could gather at the time. We even got down the road with a rising GOP House member on bill text before competing priorities squeezed out that effort.
Two years later, a different House GOP member has fully introduced the “AI Incident Reporting Act,” which pretty much dispenses with any voluntary expectation and goes straight to mandatory. High-profile incidents in 2026 did the lobbying work we never could.
The public knows about model breaches and misconfigurations because the labs and their partner organizations disclosed it, this time. Which is commendable. Some of this is now even formalized (such as it is) in a White House Accord, with commitments to “robust internal controls,” “independent assessments,” and “monitoring.” But earnest interest from the signatories in these kinds of measures was never an issue. No company wants to be implicated as failing to avert a catastrophe, or even a minor incident. Much of the hot takes in response to the accord focuses on whether the companies can be trusted. The whole point is that it’s irrelevant: Good intentions get dominated by bad incentives every time.
This is why an AI incident reporting regime ought to be a top priority for this Congress. It doesn’t wholly solve the internal tradeoff, as reflected in the hypothetical discussion between product manager and CEO from earlier. But it changes incentives and provides visibility into the asymmetry.
