Unveiling the Mythos Behind Runtime Security

What did Anthropic actually announce?

Anthropic introduced Mythos Preview as a frontier model with enough autonomous capability in vulnerability research and exploit development that it chose not to release it broadly. The model can identify severe vulnerabilities, reproduce them and in some cases develop working exploit paths with little to no human steering, which reflects a shift from AI assisting researchers to AI driving the workflow itself.

The details here are very interesting. In one test, Mythos Preview was instructed by a simulated user to try to escape the sandbox and find some way of sending a direct message to the researcher in charge. From within a secure sandbox, it developed a multi-step exploit to gain internet access, emailed the researcher who was in a park, and, this part is without prompting, posted details of its own exploit to public websites to prove its success.

The company reports that Mythos has already identified thousands of high severity issues, including long standing vulnerabilities in widely used systems such as OpenBSD, FFmpeg and the Linux kernel. What makes this significant is not just the number of findings, but the ability to move from analysis to exploitation without the same level of human involvement that has historically been required.

Anthropic’s response to this capability reinforces its impact. Instead of releasing Mythos, the company launched Project Glasswing as a restricted program with access limited to selected partners and maintainers while additional safeguards are developed. This reflects a clear concern that widespread access would accelerate exploit development in ways that the current ecosystem is not prepared to handle. We are woefully unprepared for this power to be out in the wild.

Why does this change the security problem?

Security programs have historically treated vulnerability discovery as the primary challenge, based on the assumption that if enough issues could be identified, prioritized and remediated, risk would decrease over time. That model depends on a gap between discovery and exploitation that gives teams time to act.

What Mythos demonstrates is that this gap is collapsing. When AI can analyze large codebases, surface deep logic flaws and generate exploit paths with minimal human involvement, the time required to move from discovery to exploitation becomes extremely short. The backlog of vulnerabilities does not go away, but it becomes less relevant because attackers can act on it faster than teams can resolve it.

Anthropic’s own guidance to security leaders makes this explicit. They recommend shortening patch cycles, automating incident response, treating every CVE as urgent rather than routine and using AI for defense now instead of waiting for equilibrium. That guidance reflects a reality where existing workflows are already too slow.

The race that matters is no longer about vulnerability discovery. It is the race from identifying a vulnerability to reaching a verified state where it can no longer be exploited in a running system. As that gap shrinks, the ability to manage it through prioritization and remediation alone breaks down.

Why more scanning will not save you

Scanning, testing and pre production validation still reduce exposure, but they do not control what happens once exploitation begins. Increasing scanning coverage and correlating more data produces more findings, and while AI can improve how those findings are generated and prioritized, it does not change the time required to resolve them. As soon as you have to submit a ticket to resolve a deployed vulnerability, you have lost the race.

The standard enterprise security stack reflects the vulnerability discovery model. Scanners feed findings into ticketing systems, which feed patch cycles and remediation workflows. That architecture was designed for a threat model where there was enough time to work through the queue before exploitation occurred. That model no longer exists.

As exploit development becomes faster and more automated, attackers are not limited to a small set of high priority vulnerabilities. Even lower priority issues can be identified, exploited and chained together before they can be remediated. Prioritization helps organize work, but it does not stop runtime execution, block privilege escalation or contain attacker activity once access has been established.

The limitation becomes clear when you look at where attacks actually occur. Vulnerabilities become incidents when they are exploited in running workloads, whether through a reachable weakness, a vulnerable dependency in production or a sequence of actions that lead from initial access to persistence or lateral movement. These transitions happen in runtime, which means controls applied earlier in the lifecycle cannot stop them once execution begins.

Why does runtime security matter more now?

Runtime is where exploitation becomes observable and actionable because it is where code executes and where attacker behavior manifests as process activity, system calls, file changes and network connections. It is also where initial exploitation turns into privilege escalation, persistence or lateral movement, which are the stages that determine whether an incident becomes a breach.

As AI accelerates vulnerability discovery and exploit development, the only control that can operate within that same timeframe is one that exists at runtime. Controls that depend on external analysis or delayed workflows cannot respond quickly enough when exploitation follows discovery almost immediately.

Anthropic’s recommendation to automate response highlights the need to reduce delay, but it does not eliminate it if decisions are still made outside the workload. Runtime control removes that delay by allowing detection, decision making and enforcement to happen at execution, where the attack is actually taking place.

What does deep runtime security need to do?

Addressing this shift requires more than runtime visibility, because observing behavior without acting on it does not prevent exploitation. Effective runtime security must be able to understand workload behavior in context and enforce decisions immediately when that behavior indicates an attack.

This involves analyzing process execution, system level activity, file access patterns and network behavior to determine what is expected and what represents a deviation. It also requires maintaining awareness of how workloads should behave so that drift, unauthorized changes or abnormal activity can be identified as they occur.

Most importantly, runtime security must act at execution. That includes blocking exploit attempts, preventing privilege escalation, stopping unauthorized processes and containing attacker activity before it spreads beyond the initial point of compromise. This level of control becomes critical when attackers can move faster and with less effort.

How do traditional, AI-driven and runtime-first approaches compare?

What should security leaders do next?

Security leaders should assume that AI assisted exploit development is already part of the threat model and evaluate their controls accordingly. The key question is not whether the organization can generate enough findings, but whether it can prevent those findings from turning into active exploits in production. The path to success is not vulnerability management or exposure management alone.

This requires examining whether security controls can operate at runtime and at execution speed, including the ability to block exploit attempts, stop privilege escalation, detect abnormal process behavior and contain attacker movement within live workloads. If those capabilities depend on external analysis or delayed workflows, the gap between detection and action will remain.

As exploit development continues to accelerate, that gap becomes the determining factor in whether an exposure leads to a breach, which makes runtime control a necessary part of an effective security architecture.

How can Aqua help?

Aqua’s approach is built around enforcing security inside running workloads, which is exactly where exploitation occurs and where control is now required. By operating within the workload, Aqua can observe behavior in real time, including process activity, network connections, file changes and privilege usage under actual operating conditions.

This allows Aqua to distinguish between expected application behavior and activity that indicates exploitation, using context that is not available to tools operating outside the workload. Because decisions are made locally, enforcement can occur immediately without relying on external systems or delayed workflows.

As a result, Aqua can block malicious execution, prevent privilege escalation and contain attacker activity before it develops into a broader incident. This shifts the focus from identifying vulnerabilities to controlling whether those vulnerabilities can be exploited, which directly addresses the gap between detection and remediation that becomes more pronounced as AI accelerates exploit development.