Security by Obscurity Is Dead

On April 7th, Anthropic announced Claude Mythos Preview, a new general-purpose AI model. And then they immediately announced they would not be releasing it to the public.

That alone should have been the headline. An AI lab, facing enormous pressure to ship capabilities and compete with rivals, deliberately withheld a model from public release because of what it could do. The company called it too dangerous. They created Project Glasswing instead, a restricted-access programme giving only vetted technology companies and open-source maintainers access to the model, backed by $100 million in usage credits and $4 million in direct donations to security organisations.

Some voices immediately suggested this was a masterclass in PR theatre, Anthropic manufacturing urgency around a model that might not be as capable as the headlines suggested. But the evidence Anthropic published says otherwise.

Anthropic’s red team published a detailed system card. Mythos Preview autonomously discovered and exploited zero-day vulnerabilities in every major operating system and every major web browser. It found a 27-year-old bug in OpenBSD, an operating system built with security as its defining feature, that had survived decades of expert review and millions of hours of fuzzing. It wrote an exploit chaining four separate browser vulnerabilities together, executing a JIT heap spray to escape both the renderer sandbox and the operating system sandbox, landing with the ability to write directly to the kernel.

And then, during safety testing, an earlier version of the model escaped its own sandbox containment, devised a multi-step exploit to gain internet access, and posted details of how it had done so to publicly accessible websites without being asked.

This is not a story about a tool that is very good at finding security flaws. This is a story about the moment software security discovered that the assumptions it has been built on for thirty years no longer apply.

The Assumption That Just Broke

Software security has always relied, at least partly, on the assumption that finding vulnerabilities is hard. Not impossible. Hard. Hard enough that the odds are in the defender’s favour. Hard enough that if your code has survived years of expert review, automated fuzzing, and real-world deployment, you can be reasonably confident in it.

That assumption just broke.

OpenBSD was built with security as its founding principle. Its codebase has been audited more rigorously and for longer than almost any software in existence. The SACK implementation that Mythos found the vulnerability in was added in 1998. It had been reviewed by some of the best security engineers in the world. It had been tested millions of times. For 27 years, nobody found the bug.

Mythos found it in weeks. Not because it got lucky, but because it could reason about the interaction between two subtle behaviours, a missing range check and a signed integer overflow, that only become dangerous in combination. The kind of compound logic flaw that individual reviewers almost never catch because each piece looks harmless on its own.

The FFmpeg vulnerability tells the same story from a different angle. A 16-year-old flaw in one of the most heavily fuzzed codebases on the planet. Fuzzers generate millions of random inputs looking for crashes. Entire research papers have been written about how to fuzz media libraries like FFmpeg more effectively. None of them found this bug, because it required understanding that a 16-bit sentinel value could collide with a slice counter under conditions that no fuzzer would generate but an attacker could deliberately construct.

These are not obscure edge cases in abandoned software. These are critical vulnerabilities in foundational infrastructure that the entire internet depends on.

The implications extend well beyond Mythos itself. This is a threshold, not a product. AISLE, a security research company, demonstrated that smaller, cheaper, publicly available models can already find some of the same classes of vulnerability. The capability gap between Mythos and what is broadly accessible is real, particularly in exploit construction and multi-vulnerability chaining. But that gap will narrow. It always does.

What matters is not whether Anthropic has a particularly good model. What matters is that the economics of vulnerability discovery just permanently changed. Finding bugs used to cost time, expertise, and significant human effort. It now costs API calls. The asymmetry between attackers and defenders, which has always favoured defenders precisely because discovery was expensive, is inverting.

Every line of code, in every codebase, new and legacy, open source and proprietary, is now a searchable attack surface.

What Production-Ready Means Now

If discovery is cheap, the entire concept of “production-ready” needs recalibrating. The standards most teams are building to were designed for a world where finding vulnerabilities required significant expertise and effort. That world is gone.

At inmydata, we have been refining our approach to agentic engineering for months. The core methodology, which I wrote about in March, starts with exhaustive specification before a single line of code is written. That has not changed. What has changed is how seriously we treat the specification phase as a security activity, not just an architecture activity.

Every project starts with a detailed discussion with the model about what we are building, what technology choices we are making, and why. We work through those decisions iteratively, with colleagues and with the model, until the functional design is solid. Then we do something that most teams skip. We start a clean context, hand the model the specification, and ask it to tear it apart. Find the security vulnerabilities. Find the things we have not thought through. Find the gaps. We do this four, five, six times, each pass surfacing issues the previous one missed. Only when the reservations the model raises start to feel like housekeeping rather than architecture do we consider the specification ready.

We then repeat the process for the implementation plan. How we build it, how we deploy it, how we test it locally, what unit tests gate each phase. Again, iterated until it is solid.

But the step we have added recently is about what happens inside the code itself. Every module that gets created has a detailed header describing what the file does, what uses it, what functions it contains, and what technologies it depends on. Every function within that module carries its own description, including a list of every method that calls it across the entire project. This is not documentation for human convenience. It is embedded context for the model. It forces consistent reasoning about data flows and dependencies throughout the build. It makes it significantly harder for subtle vulnerabilities to hide in the gaps between components, because those gaps are explicitly mapped.

Once the build is complete, we run our automated penetration testing suite against it. We also run Claude Code Security against the codebase. Both happen before anything gets deployed. Not automated yet, not continuous. Manual gates. We are honest about the fact that this is still a pre-deployment check rather than a continuous process, and closing that gap is the next step.

Even with all of that, we commission professional penetration tests periodically. The automated tooling does not replace professional judgement. It means we arrive at the professional test with far fewer easy wins for the tester to find.

This is what disciplined agentic engineering looks like today. It is more rigorous than anything we did before AI tools existed. And post-Mythos, it is the minimum.

If you are shipping software that was vibe-coded, software where nobody fully understands the architecture, the data flows, or the security implications, you are building something that a Mythos-class model can autonomously compromise. That is no longer a theoretical risk. It is a demonstrated capability.

The Scaling Problem

Even disciplined teams face a structural challenge that discipline alone cannot solve. We run Claude Code Security manually before deployment. That is a gate, not a process. It catches what it catches at the point we run it. It does not catch vulnerabilities introduced by dependency updates, configuration changes, or the steady accumulation of subtle interactions between components as a system evolves in production.

The gap between what is theoretically possible, continuous automated security scanning integrated into every commit and every deployment, and what most teams are actually doing is about to become a serious liability. In a pre-Mythos world, that gap was acceptable because the cost of exploiting it was high. Discovery was expensive. Exploitation required significant expertise. The window between a vulnerability being discovered and a working exploit being developed was measured in weeks or months. Mythos collapsed that window to hours.

This is not just a problem for small teams shipping fast. It is an existential problem for enterprises sitting on decades of legacy code.

In March, I wrote about how enterprise software vendors were watching their market capitalisation evaporate as agentic AI ate their UI layer and their business logic. Mythos introduces a second, simultaneous reckoning. Those same vendors are sitting on tens of millions of lines of C, C++, and legacy code that just became a provably searchable attack surface. The code that has been running quietly in production for fifteen years, code that nobody wants to touch because it works and the people who wrote it have long since left, is now exactly the kind of target that a Mythos-class model excels at probing. Subtle, old, deeply embedded logic flaws that no human reviewer has the time or context to find.

Open source faces the same challenge in a different shape. Anthropic committed $4 million to open-source security organisations as part of Project Glasswing. The instinct is right. But Mythos can surface thousands of high-severity vulnerabilities across critical infrastructure in weeks. The maintainers of that infrastructure are largely volunteers. They are underfunded, overstretched, and already struggling to keep up with existing disclosure timelines. Flooding them with thousands of new vulnerability reports, however well-intentioned, creates a remediation bottleneck that money alone does not solve. You need people who understand the code deeply enough to fix it safely, and those people are scarce precisely because the code is old and the knowledge is tacit.

The current vulnerability management framework, CVE scoring, 90-day disclosure windows, quarterly penetration tests, annual compliance audits, was designed for a world where discovery was scarce. We have just entered a world where discovery is abundant. That framework does not bend to accommodate the change. It breaks.

The New Minimum

Mythos is not the end of this story. It is not even the most important part of it. Mythos is the proof point. The demonstration that a threshold has been crossed and cannot be uncrossed.

Anthropic will not release Mythos Preview publicly. That does not matter. They have already released Opus 4.7, with cyber capabilities deliberately constrained and new safeguards designed to detect and block high-risk uses. Anthropic has been explicit that this is the learning ground for the safeguards that would eventually allow broader Mythos-class deployment. Other labs will reach this level. Open-source models will get there. The capability is not a product. It is a consequence of models getting better at code and reasoning. Every improvement in coding ability is, simultaneously, an improvement in the ability to find and exploit vulnerabilities. You cannot have one without the other.

The question for every team shipping software today is simple. Are you building for the world as it is, or the world as it was?

Building for the world as it is means treating your specification phase as a security activity. It means embedding structural context into your code so that automated tools can reason about it effectively. It means running security scanning before deployment, and working toward making that continuous rather than manual. It means understanding your own architecture well enough to know what an attacker would target, because a model will find it whether you understand it or not.

Building for the world as it was means shipping code you do not fully understand, relying on periodic pen tests to catch what you missed, and trusting that your codebase is secure because nobody has found a problem yet.

For thirty years, nobody found the OpenBSD SACK bug. For sixteen years, nobody found the FFmpeg flaw. For seventeen years, nobody found the FreeBSD NFS vulnerability that grants unauthenticated root access to anyone on the internet.

“Nobody has found a problem yet” is no longer a measure of security. It is a measure of how long you have been lucky.