A new breed of AI model can find vulnerabilities in fifty-year-old codebases that human security teams missed entirely. Most organisations will never have access to it. Here is what they should do instead.
The Asymmetry Problem Nobody Is Talking About
There is a principle in security called defence-in-depth. It assumes that the attacker and the defender are drawn from roughly the same pool of human capability — that a sufficiently resourced security team, given enough time, can reason about the same vulnerabilities a skilled attacker would find. That assumption broke in April 2026.
When Anthropic announced Claude Mythos Preview on April 7, 2026, they framed it as a cybersecurity milestone. The model had found thousands of high-severity vulnerabilities across internet-facing software — including in Linux kernel codebases with histories stretching back decades — that no prior automated tool, and no human team, had surfaced at that scale and speed. They withheld general release and launched Project Glasswing, a restricted consortium of vetted industry partners tasked with using Mythos defensively to patch critical infrastructure before the vulnerability window could be exploited.
The decision was responsible. The problem is structural. A small group of unauthorised users had already accessed Mythos on the same day Anthropic announced its limited trial. The attack capability, even partially, was already loose. And the organisations most exposed — web hosting providers running aging Linux distributions, banking middleware stacks, aviation and rail systems operating under certification constraints that make emergency patching legally impossible — were not on the Glasswing invite list. They were watching from outside, aware that something powerful had changed, unsure what they could actually do about it.
This article is written for that audience. It does not pretend to offer Mythos-level defence. It offers something more honest: a clear-eyed assessment of what the threat model has become, what the realistic attack surfaces are for organisations operating outside the frontier AI partnership tier, and what practical steps they can take with the tools they actually have. Defence here is not about matching the attacker's intelligence. It is about making the cost of exploitation high enough that even a sophisticated attacker chooses a softer target.
What Claude Mythos Actually Does — and Why It Changes Everything
To understand why Mythos represents a qualitative shift rather than a quantitative one, it helps to understand what prior automated security tooling actually did. Fuzzing tools like AFL and libFuzzer are extraordinarily good at finding crashes and memory corruption bugs by generating malformed inputs at scale. Static analysis tools like Semgrep and CodeQL are good at pattern-matching known vulnerability classes against codebases. SAST and DAST tools identify common misconfigurations and injection points. All of these are powerful. None of them reason about intent, context, or the interaction between components the way a skilled human does.
Mythos does something qualitatively different. Anthropic's red team documentation describes it as capable of reading an entire large codebase — millions of lines across multiple files, services, and languages — and reasoning about the semantic meaning of the code, not just its syntactic patterns. It can identify a subtle logic flaw in an authentication flow that only manifests when a specific sequence of API calls is made under race condition timing. It can chain a low-severity information disclosure in one service with a privilege escalation vector in another service to construct an exploit path that neither vulnerability would enable alone. It can read the interaction between a cryptographic library's implementation and the protocol layer above it and identify an edge case the protocol authors never considered.
"The same improvements that make the model substantially more effective at patching vulnerabilities also make it substantially more effective at exploiting them."
— Anthropic Red Team Documentation, April 2026
This matters because virtually all enterprise security tooling is built on the assumption that finding vulnerabilities requires more compute than any attacker possesses, or more domain expertise than any individual analyst can sustain. Mythos invalidates both constraints simultaneously. It has the domain expertise of a world-class security researcher, the context window to hold an entire codebase in working memory at once, and the speed to analyse at a scale no human team can match. The attack surface has not changed. The attacker's capability has.
Critically, Mythos does not need zero-day exploit kits or nation-state infrastructure to be dangerous. It needs only access to publicly readable code — which describes most open-source software, most smart contracts, most JavaScript frontend code, and most API documentation — and enough compute to run inference. For an attacker with API access, even unauthorised, the barrier to a Mythos-class vulnerability analysis is now a prompt, not a decade of security research expertise.
Three Incidents That Showed Us the Attack Surface Before Mythos Existed
The incidents below predate Mythos. They were caused by human attackers using conventional tools. They are instructive precisely because they illustrate the vulnerability classes that a Mythos-level model would have found faster, at greater scale, and with higher precision. They are not cautionary tales about AI — they are calibration exercises for understanding what the existing attack surface actually looks like.
The Exposure Window and Why Legacy Infrastructure Is Most at Risk
Security has always been a race between discovery and remediation. What Mythos changes is the speed of the discovery side — and it changes it by an order of magnitude. The remediation side has not kept pace, and for large categories of critical infrastructure, it cannot by design.
Consider the patching lifecycle for a typical enterprise Linux environment. A vulnerability is discovered. The kernel team issues a patch. The Linux distribution packages it, usually within days for critical issues. The hosting provider or enterprise applies it, usually within weeks for automated security patches, months for manual review processes. At every step, there is human latency built in. That latency is manageable when vulnerabilities are found by human researchers working at human speed. It becomes an existential gap when vulnerabilities are found by a model that can analyse an entire kernel subsystem in an afternoon.
Aviation and rail are structurally worse. Embedded systems running safety-critical operations — flight management systems, positive train control, signalling infrastructure — operate under certification frameworks like DO-178C and EN 50128 that require formal verification of any software change before deployment. A patch to a certified avionics system does not get applied in weeks. It enters a re-certification cycle that takes between two and five years, depending on the criticality of the affected component. The certification requirement exists for good reasons: an untested patch to flight control software is more dangerous than the vulnerability it fixes. But it means that a vulnerability found in certified aviation software today will be running unpatched in commercial aircraft for years.
Mythos finds a Linux kernel vulnerability on Day 1. A patch is written on Day 30. Web hosting applies it on Day 90. Aviation re-certification completes in Year 3. For the entirety of that window, every system in that category is exposed to any attacker who has replicated Mythos-level analysis — including the unauthorized users who accessed the model in the same week it was announced.
Banking core systems occupy a middle ground. The COBOL mainframes running general ledger operations for most large banks are, paradoxically, among the safer components — they are air-gapped, vendor-managed, and rarely internet-adjacent. The exposed layer is the middleware: the Java and Python services that translate between the core ledger and modern API interfaces, the REST endpoints that power mobile banking, the message queuing infrastructure connecting core banking to payment networks. This middleware layer is modern enough to be patched quickly in principle, but complex enough that banks apply change management processes — formal review, UAT, staged rollout — that add weeks to every patch cycle. And it sits on Linux.
Crypto, Blockchain, and Banking: The Safest Tech on Shaky Ground
The cryptographic primitives underpinning blockchain — elliptic curve discrete logarithm problems, SHA-256, Merkle tree construction — are not under threat from Mythos. A language model, however capable, cannot break mathematics that would require classical computation on the order of the age of the universe to brute-force. The safety of blockchain at the mathematical layer remains intact.
The problem is that blockchain does not run on mathematics. It runs on C++ in the Bitcoin Core implementation, on Rust in the Solana runtime, on Go in Hyperledger Fabric, on Solidity compiled to EVM bytecode. Each of these is a codebase with implementation choices, edge cases, and the accumulated technical debt of rapid development under market pressure. The mathematics is sound. The code is not necessarily.
Smart Contracts: Immutable, Public, and Permanently Exposed
Smart contracts represent the most asymmetrically exposed attack surface in the entire technology landscape. They are immutable once deployed — there is no patch process, only emergency migration if the contract architecture permits it. They are publicly readable — every deployed contract's bytecode is on-chain, and most are open-source with full source available. They directly control real financial value, with no fraud reversal mechanism. And they were often written by developers whose primary expertise was cryptoeconomics or protocol design, not adversarial security engineering.
A Mythos-level model given access to a deployed DeFi protocol's contracts has every advantage an attacker could want: complete source code, unlimited analysis time, no rate limiting, and a direct financial incentive calculation built into the protocol's own documentation. The Ronin bridge lost $625 million. The Wormhole bridge lost $320 million. Both were found by humans. The question for any protocol holding significant value is not whether a more capable model could find what those humans found. It is what that model would find that those humans did not.
The Bridge and Middleware Layer
Cross-chain bridges — the infrastructure that allows value to move between blockchain networks — have accounted for the majority of DeFi losses to date. They are structurally complex: they operate across multiple chains with different finality guarantees, they involve multi-signature validator sets with real key management requirements, and they must handle edge cases like network forks, validator slashing, and replay attacks across heterogeneous environments. This complexity is exactly the kind of multi-component reasoning task that language models at Mythos's capability level excel at. Every bridge in production today should be treated as a high-priority analysis target for any attacker with Mythos-level access.
The Defense Framework: What You Can Actually Do Without Mythos Access
The honest position is this: you cannot match a Mythos-level attacker with a Sonnet-level defender. That asymmetry is real and should not be papered over with false reassurance. What you can do is make your systems expensive to exploit — expensive in terms of the additional analysis required, the noise generated during reconnaissance, and the blast radius limitation that prevents a single successful exploit from becoming a catastrophic breach.
Defence here operates on a different logic than attack. An attacker using Mythos needs to find one exploitable vulnerability in your entire attack surface. A defender needs to make every component of that surface sufficiently hardened that the attacker's cost-benefit calculation favours a softer target. You do not need to find every vulnerability Mythos would find. You need to close enough of them, and instrument enough of the remainder, that exploitation becomes detectable and containable.
Defense-in-Depth Framework for Mythos-Class Threat Environments
Layer 1 — Blast Radius
Network segmentation and least-privilege architecture. Assume breach. Design every system boundary so that a compromised component cannot reach components it has no operational reason to access. A kernel vulnerability in a web server should not be a path to your core database. This does not prevent exploitation — it limits what exploitation enables.
Layer 2 — Detection Speed
Anomaly-based monitoring over signature-based detection. Mythos-found exploits will not match known CVE signatures until after they are publicly documented. Invest in behavioural baselines — normal process trees, normal network flows, normal privilege patterns — and alert on deviation. You cannot detect what you cannot define as normal first.
Layer 3 — Attack Surface Reduction
Immutable infrastructure and read-only filesystems. A kernel exploit that cannot write to disk, cannot install persistence, and cannot modify runtime configuration has severely limited utility. Container-based deployments with immutable images dramatically reduce post-exploitation options even when the initial exploitation succeeds.
Layer 4 — Dependency Hygiene
SBOM with automated vulnerability tracking. Log4Shell affected organisations that did not know Log4j was in their stack. Generate and maintain SBOMs for every production system. Automate CVE correlation. The speed advantage of Mythos-assisted vulnerability discovery is partially offset if your patching pipeline is already tracking every component.
Layer 5 — Smart Contract
Formal verification for high-value contracts. Traditional audits are human-speed analysis. Formal verification — mathematical proof of correctness against a specification — provides guarantees neither human auditors nor AI analysis can invalidate. Consider tools like Certora Prover, Halmos, and Dafny for critical contract logic.
Layer 6 — Privileged Access
HSMs and air-gapped key management. The Ronin bridge was broken because private keys were accessible to a compromised process. HSMs and air-gapped signing ceremonies prevent discovered vulnerabilities from translating into key compromise. This is the most cost-effective control.
Layer 7 — AI-Assisted Defence
Use available AI models for continuous code review. Models like Opus, GPT, and Gemini won't find everything Mythos finds, but they will find a meaningful fraction. Integrate AI code review into your CI/CD pipeline as a standard gate. Imperfect coverage at every commit is more valuable than perfect coverage at quarterly audit cycles.
For Banking Specifically: The Regulatory Lever
Banks operate under a regulatory framework that creates a lever unavailable to most organisations. The same bodies — the Federal Reserve, OCC, ECB, BIS, national prudential regulators — that mandate capital adequacy stress tests and operational resilience frameworks have the authority to mandate AI-assisted security audits as a supervisory requirement. The argument to make to regulators is straightforward: the threat model has changed. The Basel framework for operational risk was written before a single model could autonomously audit a codebase. The supervisory expectation that annual penetration tests constitute adequate security assurance was calibrated for human attackers. Neither assumption holds in the Mythos era.
Financial institutions have collective standing to push regulators toward requiring Mythos-level defensive access as a condition of critical infrastructure designation. This is not lobbying against regulation — it is asking regulators to update their threat model to reflect the current environment. The SWIFT Customer Security Programme, the FFIEC Cybersecurity Assessment Tool, the ECB TIBER-EU framework — all of these can be updated to require AI-assisted red teaming at the frontier capability level. Getting there requires practitioners making the case to supervisors, not just waiting for policy to catch up.
The Systemic Response: What Regulators and Industry Must Do Collectively
Individual organisation hardening, even done well, addresses the symptom rather than the cause. The cause is a structural information asymmetry: Mythos-level attack capability is, to some degree, already loose, while Mythos-level defensive capability is locked behind an invite list that does not include most of the world's critical infrastructure operators. Closing that gap requires collective action at a scale that no individual organisation can drive.
Project Glasswing is a start, but its scope is currently defined by cybersecurity research partnerships, not by critical infrastructure criticality. Aviation safety systems, core banking middleware, rail signalling infrastructure, and public utility control systems are not cybersecurity research partners — they are operational infrastructure that happens to run software. The framework for getting them defensive access needs to be different from the framework for getting a security research firm access. It needs to be closer to the model used for classified threat intelligence sharing: vetted, operationally constrained, with liability frameworks that make participation viable for regulated entities.
At the international level, the BIS and SWIFT have the institutional standing to convene a financial sector equivalent of Project Glasswing — a coordinated programme specifically for banking infrastructure, with Anthropic and peer frontier labs as partners, that gives systematically important financial institutions access to Mythos-level defensive analysis under appropriate governance. The G7 Cyber Expert Group has already established frameworks for cross-border incident response. Extending that to proactive AI-assisted vulnerability disclosure is a natural next step that requires political will more than technical innovation.
The Honest Ceiling
This article has described what organisations without Mythos access can do to harden their systems. It has been honest about what those measures cannot achieve. Blast radius limitation, anomaly detection, formal verification, and AI-assisted continuous code review are all genuinely valuable. They are not equivalent to having a Mythos-level model systematically audit your attack surface before an adversary does.
The honest ceiling of non-Mythos defence is this: you can make exploitation expensive enough that unsophisticated attackers and opportunistic actors choose softer targets. You can instrument your environment well enough that when exploitation occurs, you detect it faster and contain the damage more effectively. You cannot guarantee that a determined adversary with access to Mythos-level capability — whether through Glasswing, through the unauthorised access that has already occurred, or through a competitor model reaching similar capabilities in the coming months — will not find something in your codebase that you did not.
The appropriate response to that honest ceiling is not paralysis. It is a reordering of security priorities toward the controls that matter most in a world where vulnerability discovery is no longer the bottleneck: detection speed, blast radius limitation, response capability, and the regulatory and collective action work that can bring defensive AI access to the organisations that need it most. The threat model has changed. The response needs to change with it. Starting that work now, with the tools available now, is materially better than waiting for access to tools that may not arrive before the exposure window is exploited.
Security in the Mythos era is not about being impenetrable. It is about being the organisation that makes exploitation costly enough, and visible enough, that the calculus favours moving on. That remains achievable. It just requires being honest about what you are defending against.
Is your SDLC pipeline prepared for frontier-model adversarial analysis?
Book a Governed Agentic SDLC Audit with ZestyCode to identify your structural gaps before the attackers do.