Failure as Signal: Mythos, Glasswing, and the New Cyber Defense Loop

Anthropic’s April 7, 2026 Mythos / Project Glasswing announcement is not interesting because a frontier model is good at code.

That sentence stopped being interesting a while ago.

What’s interesting is the admission embedded in the announcement:

vulnerability discovery, exploit generation, triage, disclosure, patching, and safeguard-building are collapsing into one machine-accelerated learning loop

That is the part worth paying attention to.

Project Glasswing is the smart part of the announcement because it recognizes that the transition period matters more than the headline benchmark. If models are now strong enough to find old bugs in hardened code, turn N-days into exploits, and help non-experts produce working offensive artifacts overnight, then the only sane move is to try to force those capabilities into the defensive side of the ecosystem before they spread everywhere else.

That is not hype. That is contingency planning.

The short version

Mythos Preview matters because it shows that software failure is becoming machine-readable learning material. Cyber capability is no longer just a matter of smarter models. It is becoming a closed loop: find failures, validate them, exploit them, disclose them, patch them, and feed the results back into the next round of evaluation and safeguards.

Or in plainer language:

The benchmark is becoming the bug report. The bug report is becoming the patch. The patch is becoming the next benchmark.

That’s a different world.

More bluntly:

The engine is not the model by itself. The engine is the loop.

Failure -> Hypothesis -> Experiment -> Reproduction -> Severity Scoring -> Patch / Disclosure -> Memory Update

That is the architecture shift.

What Anthropic actually said

Anthropic’s technical write-up on Claude Mythos Preview makes several claims that would have sounded absurdly aggressive not very long ago:

• the model can identify and exploit zero-days in every major operating system and every major web browser

• it found a now-patched 27-year-old OpenBSD bug

• it wrote a browser exploit chaining four vulnerabilities with a JIT heap spray that escaped renderer and OS sandboxes

• it turned known-but-not-yet-patched vulnerabilities into working exploits

• it was usable by Anthropic engineers with no formal security background to find remote code execution bugs overnight

The part that matters even more than the examples is the framing around them.

Anthropic says Mythos Preview did not receive explicit exploit-specialized training. These capabilities emerged downstream from better code ability, better reasoning, and better autonomy. The same improvements that make the model better at fixing vulnerabilities also make it better at exploiting them.

That sentence should rearrange a lot of priors.

For years, people could pretend “helpful coding model” and “dangerous offensive capability” were separable categories. Mythos is a nice demonstration that they are much closer to being the same slope on the same curve.

This is also a long-horizon competence story

Another way to say this: Mythos matters because it is not only better at spotting something interesting. It is better at staying with a problem long enough to turn that interest into an outcome.

Anthropic’s own scaffold makes that clear. The model is not just asked for a guess. It is dropped into a container with source code and told, roughly, find a security vulnerability. Then it:

• reads code

• forms hypotheses

• runs the target

• confirms or rejects suspicions

• adds debugging or instrumentation

• repeats the loop

• produces a bug report

• and sometimes produces a proof-of-concept exploit

That is not a one-shot completion problem. That is a long-horizon, multi-step persistence problem.

And I think that matters because a lot of what people loosely call “AI cyber capability” is still imagined as glorified autocomplete with better taste. Mythos reads more like something else:

the system can hold onto an objective across enough steps to cross the distance between weak signal and usable artifact

That is the part I care about.

Exploit development is full of places where raw intelligence is not enough on its own. You need enough continuity to:

• keep state across failed attempts

• compare candidate explanations

• use one crash as evidence for the next move

• follow a chain from parser bug to primitive to exploit path

• stop only when the artifact is strong enough to validate

That is exactly why I think the long-horizon theme on this site matters here. The interesting shift is not merely “models know more security.” It is that they are getting better at carrying a line of work across enough sequential steps for real capability to show up.

The tier numbers are the part that makes this real

If someone wanted one paragraph from Anthropic’s write-up that justifies taking this seriously, I would not actually start with the OpenBSD anecdote.

I would start with the tier ladder.

Anthropic says they run models against roughly a thousand OSS-Fuzz repositories and grade the worst crash they can produce on a five-tier severity ladder:

• tier 1 — basic crashes

• tier 5 — complete control-flow hijack

Against roughly 7000 entry points:

• Sonnet 4.6 and Opus 4.6 reached tier 1 in roughly 150 to 175 cases

• both reached tier 2 about 100 times

• each reached only one tier 3 crash

Mythos Preview, by contrast:

• hit 595 crashes at tiers 1 and 2

• added a handful at tiers 3 and 4

• achieved full control-flow hijack on ten separate, fully patched targets

That is not a normal incremental improvement. That is a change in kind.

The reason those numbers matter is that they show the system is not merely getting better at producing “some evidence of breakage.” It is climbing the ladder toward weaponizable failure. The leap is not just more crashes. It is more severe crashes, and more of them, with a small but very important movement into the part of the spectrum where exploitability becomes the point.

That is why I think your instinct is right to highlight them. They make the argument falsifiable and concrete.

Project Glasswing is the defensive recognition layer

The companion announcement, Project Glasswing, is Anthropic’s attempt to operationalize that reality instead of merely describing it.

They brought together Amazon Web Services, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorganChase, the Linux Foundation, Microsoft, NVIDIA, Palo Alto Networks, and others around one core fact:

these capabilities are arriving faster than the ordinary patch, disclosure, and defense ecosystem is prepared to absorb them

So instead of treating the model as a standalone research trophy, they are seeding it into the parts of the ecosystem that carry a ridiculous fraction of the world’s shared attack surface.

That is why Glasswing is more important than the usual model-launch theater.

The announcement includes:

• up to $100M in usage credits

• direct funding for open-source security organizations

• early access for maintainers and critical-software defenders

• a commitment to publish what they learn about disclosure, triage, patching, and secure-by-design practice

Cisco’s companion post says the quiet part out loud: defenders are going to have to operate at the speed of machines and the scale of networks. That sounds dramatic until you remember that attackers have been trying to do exactly that for years already. The difference now is that the search cost is collapsing.

So the new contest is not simply:

who has the better firewall

It is:

who can operate the learning loop faster

The benchmark is not the benchmark anymore

This is the part that landed hardest for me.

Anthropic says Mythos Preview has improved enough that it mostly saturates their prior benchmarks, so they shifted toward novel real-world security tasks. That move is not just sensible benchmark hygiene. It is a signal that static reproduction tasks are no longer enough to distinguish “the model remembered a known exploit” from “the model genuinely discovered something new.”

Their solution is exactly the correct one:

• use zero-day discovery when you want proof of genuine capability

• validate with strong oracles where possible

• human-triage the output

• responsibly disclose the result

• wait for patching

• then turn the resulting artifacts into the next body of evidence

That is not a benchmark in the old sense.

That is a learning system wrapped around real software failure.

And yes, that is very close to what I mean elsewhere on this site when I say failure is the second memory.

This is agentic empirical security research

The right way to read Mythos is not:

• cyber chatbot

• AI SOC assistant

• RAG over CVEs

The deeper architecture is:

agentic empirical research applied to vulnerability discovery

Anthropic is basically showing a transition from:

Can the model answer security questions?

to:

Can the model run an empirical security loop: hypothesize, test, fail, update, reproduce, validate, and disclose?

That is a much bigger deal than “good answers about cyber.”

They are taking failures as learning

This is the line hiding in plain sight across the Mythos and Glasswing material.

What they are building is not only a model that scores high on cyber tasks. They are building an apparatus where discovered failures become structured inputs to the next round of defense work.

One nuance matters here.

I do not think the strongest version of the claim is:

the model saw a patch and literally trained online from it

That may eventually happen in some systems, but that is not the part I would lean on here because it is stronger than what Anthropic actually had to say publicly.

The stronger defensible version is this:

validated failures, exploit writeups, patch diffs, disclosure artifacts, and regression cases are becoming reusable evidence in the next exploit / defense loop

That is already enough to matter.

Once a model or scaffold can:

• find a vulnerability

• validate it with a strong oracle

• turn it into a report

• sometimes turn it into an exploit

• hand it to humans for triage

• wait for patching

• and then reintroduce the patched case as a new evaluation or safeguard example

you no longer need mystical online learning for the system to be “learning from failures” in the operational sense. The loop itself is the learning mechanism.

That is also why the long-horizon point and the failure point reinforce each other.

A short-horizon system can notice a suspicious crash. A longer-horizon system can keep pushing until the crash becomes:

• a primitive

• an exploit sketch

• a validated report

• a disclosure artifact

• and later a regression case

In other words, horizon length is part of what turns “interesting signal” into “usable security work.”

The loop looks like this:

        flowchart LR
  A[agentic vulnerability search] --> B[validated failure]
  B --> C[human triage]
  C --> D[coordinated disclosure]
  D --> E[patch / mitigation]
  E --> F[new safeguards<br/>and evaluation cases]
  F -.-> A
    

That is the important move.

Not “the model found a bug.” Plenty of systems find bugs.

The meaningful part is that each failure now becomes:

• evidence of real capability

• a prioritization signal

• a disclosure artifact

• a patch target

• an exploit-development starting point

• a future regression test

• a future safeguard example

• a reusable case for the next scaffold to reason over

The benchmark is no longer sitting on a shelf waiting to be downloaded.

The benchmark is being carved out of the system’s own encounter with reality.

That is why this announcement maps so cleanly onto my work on structured failure traces and failure-induced benchmarks. The same reframe applies:

You do not throw the failure away. You turn it into the next instrument.

Oracle E-Business Suite is the transition-period warning

If Mythos and Glasswing describe the coming loop, the Oracle E-Business Suite campaign is the reality check for what happens in the meantime.

Google Threat Intelligence Group and Mandiant described a large-scale extortion campaign targeting Oracle EBS customers, with threat actors exploiting what may be CVE-2025-61882 as a zero-day and then using the compromise for data theft and extortion. watchTowr’s technical analysis of one public exploit chain is a useful reminder that catastrophic intrusion often isn’t one beautiful bug. It is a composition of several medium-sized mistakes:

• SSRF

• CRLF injection

• authentication-filter bypass

• XSL-based code execution

Which is to say: the exploit chain is ugly in the realistic way.

That matters because compositional exploit construction is exactly the kind of thing these models seem to be getting better at. Not just “spot a trivial stack overflow.” More like:

find three or four separately survivable weaknesses, understand how they compose, and then turn that composition into a working offensive path

The Oracle EBS story is the warning flare for the transition period.

The campaign structure was already effective before Mythos-class models became normal:

1. discover or acquire a zero-day

2. hit many victims quickly

3. steal data quietly

4. delay extortion long enough that defenders stay blind

5. monetize at scale

Now imagine what happens when discovery and exploit-development costs drop further.

That is why Glasswing makes sense. The moment to build a coordinated defensive loop is before every actor with a grudge and a GPU rental account gets comparable leverage.

Past vulnerabilities are turning into exploit priors

This is the deeper connection I think is easy to miss if you only read the Mythos post as “wow, good model.”

The scary thing is not just raw bug-finding capacity. It is that the ecosystem is generating a growing library of:

• prior vulnerabilities

• patch diffs

• exploit writeups

• validated crash traces

• disclosed root-cause analyses

and those artifacts are exactly the kind of structured evidence a strong coding model can reason over.

So no, I would not phrase it as:

the model magically absorbs all past patches and becomes evil from them

That sounds mystical and slightly sloppy.

I would phrase it as:

past vulnerabilities and their patches are becoming a searchable prior over how software tends to fail, and capable models can use that prior to move faster from bug shape to exploit shape

That is a serious claim, and I think it correlates with what Anthropic is actually showing:

• N-days are easier to turn into exploits

• exploit construction is getting more compositional

• the move from “interesting crash” to “usable offensive path” is compressing

That is the part that should make defenders sweat a little.

The actual bottleneck is no longer “can the model find bugs?”

The model-finding-bugs part is becoming the easy part.

The hard parts are becoming:

• validation quality

• maintainer bandwidth

• disclosure pacing

• exploit-risk assessment

• patch rollout

• fleet-wide update speed

• proving which findings matter first

Anthropic’s coordinated vulnerability disclosure principles are interesting precisely because they read like an admission that maintainer attention is becoming the scarce resource. They explicitly talk about human review, pacing reports to what maintainers can absorb, compressed timelines for actively exploited critical bugs, and waiting after patch release before publishing full exploit details.

That is what reality looks like when the front end of the pipeline accelerates faster than the back end.

If the model can generate thousands of plausible high-severity findings, the bottleneck shifts from search to absorption. Which means the real defense problem becomes orchestration:

• which findings are real

• which findings are severe

• which findings are exploitable

• which ones should interrupt everyone else’s week immediately

That is not just a model problem. That is a systems problem.

How this connects to my own architecture language

This is the part that makes the Mythos / Glasswing moment feel less like outside commentary and more like a direct pressure test of my own work.

Mythos / Glasswing	My architecture language
vulnerability discovery	failure-induced benchmark generation
exploit reproduction	empirical validation artifact
crash triage	evaluation harness
responsible disclosure	provenance and trust boundary
OSS-Fuzz style testing	deterministic ingestion and reproducible runs
AI cyber defense	memory-first security intelligence loop
model-generated bug report	evidence, not authority

That last row matters a lot.

The model’s output is not truth. It is a claim. The system has to force that claim through reproduction, sandboxing, logs, hashes, disclosure status, patch status, and human review. Annoying, yes. Also how adults stop machines from becoming caffeinated raccoons with root access.

What this means for my own work

This is exactly why I keep coming back to provenance, event structure, and failure traces.

If failures are going to become learning, they cannot remain vibe-shaped.

A serious system needs a failure artifact that says:

• what the agent looked at

• which file or component it focused on

• what evidence confirmed the issue

• whether a human validated it

• how severe it was judged to be

• whether exploitation was demonstrated

• whether it was disclosed

• what patch or mitigation followed

• which future benchmark or safeguard case it became

Something more like this:

{
  "event_id": "uuid",
  "event_type": "vulnerability_candidate_validated",
  "source": {
    "kind": "agent_run",
    "model": "frontier_model",
    "scaffold_version": "v1"
  },
  "target": {
    "project": "critical-software-project",
    "component": "network_parser.c",
    "file_rank": 5
  },
  "evidence": {
    "oracle": "asan_crash",
    "reproduction_available": true,
    "exploit_demo": false
  },
  "triage": {
    "severity": "critical",
    "human_reviewed": true
  },
  "disclosure": {
    "status": "reported",
    "deadline_days": 90
  },
  "provenance": {
    "source_event_ids": ["uuid-1", "uuid-2"]
  }
}

Without that structure, “learning from failures” means “we remember that something bad happened once.”

With that structure, failure becomes a reusable research object.

If I wanted to compress the whole argument into five lines, it would be these:

Failures are not noise.
Failures are dataset seeds.
Failures are benchmark material.
Failures are model capability probes.
Failures are evidence for what the system does not yet understand.

That is the same argument I’ve been making everywhere else on this site:

• memory needs provenance

• long-horizon behavior needs state that survives across steps

• evaluation needs traces

• security needs forensics

• learning needs structure

Same law. Different artifact.

The line I want to keep

The single sentence I would keep from this entire moment is:

The most important shift is that failure is no longer just a bug report. Failure becomes training signal, evaluation material, benchmark substrate, disclosure evidence, and defensive memory.

The deeper doctrine

The main sentence I want to keep from this whole moment is:

The side that wins is the side that turns failures into patched systems faster than the other side turns them into exploits.

That is what Project Glasswing is betting on.

And honestly, I think that bet is correct.

The dangerous thing about Mythos is not merely that it can write exploits. The dangerous thing is that it makes the whole bug lifecycle more fluid:

• discovery compresses

• exploitation compresses

• patching can compress too, if the pipeline is built for it

Which means the real contest becomes about who has the better loop.

That is a research problem, an infrastructure problem, and a memory problem all at once.

Naturally, those are exactly the kinds of problems I care about.

Related reading on this site

• Security Research — the lane this article belongs to.

• Prompt injection, and why “just sanitize the input” isn’t enough — the AI-agent trust-boundary side of the same larger transition.

• GitHub’s git push RCE, and the rule it violated — another case where a systems boundary failed in a way that taught more than the bug itself.

• Structured failure traces — why failures need to become comparable objects.

• Failure-induced benchmarks — what it means to build the next benchmark out of the failure distribution you just observed.

Sources and citations

Direct sources

• Anthropic — Claude Mythos Preview
  Primary source for the Mythos Preview capability claims, the OSS-Fuzz evaluation setup, the five-tier crash severity ladder, the tier 1 through tier 5 results, the zero-day examples, and Anthropic’s framing that Mythos Preview will not be made generally available.

• Anthropic — Project Glasswing: Securing critical software for the AI era
  Primary source for Project Glasswing’s stated goal, partner ecosystem, defensive release posture, usage credits, open-source security support, and the claim that defenders need access before similar capabilities become broadly available.

• Anthropic — Coordinated vulnerability disclosure for Claude-discovered vulnerabilities
  Primary source for the disclosure operating principles referenced in the article: human review, maintainer pacing, standard 90-day disclosure windows, critical actively exploited vulnerability timelines, and delayed publication of full technical details after patches.

• Cisco — Rising to the Era of AI-Powered Cyber Defense
  Source for Cisco’s Project Glasswing perspective and the “speed of machines and scale of networks” defensive framing.

• Google Cloud / Mandiant — Oracle E-Business Suite Zero-Day Exploited in Widespread Extortion Campaign
  Source for the Oracle E-Business Suite transition-period example, including Google Threat Intelligence Group and Mandiant’s reporting on the extortion campaign and suspected zero-day exploitation.

• watchTowr Labs — Well, Well, Well. It’s Another Day. (Oracle E-Business Suite Pre-Auth RCE Chain - CVE-2025-61882)
  Source for the compositional exploit-chain framing referenced in the Oracle EBS section: SSRF, CRLF injection, authentication-filter bypass, and XSL-based code execution. The specific write-up is used here as technical context for why exploit construction often looks like several medium-sized failures chained together rather than one clean bug.

Background and related context

• Google — OSS-Fuzz documentation
  Background source for OSS-Fuzz as the open-source fuzzing corpus and infrastructure Anthropic references in the Mythos evaluation.

• Michał Zalewski — American Fuzzy Lop technical details
  Background source for coverage-guided fuzzing context. This is not the core evidence for Mythos, but it grounds the comparison to older fuzzing systems and the larger history of automated vulnerability discovery.

• The Next Web — Anthropic adds SpaceX compute and raises Opus API rate limits
  Related infrastructure context, not a source for the Mythos exploitability claims. Included because Anthropic’s recent compute expansion and Claude Code / Opus API limit increases are part of the same broader capability, access, and infrastructure picture.

• Anthropic — Higher limits and SpaceX compute
  Related primary context for Anthropic’s compute and rate-limit changes. This is not directly used in the Mythos argument, but it is relevant to the surrounding question of how frontier capability gets served, limited, and scaled.