The cybersecurity landscape has fundamentally changed.
That’s not hyperbole. It’s not vendor theater. And it’s not another prediction that AI-powered cybersecurity will transform security someday.
It has already happened.
Anthropic’s launch of Glasswing is the clearest signal yet that frontier AI models can now perform vulnerability discovery and exploitation tasks that were previously limited to elite human researchers. Project Glasswing gives selected defenders access to Claude Mythos Preview, Anthropic’s frontier model, to help secure critical software before similar capabilities become broadly available. Anthropic describes the effort as an initiative to secure the world’s most critical software with early access to frontier AI, supported by launch partners including AWS, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorganChase, the Linux Foundation, Microsoft, NVIDIA, and Palo Alto Networks.
That’s the headline. But it’s not the real story.
The real story is that the cost of vulnerability discovery is collapsing.
For enterprises, this changes the risk equation. The question is no longer whether AI can find software weaknesses. It can. The question is whether your organization can remediate, validate, deploy, and contain at the same speed AI can discover.
Few enterprise remediation programs were designed for that tempo.
That gap is where the next generation of cyber risk will emerge.
What Glasswing is, and what it isn’t
Let’s be precise.
The Anthropic Glasswing initiative is a defensive cybersecurity initiative designed to give trusted technology providers, open-source maintainers, and security leaders a head start. Anthropic says it has extended access to additional organizations that build or maintain critical software infrastructure, alongside its launch partners. It has also committed $100 million in model usage credits to cover Project Glasswing and additional participants throughout the research preview.
That investment matters. It signals that frontier AI security is not a lab curiosity. It’s an ecosystem-level issue.
But Glasswing should not be misunderstood.
It is not a public release of the Claude Mythos AI model. Anthropic’s red team has said Mythos Preview will not be made generally available today, even as the company works toward safe deployment of Mythos-class models in the future.
It is not a bug bounty replacement. Human researchers, maintainers, security engineers, and product teams still matter. In fact, they matter more, because AI can create more findings than the current remediation system can absorb.
It is not a surveillance mechanism. The relevant capability is code-level analysis: finding structural weaknesses, exploit paths, and vulnerability chains.
This distinction is important. Glasswing is not about replacing defenders. It is about preparing defenders for an environment where attackers may soon have access to similar capabilities.
Why this changes the balance between attackers and defenders
Anthropic’s technical writeup on Mythos Preview should be required reading for CIOs, CTOs, and CISOs.
During testing, Anthropic found that Mythos Preview could identify and exploit zero-day vulnerabilities across major operating systems and web browsers when directed to do so. The company also reported that many of the vulnerabilities were subtle, difficult to detect, and in some cases decades old.
The model didn’t just find simple bugs. Anthropic reported examples involving exploit development, vulnerability chaining, and complex analysis across real open-source codebases. It also described a significant step-change in exploit-development performance compared with earlier models.
That should make every security leader uncomfortable.
Because modern enterprise security already struggles with scale. Organizations are buried under CVEs, alerts, dependency updates, cloud misconfigurations, identity exceptions, outdated libraries, unpatched appliances, and third-party risk questionnaires. The current model depends heavily on prioritization: What’s critical? What’s exploitable? What’s exposed? What’s actively being attacked? What can we fix this week?
AI changes the tempo of every one of those questions.
A human-led vulnerability program assumes discovery is scarce and remediation can be scheduled. An AI-led threat environment assumes discovery is abundant and remediation becomes the constraint.
That is the strategic shift.
The Cybersecurity Singularity is the point where human-speed defense breaks
This is why I use the term Cybersecurity Singularity.
The Cybersecurity Singularity is the point at which AI-accelerated offensive capability overwhelms human-speed defensive operations.
That doesn’t mean every attacker will instantly become elite. They won’t. It means the economics of attack improve dramatically. AI can help adversaries search larger codebases, generate exploit hypotheses, chain vulnerabilities, create phishing content, impersonate trusted identities, and automate reconnaissance. Attackers don’t need perfection. They need speed, volume, and enough successful paths to create leverage.
Defenders operate under a different burden. They need accuracy. They need uptime. They need legal defensibility. They need change windows. They need business alignment. They need vendor coordination. They need evidence. They need governance.
That asymmetry is where risk compounds.
Anthropic has said fewer than 1% of the potential vulnerabilities it identified had been patched by maintainers at the time of publication, which limited what it could responsibly disclose.
That one detail captures the problem better than any abstract warning could.
Finding vulnerabilities is getting faster.
Fixing them is not.
CVSS alone is not enough for AI-speed prioritization
In an AI-speed environment, vulnerability prioritization has to evolve.
Many organizations still rely too heavily on CVSS scores. CVSS is useful for severity, but severity is not the same as likelihood of exploitation, business exposure, compensating controls, asset criticality, or blast radius. A vulnerability that is “critical” on paper may be less urgent than a lower-scored vulnerability that is internet-facing, easy to exploit, actively discussed, and present in a revenue-critical system.
CISA’s Known Exploited Vulnerabilities catalog already reflects this reality by focusing on vulnerabilities with evidence of active exploitation. CISA strongly encourages organizations to prioritize KEV-listed vulnerabilities as part of vulnerability management.
The Exploit Prediction Scoring System, or EPSS, also points in the right direction. FIRST describes EPSS as a daily estimate of the probability that exploitation activity will be observed for a vulnerability over the next 30 days.
But even KEV and EPSS are not enough on their own.
A Mythos-class model can change exploitability assumptions quickly. It can turn obscure technical friction into mechanical work. It can chain weaknesses across code, configuration, identity, and architecture. It can revisit old software that security teams assumed was too obscure or too hard to exploit.
So, enterprises need a richer prioritization model:
- Known exploitation: Is it in KEV or being exploited in the wild?
- Predicted exploitation: What does EPSS indicate?
- Business criticality: Is the affected asset tied to revenue, operations, regulated data, or critical infrastructure?
- Exposure: Is it internet-facing, partner-facing, API-accessible, or reachable from lower-trust zones?
- Exploit chain potential: Can it combine with weak identity, exposed credentials, misconfiguration, or lateral movement paths?
- Patchability: Can it be fixed quickly, or does it require vendor action, code changes, downtime, or regression testing?
- Blast radius: If exploited, how far can the attacker move?
That final question may become the most important one.
Supply chain trust needs to move beyond questionnaires
Project Glasswing also forces a more serious conversation about software supply chain assurance.
Most enterprises run on code they didn’t write. Cloud platforms. Operating systems. Browsers. SaaS applications. Open-source libraries. Commercial software. APIs. Container images. Infrastructure-as-code modules. Build tools. Identity providers. Agents. Plugins. Integrations.
The attack surface is not your enterprise alone. It is your ecosystem.
SBOMs are a necessary foundation for transparency, but they are not sufficient by themselves. CISA describes a Software Bill of Materials as a formal record detailing the components and supply chain relationships used in building software.
An SBOM can tell you what’s inside the software. It doesn’t prove the software has been tested with AI-assisted vulnerability discovery. It doesn’t tell you whether a dependency is reachable in production. It doesn’t tell you whether a vendor can patch within 24 hours, 72 hours, or three months. It doesn’t tell you whether a vulnerability can be chained with your identity architecture.
That is why enterprises need a modern supply chain security assessment.
The assessment should ask harder questions:
- Which critical vendors are using AI-assisted vulnerability discovery?
- Which products have been tested with frontier or frontier-adjacent models?
- How are AI-generated findings validated before they enter the remediation workflow?
- What is the vendor’s mean time to triage, remediate, test, and release?
- Can the vendor provide machine-readable evidence of dependency exposure?
- Does the vendor maintain a current SBOM and VEX-style exploitability context?
- How does the vendor handle coordinated disclosure?
- Which critical components remain unsupported, unmaintained, or opaque?
NIST’s Secure Software Development Framework provides producers and purchasers with a common vocabulary for secure development, reducing vulnerabilities, mitigating the impact of unaddressed vulnerabilities, and improving supplier communication.
That framework now needs to be applied with AI-speed assumptions.
The old vendor question was: “Are you secure?”
The new vendor question is: “Can you prove how quickly you find, fix, and validate exploitable weaknesses?”
AI-speed remediation requires engineering discipline, not just security tooling
The biggest mistake enterprises can make right now is treating cybersecurity automation as a tool purchase.
Automation helps only after ownership, workflow, and evidence are clear. Otherwise, it just accelerates confusion.
AI-speed remediation requires a technical operating model that connects security findings directly into engineering execution. That means security, platform, application, infrastructure, and product teams need one remediation fabric, not five disconnected queues.
At minimum, that fabric should include source-level code analysis, or SAST; runtime and web application testing, or DAST; software composition analysis, or SCA; container image scanning; infrastructure-as-code scanning; secrets detection; API security testing; SBOM generation; automated regression testing; policy-as-code gates; patch validation; rollback automation; change-risk scoring; and evidence capture for audit and board reporting.
The goal is not to block development. The goal is to make secure remediation the path of least resistance.
When a critical vulnerability is discovered, the workflow should already know the owner, affected assets, dependency path, exploitability context, exposure level, business criticality, remediation SLA, exception process, and escalation route.
If that sounds basic, ask how many organizations can do it today across cloud, legacy systems, SaaS, custom applications, third-party platforms, and open-source dependencies.
Very few can.
That’s why the bottleneck is no longer finding bugs. It’s fixing them without breaking the business.
Zero Trust has to become identity-for-everything
The other major implication is architecture.
NIST defines Zero Trust Architecture as a shift away from static, network-based perimeters toward the protection of users, assets, and resources. NIST also states that zero trust assumes no implicit trust based solely on network location or asset ownership, and that authentication and authorization should occur before access to enterprise resources is established.
That matters because Mythos-class models weaken defenses that depend on friction.
If a control works mainly because exploitation is tedious, repetitive, or requires deep manual skill, AI can reduce that friction. Anthropic’s red-team writeup makes this point directly, noting that mitigations whose value comes primarily from making exploitation tedious may become weaker against model-assisted adversaries.
In that environment, Zero Trust Architecture can’t remain a slideware principle. It has to become the containment architecture.
That means:
- Least privilege by default.
- Just-in-time and just-enough access.
- Strong privileged access management.
- Microsegmentation.
- Workload identity.
- Service-to-service authorization.
- API access governance.
- Device posture checks.
- Continuous verification.
- Egress controls.
- Session monitoring.
- Lateral movement detection.
- Rapid credential revocation.
- Dynamic policy enforcement.
And now, identity must extend beyond humans.
Enterprises are deploying AI agents into software development, IT operations, customer service, finance, HR, cybersecurity, and business workflows. Those agents will read data, call APIs, execute tasks, open tickets, generate code, approve actions, and interact with other systems.
If an agent has access, it has identity risk.
If it has standing permissions, it has blast radius.
If it can act across systems, it can become an attack path.
So, the model must evolve toward identity-for-everything: people, agents, machines, workloads, applications, controls, APIs, and data pathways.
The perimeter will be breached. The question is whether the breach becomes a contained event or an enterprise-wide compromise.
The CyberSolve AI-Speed Cyber Resilience Framework
At CyberSolve and Hexaware, we believe the right response to Glasswing is not panic. It is disciplined readiness.
This is the CyberSolve AI-Speed Cyber Resilience Framework: a practical model for helping enterprises close the gap between AI-speed vulnerability discovery and human-speed remediation.
That readiness needs to be measurable. It must connect security strategy, engineering execution, vendor assurance, identity architecture, and board-level governance.
This is not about buying more disconnected cybersecurity solutions. It is about building the operating capability to detect, prioritize, remediate, contain, and prove resilience at AI speed.
We recommend a five-part model.
1. Supply chain AI-vetting assessment
Start with your most critical software suppliers, platforms, and open-source dependencies.
Identify where your business depends on opaque software, unsupported components, unmanaged dependencies, or vendors with weak remediation practices. Review SBOM maturity, exploitability context, patch velocity, disclosure practices, and evidence of AI-assisted vulnerability discovery.
The goal is not to shame vendors. It is to understand concentration risk before a Mythos-class model exposes it for you.
2. AI-speed remediation enablement
Redesign the remediation workflow before automating it.
Define ownership by system, application, platform, and dependency. Establish SLAs by exploitability, exposure, and business criticality. Integrate findings into engineering systems. Automate testing where possible. Capture evidence as part of the workflow, not after the fact.
Then apply cybersecurity automation to accelerate triage, patch validation, deployment, rollback, and reporting.
3. Zero Trust and identity-for-everything architecture
Accelerate Zero Trust Architecture with a focus on real containment.
Prioritize privileged access, workload identity, service accounts, API keys, OAuth scopes, machine identities, and AI agent permissions. Eliminate standing access wherever possible. Segment critical systems. Monitor lateral movement. Build fast revocation paths.
The goal is not to make compromise impossible. The goal is to make compromise survivable.
4. Blast radius reduction
Map the pathways an attacker could use after initial access.
Which identities can reach critical systems? Which service accounts are overprivileged? Which workloads can talk to each other unnecessarily? Which APIs expose sensitive functions? Which legacy systems can’t enforce modern controls?
Then reduce the blast radius through segmentation, policy enforcement, access redesign, and detection engineering.
5. CTO-CISO accountability model
This may be the most important element.
The CISO can define the risk, but the CTO organization often owns the systems that must be patched, modernized, refactored, or retired. If those two functions are not operating from the same playbook, AI-speed risk gets trapped in human-speed process.
The CIO, CTO, and CISO need shared metrics:
- Mean time to triage.
- Mean time to remediate.
- Patch deployment velocity.
- Critical vulnerability aging.
- Exception aging.
- Percentage of critical assets with known owners.
- Percentage of critical vendors with AI-vetting evidence.
- Identity risk reduction.
- Blast radius reduction.
- Board-ready assurance evidence.
In this model, cybersecurity is not a downstream control function. It is an engineering, architecture, and governance discipline.
Why boards should care now
For boards and audit committees, Glasswing raises the diligence bar.
If AI-assisted tools can identify vulnerabilities that traditional approaches missed for years, “we didn’t know” becomes a weaker defense. The stronger question is whether the organization had a reasonable process to assess critical software, demand vendor assurance, prioritize exploitable vulnerabilities, and remediate at the speed of risk.
This is where cyber resilience becomes more than a technical matter.
It touches cyber insurance. Regulatory exposure. Customer trust. Supplier management. Operational continuity. M&A diligence. Critical infrastructure protection. Reputation.
Boards don’t need to understand every exploit primitive. They do need to ask whether the enterprise can answer five questions:
- What are our most critical software dependencies?
- Which of them have been assessed for AI-discoverable vulnerabilities?
- How fast can we patch critical exposed systems?
- Where can a compromise spread if initial access occurs?
- Who is accountable for fixing the risk?
If those answers are unclear, the enterprise is not ready for the next era of AI-powered cybersecurity.
The Glasswing window will not stay open forever
Anthropic is restricting access to Mythos Preview today. That is the responsible choice.
But model parity is coming.
Other labs, nation-states, open-weight communities, commercial vendors, and criminal ecosystems will continue pushing cyber-capable AI forward. Anthropic’s red team is clear that it does not believe Mythos Preview is where language-model cybersecurity capability will plateau.
This creates a limited window for defenders.
Use it.
Audit your supply chain. Modernize remediation. Tighten identity. Reduce blast radius. Connect the CISO and CTO operating models. Treat transparency as a security feature. Make patch velocity measurable. Challenge vendors to provide “AI-vetted,” “frontier-model-assessed,” or equivalent evidence for critical software.
The old model was to find vulnerabilities, score them, assign them, and hope they were patched before they were exploited.
That model is no longer enough.
The new model is AI-led cybersecurity resilience: the ability to find faster, prioritize smarter, fix sooner, contain better, and prove readiness to the business.
Cybersecurity teams have spent years trying to move left.
Now they also need to move faster.
And in the Mythos era, faster may be the difference between a contained exposure and a systemic event.
