Anthropic’s April announcement was easy to miss.
A short disclosure that their latest model had identified thousands of previously unknown vulnerabilities across major operating systems and browsers.
What mattered wasn’t the volume, but what the model did next.
Access was restricted and shared with a small group of technology providers to fix issues before they could be exploited. Project Glasswing handed early availability to a named group of launch partners, with access extended to more than forty additional organisations responsible for critical software. The logic was to give defenders first use before the capability reaches people with less constructive intentions. Anthropic committed $100 million in usage credits to support the effort.
What actually changed
The more significant shift is that the model didn’t stop at identification. It was able to develop working exploits and in some cases, chain them together into viable attack paths.
Finding vulnerabilities has always been the easier part of security. Turning them into something usable, reliably and at scale, has traditionally required time, skill and iteration. That constraint is now starting to disappear.
This is where the impact moves beyond efficiency and into capability. It lowers the barrier for less experienced attackers and increases the speed at which more capable ones can operate. Instead of probing for a single weakness, the focus shifts to building attack paths across systems, combining smaller issues into something materially more serious.
That is a different category of risk.
Worth being sceptical about, but not dismissible
The AI industry has a well-documented habit of announcing transformative capabilities that turn out, on closer inspection, to be incremental ones dressed up in ambitious language.
That scepticism is reasonable. Some researchers have reportedly replicated aspects of the identified vulnerabilities using older, cheaper, publicly available models, suggesting the capability gap may be narrower than headlines imply.
However, the specific claims matter less than what this demonstrates is now achievable at scale. Once a capability is shown at scale, replication follows by competitors, researchers and eventually by less constrained actors. The gap between “a leading lab can do this” and “others can do this” is usually short and shrinking. Security programmes built for today’s threat pace will not hold up against what follows.
The problem no one wants to say out loud
Most security teams are already underwater.
Not because they are not good at their jobs but because finding vulnerabilities has always been easier than fixing them. Remediation is slow and it requires coordination across teams with other priorities, change management processes that exist for legitimate reasons and a tolerance for operational disruption that organisations tend to have in limited supply.
More findings without higher throughput do not improve security. They deepen the backlog, exhaust the team triaging it and leave exposure largely unchanged.
One example cited was a remote code execution flaw in FreeBSD that had gone undetected for 17 years. It was not unfindable. It had simply not been looked for with this level of consistency. Mythos found it and built a working exploit without human involvement after the initial prompt.
It also reinforces a broader trend. Capabilities that once required deep technical expertise are becoming more accessible. As that continues, the gap between low-skill and high-skill attackers starts to narrow, particularly when tools can assist with both discovery and exploitation.
That shifts the risk. It’s no longer just about discovery, it’s about how quickly those vulnerabilities can be turned into something usable, and whether remediation can keep up with that pace.
AI already lives in your environment
Separate from Mythos as an external threat, there is a more immediate and less discussed problem: the AI systems organisations have already deployed, often with limited security oversight, are themselves an expanding attack surface.
AI systems connected to privileged data without proper access controls expose sensitive information through routes that traditional security tooling was not built to detect. Agents granted broad operational permissions, able to call APIs, trigger workflows and interact with downstream systems, create privilege escalation paths that were never part of any threat model. Indirect prompt injection, where an attacker poisons a data source the AI consumes rather than attacking the model directly, has moved from theoretical concern to practical technique.
The underlying cause is usually the same: nobody drew a clear line between what the system should treat as instruction, what it should treat as data and what it should treat as potentially hostile. When that distinction is not enforced architecturally, the exposure is structural.
An AI assistant producing unreliable output is an annoyance. An AI agent that can send requests, execute tasks and modify records is a different category of risk. As organisations move from one to the other, the attack surface grows with the autonomy granted. That requires deliberate design decisions from the outset, not fixes added once the system is already running
The practical response
The unavoidable truth is that if vulnerabilities can be found and have exploits designed for them by attackers more quickly, then patch management needs to speed up as well. Prioritisation needs to work as a real operational discipline.
The question is not just “how severe is this finding?” It is “if this gets exploited in our environment, what breaks, how badly and for how long?” That means understanding reachable attack paths, privilege outcomes and blast radius, not just CVSS scores. Define who makes those calls, how often and what the criteria are for deferral.
Internet-facing services and identity infrastructure are where it matters most. Fix those boundaries first and include the supply chain dependencies sitting adjacent to them: VPN components, gateway services and third-party libraries handling authentication. Widely reused open-source components are particularly exposed. A single vulnerability in a ubiquitous library is more valuable to an attacker than a bespoke flaw in a proprietary system.
Remediation needs to be treated like a pipeline
Measure cycle time from finding to fix. Work out where things stall, because it is usually the same two or three bottlenecks.
Separate changes into two tracks: those that are low-risk and well-understood with clean rollback options and those requiring architectural review and proper change windows. This prevents complex work from blocking straightforward fixes.
If discovery accelerates and throughput does not follow, exposure grows regardless of how strong detection capabilities are.
This also requires an honest conversation upward. Faster remediation means more frequent operational disruption and that is a resource and tolerance decision that security teams cannot resolve alone.
AI systems need trust boundaries built in from the start
Treat external inputs as untrusted until proven otherwise. Separate the paths through which instructions flow from the paths through which data flows and enforce that technically rather than through process alone. Apply least privilege to anything agentic: narrow scopes, explicit allow-lists and defined escalation paths for sensitive actions.
Assume model behaviour will be interfered with, because at scale it will be. Monitoring for anomalies, rollback capability and clear accountability for agent actions are not refinements for later, they are the baseline.
Know where AI already sits in your environment
Build a clear inventory of where AI is already in use across your organisation, including embedded features in tools and platforms, the data that flows through them and the third-party services involved.
This is about more than visibility. Without a clear view of where AI is operating and what it can access, it is difficult to assess exposure or contain failures effectively.
Apply the same level of scrutiny to suppliers. As AI becomes embedded in development and testing pipelines, it can change the exposure profile of everything downstream, introducing risks that may not be immediately visible within your own environment.
Also be explicit about expectations. Require software bills of materials for critical suppliers so dependencies are understood and set clear contractual obligations for response times when components are compromised.
Talking to the board
Mythos has cut through in a way security issues rarely do. It’s in the headlines, being discussed by finance ministers and has drawn comment from the Bank of England. That’s a very different backdrop from the usual internal struggle to justify security investment and it’s likely that it won’t last.
Security leaders should use it.
The conversation that lands with executives isn’t technical, it’s operational. Strip it back to a few direct questions:
- What actually breaks if this capability is used against us?
- Given how we’re set up today, how would that realistically happen?
- What are we doing about it and how would we know it’s working?
The harder part is pace. Most organisations are not short on findings, they are short on the ability to fix things quickly. Speeding that up means accepting more change. More updates, more testing, sometimes more disruption.
That is a business decision, not a security one.
Mythos helps because it gives that discussion some external weight. It is not about hype or worst-case scenarios. It is about using the moment to reset expectations on how quickly the organisation is willing to move while people are paying attention.
The longer view
The capability that makes Mythos a potential offensive tool also makes it a powerful instrument for finding and fixing vulnerabilities that have accumulated in internet infrastructure over decades. Both things are true and the outcome depends largely on which side moves faster.
The organisations that come through this period in better shape will not necessarily be the ones that reacted most urgently to Mythos specifically. They will be the ones that treated it as a prompt to ask whether their fundamentals, visibility, prioritisation, remediation throughput and containment design, can operate at the pace the next few years will demand.
The fundamentals haven’t changed. Software still breaks. What has changed is how quickly weaknesses can be found, exploited and combined and most organisations are not set up to operate at that speed.
References
- https://red.anthropic.com/2026/mythos-preview/
- https://www.anthropic.com/glasswing
- https://www.forbes.com/sites/amirhusain/2026/04/01/ai-just-hacked-one-of-the-worlds-most-secure-operating-systems/
- https://www.bbc.co.uk/news/articles/c2ev24yx4rmo