The real lesson from Claude Mythos isn’t about AI, it’s about governance

COMMENTARY: A remote code execution vulnerability sat inside FreeBSD's network file-sharing code for 17 years, in software trusted enough to run some of the most cautious infrastructure in the world. And then, earlier this year, an AI model, Claude Mythos Preview, found it. 

Anthropic says Claude needed nothing more than an instruction to look for the vulnerability, find it, and build a working exploit. Catalogued as CVE-2026-4747, this vulnerability was one of thousands found by Claude across nearly every operating system and browser. In response, Anthropic restricted access to the model, rather than releasing it broadly.

[SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Read more Perspectives here.]

In the weeks since, the vocabulary used to respond - by regulators, by theIMF, by nearly every vendor with a stake in AI security -  has converged on a single word: governance.

That word does several different jobs at once. For some, it means overseeing what a model itself can do. For others, it means the separate discipline of controlling who can reach which data. Increasingly, in board and regulatory conversations, it has come to mean the general assurance that someone, somewhere manages risk, even though that says little about whether security policies still reflect their original business purpose or intent.

It’s not an argument against governance as a discipline. Defining who’s allowed to do what, and proving it, lies at the heart of security best practices.

The problem: one word now stands in for all these different jobs, so a board hearing it cannot tell a specific commitment from a framework binder and a slide deck. What we need to actually ask of any vendor is narrower and far more testable: whether a given policy permits exactly what it’s supposed to, and whether that permission is verifiable today. In short, we have to make permission more than something asserted in a pitch and proven only once something goes wrong.

Why prevention is harder – and better

The most concrete policy conclusion to come out of the Mythos episode was the IMF's: that attackers will eventually breach defenses, and that we have to make resilience a priority, the capacity to keep functioning once an attacker gets through. That’s a sensible position. But resilience should complement, not replace, prevention. Prevention reduces exposure by eliminating unnecessary attack paths before bad actors can exploit them, while resilience ensures organizations can recover when attacks succeed.

Prevention takes more work because it asks for evidence before an attack happens: Are only the intended access paths available? And, do security policies still reflect their original business purpose? Resilience answers whether an organization can withstand and recover from a breach; prevention reduces the likelihood and impact of that breach by removing unnecessary exposure before attackers can exploit it.

Patching the FreeBSD flaw did not amount to prevention. Once public, any competent security team could apply a fix within days, but the patch addressed only the specific bug the model happened to find, not whether the underlying service, a file-sharing protocol built for trusted internal networks, should have been reachable from outside the organization's perimeter at all. The next flaw in that same service would have been just as exploitable.

That’s the difference between fixing what was found and closing what allowed it. A patch responds to a specific disclosure; a policy decision about what a network-facing service can do determines how many more disclosures are still waiting to be found. It’s the layer that never earns a press release when it works, because nothing malicious happens.

From adding controls to maintaining control

Adding controls treats security as an accumulation of tools bolted onto infrastructure that keeps changing beneath them. Maintaining control treats the policy governing that infrastructure as the variable that actually determines, at any given moment, whether an opportunity for exploitation exists at all.

Most organizations do not have a single policy problem. They have thousands of small ones: firewall rules approved for a project that ended two years ago, cloud security groups opened for a migration that's finished. We’re not missing judgment at the time the decision was made, but ownership afterward. The engineer who justified a rule moves to a different team before anyone revisits it, and the temporary exception outlives the project that needed it. Nobody ever gets assigned the job of asking whether last year's decision still makes sense this year.

Every outdated rule, temporary exception, and unnecessary access path expands the environment attackers can exploit. Over time, policies stop reflecting deliberate business intent and instead reflect years of incremental change. Modern AI systems can identify exactly this accumulated exposure at machine speed.

Once an access decision gets made, organizations need help to verify that the surrounding policy environment does not allow that access to extend beyond its intended purpose. That means showing security teams the actual permitted access, not what documentation says should be permitted. It means validating policy changes before deployment, continuously confirming policies still reflect their original business intent, and maintaining evidence across hybrid environments to prove that access still matches business intent.

The test that matters

Other tools such as Claude Mythos will hit the market, and the next one will no doubt work smarter and move even faster. The industry assumes that we’ll simply get better at responding once something like it gets through. But that assumption deserves far more scrutiny than it’s getting right now.

At first blush, we want to reach for more governance. It’s not an incorrect instinct, but it’s incomplete. Organizations need both prevention and resilience. Prevention reduces exposure by ensuring only necessary access exists. Resilience ensures operations continue when attacks succeed. Both depend on knowing what’s allowed, what has changed, and whether access still reflects the business's intended purpose.

That’s the test I would apply to anyone's version of governance: not whether it can describe the access a business intends to allow, but whether it can prove the access that actually exists matches that intention.

David Brown, senior vice president, International Business, FireMon

SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Each contribution has a goal of bringing a unique voice to important cybersecurity topics. Content strives to be of the highest quality, objective and non-commercial.