Author: Paul Gedeon
Anthropic’s Project Glasswing should not be read as another impressive AI demo. It should be read as a warning about time.
According to Anthropic and reporting from TechCrunch, Claude Mythos Preview, a restricted frontier model used by a small group of partner organizations, identified thousands of zero-day vulnerabilities across major software ecosystems in only a few weeks. Many of these vulnerabilities were described as critical, and some had apparently existed for one or two decades.1
The obvious reaction is amazement. The more useful reaction is discomfort.
If an AI system can uncover this many unknown vulnerabilities in mature, widely reviewed codebases, then the industry has to confront an unpleasant conclusion: many software security programs have been operating with a false sense of depth. We were not necessarily secure because the vulnerabilities were absent. We were secure because the economics of finding them were expensive, slow, and unevenly distributed.
AI changes those economics.
The important question is not whether Claude Mythos is uniquely powerful, or whether every claim made around Project Glasswing will survive independent scrutiny. The important question is what happens when vulnerability discovery becomes cheaper, faster, and more automated. That shift affects operating systems, open-source dependencies, firmware, IoT devices, OT environments, connected vehicles, medical devices, routers, and every product category that quietly carries legacy code forward because “it still works.”
That sentence has always done a lot of damage.
For years, product security has depended on a manageable imbalance. Attackers had to choose targets, invest time in reverse engineering, build exploit chains, and decide whether the payoff was worth the effort. Defenders were slow too, but the slowness was survivable because vulnerability discovery itself remained a bottleneck.
If AI-assisted discovery removes that bottleneck, the whole model changes.
A vulnerability that sat unnoticed for fifteen years is not harmless. It is simply undiscovered debt. The moment automated systems can enumerate that debt at scale, old code becomes newly dangerous. This is especially true for connected products, where software lifecycles are long, update mechanisms are inconsistent, and embedded components are reused across multiple product generations.2
The risk is not limited to “big tech” operating systems. In many ways, the more fragile domain is embedded in industrial software. IoT and OT products often contain old kernels, vendor SDKs, forked libraries, outdated web servers, custom protocol parsers, legacy crypto, and third-party components that nobody inside the manufacturer fully owns anymore. 3Some devices remain deployed for ten or twenty years. Some cannot be easily patched. Some were never designed with a realistic vulnerability management process in mind.
That is exactly the kind of environment where AI-assisted vulnerability discovery becomes strategically significant.
The defensive promise is real. If a model can help maintainers find and fix vulnerabilities before attackers exploit them, that is valuable. Open-source maintainers are overburdened, product security teams are understaffed, and critical infrastructure depends on codebases that few people deeply understand. Used responsibly, AI can act as a force multiplier for review, triage, root cause analysis, patch suggestion, and variant hunting.
But the offensive symmetry is impossible to ignore. The same capability that helps a defender find a memory corruption bug in a protocol parser can help an attacker find it too. The difference is access, governance, and intent, not the underlying technical direction. Anthropic’s decision to restrict Mythos rather than release it broadly is therefore not just a product choice. It is an implicit admission that frontier cyber capabilities can have dual-use consequences.4
That raises a serious policy and market question: who gets the head start?
Project Glasswing gives selected large organizations early access to frontier AI for defensive security. That may be sensible from a risk-control perspective, but it also creates an asymmetry inside the defender community. Large platform companies and major infrastructure providers may gain faster visibility into vulnerability classes that smaller manufacturers, open-source projects, and downstream product vendors cannot detect at the same speed.
This matters because software supply chains are not flat. A vulnerability found in a shared component does not only affect the company that discovers it. It affects every product that integrates it, often without clean dependency tracking or a maintained update path. If AI-assisted scanning becomes a premium capability available mainly to the largest organizations, then the security gap between mature and immature manufacturers will widen.
For connected product manufacturers, this is where the Cyber Resilience Act becomes very concrete.
The CRA pushes manufacturers toward secure-by-design obligations, vulnerability handling, coordinated disclosure, software updates, and reporting of actively exploited vulnerabilities.5 These requirements are often discussed as compliance tasks. They should be understood as operational readiness requirements.
AI-assisted vulnerability discovery changes what “without undue delay” means in practice. It compresses the interval between latent vulnerability and known vulnerability. It also increases the likelihood that multiple parties discover similar bugs independently. A manufacturer that cannot identify its affected products, map dependencies, contact suppliers, assess exploitability, prepare advisories, and ship fixes quickly will not merely be slow. It will be structurally unprepared for the new discovery environment.

SBOMs and HBOMs become more important in this context, but not because they magically make products secure. They do not. A badly maintained SBOMor HBOM is a spreadsheet-shaped comfort blanket. Useful, perhaps, but not protective.
The real value of an SBOM/HBOM is operational speed. When a vulnerability is discovered in a component, the manufacturer needs to answer basic questions immediately: Do we use this component? In which products? Which versions? Which firmware branches? Which customers are affected? Is the component reachable? Is there a mitigation? Who owns the fix?
Without that inventory, AI-assisted discovery becomes a weapon pointed at organizational confusion.
This is the part many companies still underestimate. Product security is not only a technical discipline. It is a logistics discipline. The winners will not simply be the teams with the best scanners. They will be the teams that can turn discovery into controlled action: reproduce, prioritize, patch, validate, communicate, and monitor.
The industry also needs to be careful with the phrase “zero-day.” Thousands of zero-days sounds dramatic, and it is. But not every unknown vulnerability has the same exploitability, reachability, or real-world impact. A critical bug in a default network-exposed parser is not the same as a crash in a rarely used local tool. AI-generated findings still need validation, severity assessment, exploitability analysis, and context.

This is where human security expertise remains essential. AI can accelerate discovery, but it can also flood teams with findings that require triage. If organizations respond by dumping thousands of model-generated reports onto maintainers without reproductions, patches, or prioritization, they will not improve security. They will industrialize noise.
That is the uncomfortable middle ground: AI vulnerability discovery is both powerful and insufficient. It can find more problems than humans can manually inspect, but it does not automatically create a mature vulnerability management process. It exposes the maturity gap.
For manufacturers of connected products, the practical conclusion is clear. Treat AI-assisted vulnerability discovery as part of the threat model now. Not in five years. Not when the tools become public. Now.
That means product teams need to assume that attackers will increasingly use automation to search for old bug classes, variant vulnerabilities, and forgotten dependencies across firmware and software stacks. Legacy code should be reviewed not only because regulation demands it, but because its risk profile has changed. Old vulnerabilities are no longer buried as deeply as they used to be.
It also means supplier security can no longer be handled as a checkbox exercise. If a product depends on third-party modules, SDKs, chip vendor libraries, cloud connectors, mobile apps, or open-source packages, the manufacturer needs a real answer for how those suppliers discover, disclose, and patch vulnerabilities. “We asked them once during procurement” is not a process. It is paperwork cosplay.
The most important shift is cultural. Many companies still treat vulnerability discovery as an exceptional event. Something external happens, a CVE appears, the security team reacts, and the organization returns to normal. AI-assisted discovery suggests that this rhythm may not survive. Discovery may become continuous. Variant analysis may become continuous. The pressure to patch may become continuous.
That does not mean panic is useful. Panic produces bad prioritization and broken patches. But complacency is worse. The correct response is disciplined acceleration.
Build and maintain accurate SBOMs. Map components to products. Test update mechanisms before a crisis. Define disclosure of ownership. Exercise 24-hour reporting workflows. Know which products are end-of-life but still exposed. Require suppliers to provide vulnerability handling commitments. Use AI defensively where possible, but do not confuse tool adoption with program maturity.
Project Glasswing is significant because it reveals a future that is already arriving unevenly. Some defenders will get faster. Some attackers will get faster. Some manufacturers will discover that their security processes were built for a slower era.
That is the real story.
AI is not only changing how software is written. It is changing how quickly old software can be interrogated. The buried flaws were already there. The difference is that the shovel just became automated.

- The Hacker News, “Anthropic’s Claude Mythos Finds Zero-Day Vulnerabilities,” The Hacker News, April 2026, accessed May 11, 2026, https://thehackernews.com/2026/04/anthropics-claude-mythos-finds.html. ↩︎
- National Institute of Standards and Technology (NIST), “IoT Device Cybersecurity Guidance for the Federal Government: Establishing IoT Device Cybersecurity Requirements,” NIST Special Publication 800-213, November 2021, accessed May 11, 2026, https://csrc.nist.gov/publications/detail/sp/800-213/final. ↩︎
- European Telecommunications Standards Institute (ETSI), “Cyber Security for Consumer Internet of Things: Baseline Requirements,” ETSI EN 303 645, accessed May 11, 2026, https://www.etsi.org/technologies/consumer-iot-security. ↩︎
- VentureBeat, “Anthropic Says Its Most Powerful AI Cyber Model Is Too Dangerous to Release,” VentureBeat, accessed May 11, 2026, https://venturebeat.com/technology/anthropic-says-its-most-powerful-ai-cyber-model-is-too-dangerous-to-release. ↩︎
- European Commission, “Cyber Resilience Act,” Shaping Europe’s Digital Future, accessed May 11, 2026, https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act. ↩︎







Leave a Reply