Claude Mythos, Project Glasswing, and the End of “Security Later” in Software Development

Anthropic built a model it won’t release. The reason it won’t release it is the reason your engineering team should care. And the reason to care isn’t what most of the coverage is telling you.

Anthropic announced Project Glasswing on April 7, 2026. The headlines that followed have mostly focused on two things. First, that Claude Mythos Preview, the model behind the initiative, is “too dangerous to release.” Second, that a dozen of the biggest names in technology are now inside a private coalition to use it for defense. Both of those things are true. Neither of them is the most useful part of the story for the teams we work with every day.

The most useful part is this. Anthropic has just shown, with specific evidence and serious institutional response, that the gap between “this software has a flaw” and “someone is actively exploiting it” is collapsing. That collapse does not care whether your team has access to Mythos. It does not care whether the panic is overblown. What it cares about is whether your codebase, your architecture, and your remediation pipeline can keep up with a world where flaw discovery is no longer the slow, expensive, human-bottlenecked step it used to be.

This post is for the CTOs, engineering leads, and technical founders trying to read through the noise. You don’t need to have a position on Anthropic’s PR strategy. You need to know what has actually changed, what your team should do about it, and what is still, for now, mostly hype.

What Mythos and Glasswing Actually Are

Cutting through the coverage: Claude Mythos Preview is an unreleased frontier model from Anthropic. A frontier model is the most capable tier of large language model a lab has trained, typically ahead of what it offers to the public. Mythos is presented as a general-purpose model that happens to be unusually strong at software reasoning and cybersecurity tasks. It isn’t a specialised scanner. It isn’t a security tool. Its capability at finding and exploiting software vulnerabilities is a byproduct of how good it is at understanding code in general.

Project Glasswing is the gated program through which Mythos is being used. Twelve launch partners were named: Amazon Web Services, Anthropic, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorganChase, the Linux Foundation, Microsoft, NVIDIA, and Palo Alto Networks. Another forty-plus organisations that maintain critical software infrastructure have been given access. Anthropic has committed $100 million in model usage credits for the program.

Anthropic says Mythos has already found thousands of high-severity zero-day vulnerabilities (flaws that the software’s own maintainers didn’t know existed) in systems including every major operating system and every major web browser. It has published a system card and a Frontier Red Team writeup with technical detail on a subset of those findings that have since been patched.

The headline benchmark number from Anthropic’s own red team report: Mythos produced working Firefox-related exploits 181 times on a benchmark where Claude Opus 4.6 succeeded just 2 times out of several hundred attempts. Even if you discount the number heavily, the gap is the kind that doesn’t get closed by prompt engineering.

Worth knowing: Anthropic is not releasing Mythos Preview generally. Glasswing participants access it through the Claude API, AWS Bedrock, Google Cloud’s Vertex AI, and Microsoft Foundry at $25 per million input tokens and $125 per million output tokens, roughly five times the price of public Claude Opus. That pricing is one of the quieter signals in this whole story. It tells you Anthropic expects access to be valuable enough that the economics of defence justify the premium.

Why Serious Institutions Reacted Seriously

This is the part of the story most worth paying attention to if you’re trying to calibrate the signal-to-hype ratio. Announcements from AI labs are a monthly occurrence. Responses from central banks are not.

Within a week of the Glasswing announcement, regulators on three continents had moved. U.S. Treasury Secretary Scott Bessent and Federal Reserve Chair Jerome Powell convened an urgent meeting with bank chief executives to warn them about the risks. The Bank of England’s Cross Market Operational Resilience Group and AI Taskforce scheduled sessions on Mythos within two weeks. European Central Bank supervisors, Reuters reported, began gathering information with a view to asking eurozone banks about their preparedness for this new possible source of risk. In Canada, Mythos was discussed at a meeting attended by representatives of the Finance Ministry, the Bank of Canada, and bank executives.

Bank of England Governor Andrew Bailey was the clearest voice in the room. He described the model’s arrival, in remarks at Columbia University, as something that could “crack the whole cyber risk world open.” That language matters because it comes from an institution whose job is to understate risk, not dramatise it.

The other signal that mattered came from the defenders themselves. JPMorganChase CEO Jamie Dimon, whose bank is a Glasswing partner, put it in the most useful terms for engineering leaders. On the Q1 earnings call, he acknowledged that AI had made cyber risk worse and harder, and then landed on the real point: “It shows a lot more vulnerabilities need to be fixed.”

That sentence is the entire post in eight words. The story isn’t that a new attacker has arrived. The story is that the queue of things already broken in production software just got a lot longer, and the tools for finding the next item in that queue just got a lot faster.

What the Hype Is Getting Right, and Where to Be Careful

Not everything in the coverage is worth believing. Bruce Schneier, who is about as reliable a cold-shower voice as exists in this space, pointed out something useful. A smaller security firm called Aisle replicated some of Mythos’s findings using older, cheaper, public models, with one catch. The replication could find the vulnerabilities but not reliably turn them into exploits. Finding is easier than weaponising. That gap, for now, still favours defenders.

The brief version of the honest picture looks like this.

What’s Real

• The capability jump is genuine. Anthropic’s own disclosures, independent partner confirmations, and replication work by Aisle all point in the same direction. Vulnerability discovery by AI is no longer science fiction and no longer a toy demo.
• The regulatory response is real. Four jurisdictions moved within a week. That does not happen over press releases.
• The capability will proliferate. Anthropic itself frames Glasswing as a head-start program, not a moat. Competitors are training models in the same direction. The question is timing, not outcome.

What’s Hype, or At Least Uncertain

• The “thousands of zero-days” figure is not independently verifiable. It comes from Anthropic. It may well be accurate. It also includes vulnerabilities still undisclosed because they are not yet patched, meaning the public cannot inspect the claim directly.
• “Too dangerous to release” is framing, not regulation. No body has classified Mythos. Anthropic made the decision. Restricting access has real safety logic behind it, but it also has real marketing logic behind it.
• The end-of-defender narrative is premature. Finding plus exploiting is harder than finding. Defender advantage in that gap is real for now. It is also shrinking.

If you’re trying to decide how seriously to take this, the right frame is not “is Anthropic’s story accurate?” It is “does the direction of travel require me to change what my team ships this quarter?” The answer to that question does not depend on whether every claim in the announcement holds up.

The Real Lesson: Remediation Speed Is Now a Strategic Metric

Here is the reframe that matters most for technical teams. For the last decade, most software organisations have optimised for two things: ship speed and feature velocity. Security has been treated as a downstream concern, a gate before release, a QA pass, an audit before a compliance window, something the security team handled while engineering kept building.

That model was already under pressure from AI-assisted development. Teams using Cursor, Claude Code, and GitHub Copilot have been shipping faster for a year, but the codebases they’re shipping accumulate a particular kind of debt: code that’s syntactically correct and locally sensible but architecturally brittle. We wrote about that pattern in The Hidden Cost of AI-Assisted Code. It’s a known wall.

Mythos and its successors change the economics of that wall. In the old model, accumulated architectural debt was a problem you could sort out during the next quarter’s “cleanup sprint.” In the new model, that debt is a surface area that can be mapped, tested, and broken faster than your team can audit it. The equation that used to work, ship fast and fix later, stops working when “later” is shorter than your patch deployment cycle.

“Providers of technology must aggressively adopt new approaches now, and customers need to be ready to deploy.”

Lee Klarich, Chief Product Officer, Palo Alto Networks (Project Glasswing launch)

The metric that used to matter was mean time to ship. The metric that matters now is something closer to mean time to remediate: how long between a flaw being discovered in your software and a fix being verified, deployed, and observed in production.

Most engineering organisations have never measured that number. They are about to find out what it is.

What Actually Changes for Engineering Teams

Below is what this shift looks like in practice. These aren’t hypotheticals. They are the conversations we are having this month with CTOs who are trying to translate the news into roadmap decisions.

The column that does most of the work in that table is the third one. The shift isn’t hard to understand. It’s hard to operationalise. The teams that will struggle most are not the ones that don’t know what to do. They are the ones whose organisational design, tooling, and sprint cadence were built around a different equation.

The 80% Is Still Fine. It’s the 20% That Now Has a Deadline.

Worth saying plainly, because the coverage is making a lot of engineering leaders feel like they’re about to be breached by Tuesday: most of your codebase is still solid.

The typical production application we review has a mixture. Roughly 80% of the code is fine: standard patterns, well-tested paths, the parts that work because the team paid attention. The 20% that isn’t fine tends to cluster in specific places. Authentication flows that were rushed. Dependency chains that nobody has audited since adoption. Internal services that were meant to be temporary. Database access patterns that scaled past their original design. Legacy integrations that someone inherited and never fully understood.

That 20% is where an AI-assisted attacker would go first. It is also where an AI-assisted reviewer would find issues first. The same capability that makes the attack faster makes the defence faster. The teams that will be fine are the teams that point the capability at their own 20% before someone else does.

That reframe is the whole point. This is not a story about your codebase being suddenly broken. It is a story about the 20% of it that was always a problem now being a problem with a timer on it.

What Decision-Makers Should Actually Do This Quarter

Condensed, practical, and ordered roughly by leverage per unit of effort.

1. Audit Your 20%, Not Your Whole Codebase

Don’t boil the ocean. Identify the specific services, integrations, and dependencies that are the most brittle, the most privileged, or the least observed. The goal is a prioritised list of the places where a serious vulnerability finding would cause the most damage, not a complete inventory.

2. Measure Remediation Speed as a First-Class Metric

Pick a real incident from the last twelve months and run the timeline. Flaw reported to fix deployed: how long? Break it down by stage: triage, fix development, test, deploy, verify. The bottleneck is probably not where you think.

3. Put AI on Both Sides of the Pipeline

If your team is using Cursor, Claude Code, or Copilot to write code and not using equivalent capability to review it, you are already behind the curve that existed before Mythos. The discipline worth building now is AI-assisted code review on every pull request touching sensitive paths: auth, payments, data access, third-party integrations. We covered the specifics in the AI PR review checklist.

4. Treat Modernisation Budget as Risk Budget

The old argument against modernising legacy systems was that it costs too much for what it returns. That math changes when the cost of not modernising is a surface area that can be mapped in hours by a model you don’t control. For most mid-sized companies, there are one or two systems that have been sitting on the “eventually” list for years. Those systems are now decisions, not aspirations.

5. Expect Supervisory and Customer Questions

If you serve regulated industries, such as finance, healthcare, or critical infrastructure, expect your customers and their regulators to ask about AI cyber risk posture before the end of Q2. The question will not be “do you use Mythos.” It will be “how have you adapted your SDLC to the capability shift.” Having an answer ready is cheaper than being asked on a compliance call without one.

6. Revisit Dependency and Vendor Governance

The Forrester analysis on Glasswing made a point worth repeating: Mythos surfaced vulnerabilities in open-source projects that were 16 and 27 years old, maintained by small volunteer teams. A lot of enterprise software depends on those same projects. Your dependency tree is now part of your attack surface in a more immediate sense than it was a year ago. Knowing what you ship inside your product matters more than it used to.

The Governance Layer: A Brief Note

Worth acknowledging honestly. Yoshua Bengio and others have raised a legitimate concern about concentration of power. Their argument is that frontier cyber capability, if it sits inside a small group of private labs and approved partners, creates a governance asymmetry that is difficult to resolve after the fact. That concern is real. It is also largely outside the scope of what any individual engineering organisation can act on this quarter.

For businesses operating in emerging markets, smaller jurisdictions, or sectors that aren’t named on the Glasswing partner list, the practical implication is that external tooling advantages will arrive unevenly. That makes internal engineering discipline (architectural resilience, cloud governance, observability, secure-by-default defaults) more important, not less. The companies that will weather the governance asymmetry best are the ones whose security posture does not depend on having the newest model.

What We’re Telling Clients This Month

The posture shift we’re recommending is not a replatforming. It’s a reprioritisation. Most of the teams we work with already know, at some level, which of their services are the fragile ones. What they haven’t done is treat remediation speed on those services as a sprint goal. That is the change this quarter.

For teams already using AI coding assistants to build apps, the specific work looks like this: tighten the code review loop on auth, payment, and data-access code; get explicit about which files an AI-generated PR can touch without a second pair of eyes; measure and shorten the cycle between a finding, from any source (manual audit, automated scanner, bug bounty), and a verified fix in production.

For teams running agentic systems, where you’ve got LLM-based agents calling tools, making decisions, or interacting with production data, the surface area is broader still. Agent memory, tool-call auditing, and orchestration failure modes are now part of the security perimeter in a way they haven’t historically been. That conversation is its own post. If you’re at that scale, we’d point you at the senior engineering checklist for agentic codebases.

None of this requires a new stack. It requires that the engineering discipline you’ve been planning to tighten for the last two years is tightened in the next two quarters instead.

The Line Worth Remembering

Claude Mythos may or may not be the model people look back on as the turning point. Project Glasswing may or may not be the program that history records as the moment industry governance got real. The specific names may not matter in five years.

What will matter is the shift they both made legible. Advanced AI is no longer just helping teams write software. It is beginning to understand, test, and break software at a level that forces a rethink of how technology gets built and maintained. That rethink is not theoretical. It is the next two quarters of your roadmap.

The era of “we’ll secure it later” was already fragile. Frontier AI may have just ended it. The teams that will be fine are not the ones with the most advanced tooling. They are the ones with the shortest distance between a flaw being found and a fix being shipped.

That distance is the discipline. The rest is execution.

The hard parts of this shift are the ones your roadmap doesn’t budget for.

Threat modelling at architecture stage. AI-assisted code review on every PR. Remediation cycles measured in hours, not weeks. This is the work our senior engineers at IT Path Solutions embed to do, inside the teams already shipping fast, without breaking their cadence.

Book a Free Consultation