In April 2026, Anthropic announced Claude Mythos — its most capable AI model to date — but chose not to release it publicly due to unprecedented cybersecurity risk. Instead, Anthropic launched Project Glasswing, a defensive coalition of over 50 major technology organisations tasked with finding and fixing critical software vulnerabilities before similar capabilities proliferate.
What is Claude Mythos?
Like previous Claude models, Anthropic’s newest frontier AI model, Mythos, is a general-purpose large language model (LLM) capable of reasoning, writing code, and solving complex problems. What distinguishes Mythos from its predecessors is a step-change improvement in autonomous cybersecurity tasks.
According to Anthropic’s official system card and Frontier Red Team blog, Mythos Preview demonstrated the ability to independently discover thousands of previously unknown software vulnerabilities across every major operating system and web browser, and develop working exploits without human guidance.
Critically, Anthropic assessed that these capabilities exceeded those of previous models by a significant margin and were advanced enough to present a dual-use risk: the same skills that accelerate defensive vulnerability discovery could, in the wrong hands, dramatically lower the barrier to large-scale cyberattacks.
On that basis, Anthropic decided not to make Claude Mythos Preview generally available.
What is Project Glasswing?
Rather than withholding its new model entirely, Anthropic launched Project Glasswing on the same day as the Mythos Preview announcement. Project Glasswing is a defensive cybersecurity initiative that provides controlled access to Claude Mythos Preview to a curated set of organisations responsible for globally critical software infrastructure.
Named launch partners include:
- Amazon Web Services
- Apple
- Broadcom
- Cisco
- CrowdStrike
- JPMorganChase
- The Linux Foundation
- Microsoft
- NVIDIA
- Palo Alto Networks
More than 40 additional organisations with roles in critical software infrastructure have also received access. Anthropic has committed USD $100 million in usage credits to support participants, alongside direct funding for open-source security work.
Project Glasswing’s stated purpose is to use Mythos Preview’s capabilities to find and remediate critical vulnerabilities before similar AI capabilities become widely accessible, effectively creating a window for defenders to reduce the global software attack surface ahead of broader proliferation.
Anthropic has stated that it does not plan to make Mythos Preview generally available but intends, over time, to develop safeguards that will allow Mythos-class capabilities to be deployed safely at scale.
Why Project Glasswing matters now
AI can accelerate vulnerability discovery and exploitation
Traditional security research relies on skilled human analysts manually working through large code bases, or on specialised tooling that scans for known vulnerability patterns. Both approaches are time-intensive and produce incomplete coverage of complex, real-world codebases.
Advanced AI models like Claude Mythos Preview represent a different class of capability. These systems can read and reason about large volumes of code, identify subtle logical flaws, and in documented cases, autonomously develop working exploits. At a conceptual level, this shifts the economics of vulnerability discovery. Tasks that previously required months of expert effort may become achievable in hours or minutes.
Connected products can potentially be impacted
For OEMs whose products contain embedded software — whether in smart appliances, industrial controllers, medical devices, or transportation systems — the relevant concern is not today’s adversarial capability, but the trajectory.
Two characteristics of embedded products make them particularly worth examining in this context:
- Long deployment lifetimes: Many embedded systems operate for 10–30 years after manufacture. Software that was considered secure at certification may contain latent vulnerabilities that were never identified due to prior tooling limitations, but could, in principle, be discovered by more capable systems in the future.
- Constrained update pathways: Unlike enterprise software, many embedded products lack reliable over-the-air update mechanisms, particularly in regulated environments. This can mean that even a known vulnerability remains unpatched in the field for extended periods.
Neither of these characteristics is new. What Project Glasswing signals is that the speed and breadth of vulnerability discovery may increase, and that the window between discovery and exploitation could shorten.
The extent to which these dynamics translate into actual attacks on specific embedded product categories within a defined timeframe is not precisely predictable, so OEM teams should treat this as a risk-planning horizon rather than a fixed outcome.
Implications for the EMS product lifecycle
Design and architecture
Secure-by-design principles are the most efficient point of intervention. Products architected with minimal attack surface, hardware-enforced trust boundaries, and defence-in-depth are more resilient to both current and future vulnerability discoveries, regardless of the discovery method. Threat modelling during early design stages, rather than as a late-stage audit, is increasingly the expected baseline under frameworks including IEC 62443, ETSI EN 303 645, and the EU Cyber Resilience Act.
Component selection decisions made at the design stage, including the choice of third-party open-source libraries, connectivity stacks, and SoC firmware, determine much of the downstream vulnerability surface. Proactive assessment of component security posture, including history of known vulnerabilities and vendor patch cadence, should be part of the standard design review process.
Verification and validation
Secure firmware practices, including code signing, boot chain integrity verification, and separation of privileged execution contexts, reduce the exploitability of vulnerabilities even when they are present. These practices are well-established; where they are not already implemented in a product line, prioritisation is warranted.
Software Bill of Materials (SBOM) and Vulnerability Exploitability eXchange (VEX) documentation are increasingly required by regulation and customer procurement in sectors including medical and defence. Maintaining a current SBOM enables faster triage when new vulnerability disclosures affect components used in a product.
Fuzz testing at scale — the automated generation of malformed inputs to identify unexpected software behaviour — is a well-supported technique for finding vulnerabilities earlier in the development cycle. AI-assisted tooling is beginning to improve coverage and efficiency here, offering OEM teams access to previously scarce capabilities.
Manufacturing and supply chain
The manufacturing phase is a critical control point for device identity and cryptographic credential provisioning. Products shipped without unique device identities or with default credentials that are not changed at commissioning represent preventable exposure.
Secure provisioning, such as the controlled injection of unique keys, certificates, and configuration at manufacture, establishes a verifiable root of trust that supports lifecycle management.
Supply chain integrity, ensuring that components and firmware are authentic and have not been tampered with between manufacture and field deployment, is a related concern. Trusted component sourcing, chain-of-custody documentation, and bill-of-materials verification are all relevant controls.
Field operations and lifecycle management
Over-the-air (OTA) update capability is increasingly a product design requirement rather than an optional feature. Products that can receive authenticated, integrity-checked firmware updates retain the ability to respond to newly discovered vulnerabilities throughout their deployed lifetime. Where OTA is not feasible — for example, in certain safety-certified environments — defined patch delivery and service processes, including field update procedures, provide a fallback.
Patch SLA policies with defined commitments to assess and respond to disclosed vulnerabilities within a stated timeframe are becoming standard in regulated sectors and are expected by sophisticated OEM customers. End-of-life strategies that define the point at which security support ceases, and communicate this clearly to customers, are equally important for long-lifecycle products.
What OEMs should do now
1. Understand your current exposure
- Convene a brief cross-functional call to review what Claude Mythos and Project Glasswing mean for your product portfolio.
- Identify which products in your portfolio contain components from the major OS, browser, or open-source libraries confirmed to have been scanned under Project Glasswing (Linux kernel, major RTOS variants, common networking stacks).
- Check in with key software component suppliers to understand whether they are Project Glasswing participants or have received Glasswing-patched vulnerability disclosures, and what their patch release timeline is.
- Designate an internal owner for tracking vulnerability disclosures relevant to your product lines.
2. Strengthen your baseline
- Conduct an SBOM inventory check across your active product portfolio. If no current SBOM exists for a product, initiate one. Identify which third-party open-source components are used and their current patch status.
- Review your current update and patch policy. Identify products that lack OTA update capability and assess whether field update procedures are documented and can be exercised.
- Initiate a threat-modelling exercise on one flagship or highest-revenue product, using a structured methodology such as STRIDE or TARA, with findings reviewed against current design decisions.
- Review your current supplier security questionnaire and procurement criteria; ensure they include questions about SBOM provision, patch cadence, and secure provisioning capability.
3. Build systematic capability
- Integrate fuzz testing or equivalent dynamic analysis into your firmware development pipeline for at least one active product development programme.
- Pilot a secure provisioning process at manufacturing, including unique device identity and credential injection, on a new or next-revision product.
- Conduct a tabletop incident response exercise simulating a scenario in which a zero-day vulnerability is publicly disclosed, affecting a component used in your deployed product fleet. Identify gaps in detection, triage, and customer communication processes.
- Benchmark your current cybersecurity practices against the applicable regulatory framework for your target markets.
4. Establish a durable posture
- Develop or update a product security roadmap that addresses architecture refresh priorities, secure-by-design requirements for next-generation products, and technology debt items in current-generation products.
- Formalise patch SLAs for your active product lines, defining maximum response times for critical, high, and medium-severity disclosures, and communicate them to key customers.
- Establish a third-party security assessment cadence, including penetration testing, component vulnerability scanning, or supply chain review, appropriate to your product risk profile and regulatory obligations.
- Engage your EMS partner in a structured review of secure provisioning, SBOM provision, and manufacturing-phase security controls for any products entering design or production refresh.
How an EMS partner like ESCATEC can help
The emergence of AI-driven vulnerability discovery reinforces something we have observed building across our customer base over recent years: cybersecurity is no longer a separate workstream appended to a hardware project. It is a foundational quality dimension that affects design choices, supplier selection, manufacturing processes, and field service expectations.
Taking a secure-by-design approach, we support OEM engineering teams in assessing product architectures for security risk early in the design cycle, including component selection, connectivity surface, and debug/update interface exposure. We also offer SBOM and VEX support, helping customers develop and maintain software bill of materials documentation for products we manufacture, supporting traceability and vulnerability triage.
Our secure provisioning practices ensure manufacturing-phase provisioning processes that inject unique device credentials, cryptographic keys, and configuration in controlled, auditable conditions, while our trusted supply chain practices include authorised channel procurement and component authenticity controls relevant to embedded product integrity.
When it comes to compliance-readiness, we assist customers in documenting manufacturing-phase evidence for cybersecurity regulatory submissions, including IEC 62443, ETSI EN 303 645, and the EU Cyber Resilience Act.
Post-production, we also offer lifecycle patch and field support by providing post-market logistics and field service options relevant to products requiring firmware update delivery or managed EOL transitions.
Conclusion: Taking a balanced perspective
Claude Mythos and Project Glasswing represent a genuine inflexion point in the security landscape; what is unclear is the rate at which comparable capabilities will proliferate to other actors, the extent to which embedded product categories in OEM markets will be specifically targeted, and whether the defensive window created by Glasswing will close before widespread exposure occurs.
The responsible response is to treat AI-accelerated vulnerability discovery as a trend that is directionally established and likely to intensify, without forecasting specific failure modes or timelines that cannot currently be substantiated. Overreaction — such as product recalls not supported by specific vulnerability evidence — is as counterproductive as inaction.
Anthropic’s decision to restrict Mythos and invest in defensive infrastructure reflects a considered judgement about dual-use risk. The EMS and OEM community can play a complementary role by building products that are harder to exploit, more transparent in their software composition, and more capable of receiving security updates throughout their operational life.
If you’re an OEM engineering, product, or compliance leader looking to understand how the emerging AI security landscape affects your product portfolio, ESCATEC can help you get started. Contact us now to find out more.
FAQs
1. Do we need to recall our existing products because of Claude Mythos?
Not on the basis of this announcement alone. A recall is warranted when a specific, confirmed vulnerability in your product presents a defined safety or security risk to users and cannot be adequately mitigated by a software update or configuration change. Claude Mythos Preview’s capabilities accelerate the discovery of vulnerabilities; they do not automatically mean that your specific products contain exploitable flaws that adversaries have already discovered. The appropriate response is a structured vulnerability assessment of your software components and a review of your existing patch and update processes.
2. What data and documentation should we have ready?
The most useful preparatory step is to assemble or verify your Software Bill of Materials (SBOM) for each active product. An SBOM lists all software components, including third-party and open-source libraries, their versions, and their known vulnerability status. Complementary documents include your current threat model (if one exists), your firmware update and patch policy, your product End-Of-Life schedule, and any existing security certifications or test reports. If you do not have a current SBOM, this is the highest-priority document to create. Your EMS partner should be able to assist with the manufacturing-phase component of this documentation.
3. How do we prioritise which products or vulnerabilities to address first?
Products with network connectivity, products deployed in safety-critical environments, and products running software components with known long-standing vulnerabilities or poor patch cadence should be reviewed first. Within a given product, apply a standard vulnerability severity framework (e.g., CVSS) to triage disclosed vulnerabilities. Where an SBOM exists, map current disclosures from the National Vulnerability Database (NVD) or vendor security advisories against your component list. Where it does not, creating the SBOM is the prerequisite to structured triage.
