AI-driven vulnerability discovery is getting attention because of Anthropic’s Project Glasswing and Claude Mythos Preview. Anthropic describes Project Glasswing as an initiative to secure critical software using early access to Claude Mythos Preview, a frontier model with strong cybersecurity capabilities. Project Glasswing includes launch partners such as AWS, Apple, Cisco, CrowdStrike, Google, JPMorganChase, Linux Foundation, Microsoft, NVIDIA, Palo Alto Networks, and others.
This raises a practical question: once a model like Mythos finds a vulnerability, what happens next?
The answer is that discovery is only the first step. A vulnerability does not become useful to software users simply because it has been found. It must move through validation, disclosure, fixing, publication, and then enterprise action.
Discovery is not the same as disclosure
When Mythos finds a vulnerability in an operating system, browser, library, or other software component, that does not mean the vulnerability is immediately visible to every enterprise or security vendor.
In many cases, the vulnerability details are first handled through coordinated disclosure. Anthropic says it aims to notify vendors and maintainers as soon as possible, and unless there is a security reason to do otherwise, it aims to share details publicly after 90 days or after a patch is released, whichever comes first.
This distinction matters. A vulnerability can be real, serious, and validated, but still not public. It may be known to Anthropic and the affected software owner but not yet known to enterprises that use the software.
Anthropic follows a structured disclosure process
Anthropic’s coordinated disclosure process follows industry standard principles: vendors and maintainers are notified first, findings are human reviewed before submission, and public disclosure follows a structured timeline that balances giving maintainers time to fix while ensuring defenders are not kept in the dark indefinitely. The process also accounts for situations like actively exploited vulnerabilities, ecosystem-wide patterns, and cases where maintainers are unresponsive. The details matter, and the disclosure policy is worth reading in full.
What enterprises need to take away is simple: A vulnerability found by Mythos does not become public immediately, and a patch being available does not mean exploitation details are public immediately either. There are structured windows between each stage and those windows have implications for how enterprises should think about their own exposure.
A simplified flow looks like this:
- Mythos identifies a potential vulnerability
- Anthropic triages and validates the finding
- The affected OEM or maintainer is notified
- The OEM or maintainer investigates affected versions
- A patch, workaround, or advisory is developed
- The issue becomes public or actionable
- Enterprises respond inside their environments
This is the part that is often missed. AI may accelerate discovery, but the software ecosystem still must convert discovery into something users can act on.
The software owner has the first responsibility
Once the affected OEM or open-source maintainer receives a validated report, they must investigate it.
They need to answer basic questions:
- Is the finding correct?
- Which versions are affected?
- Is the issue exploitable?
- How severe is it?
- Is there already a related fix or mitigation?
- What change is required?
- Can the fix be released safely?
This work can take time. Some vulnerabilities may be simple to fix. Others may be deep inside an operating system, browser engine, protocol implementation, library, or legacy component. In those cases, fixing the vulnerability is not just a matter of writing code. It also requires testing, compatibility checks, release planning, and communication.
A patch may not be available immediately
The ideal outcome is a patch. But not every vulnerability gets a clean patch quickly.
Sometimes the affected software is old. Sometimes the vulnerable component is embedded in other systems. Sometimes the fix may affect stability or compatibility. Sometimes the software is open source and maintained by a small group. Sometimes the OEM may need more time to test and release the fix.
In these situations, the software owner may publish a workaround or mitigation before a full patch is available. That could include disabling a feature, changing a configuration, restricting access, blocking a protocol, or applying another compensating control.
For enterprises, this is an important distinction. A vulnerability becoming public does not always mean a patch is ready. Enterprises still need a way to reduce risk while waiting for the permanent fix.
Disclosure starts the clock, in most cases
Once a vulnerability becomes public, the clock starts for enterprises.
Anthropic’s Mythos write-up makes this point clearly in the context of N-day vulnerabilities. It says Mythos was able to write exploits autonomously starting from public information such as a CVE identifier and a git commit hash. Anthropic says work that historically took skilled researchers days to weeks can now happen much faster, cheaper, and without intervention.
This means public disclosure can quickly become public exploitability.
At the same time, non-disclosure should not be confused with safety. If a vulnerability is not yet public, it only means enterprises do not have visibility into it. It does not guarantee that no adversary has independently found the same weakness. In some cases, attackers may already know about the vulnerability, may be developing an exploit, or may even be using it before the broader ecosystem becomes aware.
This also does not mean every vulnerability will be exploited immediately. But it does mean enterprises should expect the time between discovery, disclosure, and exploitation to keep shrinking. Slow patch cycles become riskier in this environment.
The role of security research is to identify and validate weaknesses. The role of the software owner is to turn that finding into a patch, workaround, advisory, or mitigation path. AI can accelerate discovery and may also help with triage, reproduction, and patch suggestions. But enterprises still depend on the software owner to publish usable guidance.
What this means for enterprises
AI can find vulnerabilities faster, but those vulnerabilities still have to move through the software ecosystem before most enterprises can act on them directly. That ecosystem includes AI labs, security researchers, OEMs, open-source maintainers, vulnerability databases, security vendors, and enterprise security teams.
For enterprises, the disclosure window is not a passive waiting period. Even when a specific vulnerability is not yet visible, enterprises can improve readiness by knowing their assets, understanding what software is running and where, reducing internet exposure, enforcing secure configurations, and limiting unnecessary access.
Detection and response also matter in this period. EDR and XDR tools may not know the specific zero-day before it is public, but they can still help detect suspicious behavior if exploitation begins. This complements prevention.
Once a vulnerability becomes public, patched, or otherwise actionable, the enterprise challenge begins. Enterprises have to determine whether they are affected, decide what action is needed, and verify that risk has been reduced.
Discovery is important. But discovery is not the end of the process. For enterprises, it is the start of the operational work.