Frontier AI Makes Exploits Easier and IT Harder to Defend

The most dangerous gap in enterprise IT and cybersecurity is becoming the time between knowing something is wrong and getting it fixed. Frontier AI is putting that gap under extraordinary pressure. It is making deeply buried software flaws easier to discover and, increasingly, easier to turn into working exploits. Anthropic’s analysis of GLM-5.3 advanced cyber capabilities, published more than three weeks ago, reached capability findings that broadly match NIST CAISI’s independent assessment of the same model. It should have set off alarm bells: building working exploits is no longer hard.

At the same time, Frontier AI is opening a path to something our industry has struggled to achieve at scale: mathematical guarantees about how critical software behaves.

I believe this puts cybersecurity and enterprise IT at a turning point. We must respond to the weaknesses being exposed today while changing how we design, build, test and operate the systems we will depend on tomorrow.

The exploitation ladder

Consider the PHP advisory issued on October 21 that noted that two critical vulnerabilities could allow unauthenticated remote code execution. For Apache with mod_php, the PHP team described a demonstrated attack that could trigger before any application code ran. Your application could be carefully written and still inherit a critical weakness from the runtime beneath it. [1] [2]

Earlier this year, Mozilla reported fixing 271 security bugs identified with Claude Mythos Preview in Firefox 150. Some of the flaws described in its research had survived for 15 or 20 years. Mozilla also explained that several sandbox escape findings required another exploit to form a complete compromise. That distinction matters: a vulnerability, a working exploit and a compromised system are different things. [3]

We should be careful about treating every disclosure as proof that software suddenly became less secure. Some of what we are seeing is frontier AI models dramatically improving our ability to find weaknesses that were already there. The immediate consequence, however, is real: organizations have more urgent work arriving against infrastructure they cannot simply stop using.

This is where the exploitation ladder becomes important.

“Exploitation is not a binary event. It is a ladder of acquiring progressive capabilities, from executing a single buggy line of code to taking full control of the target.”

That line comes from the ExploitBench researchers, who break the progression into rungs: reach vulnerable code, trigger the bug, develop limited capabilities inside a sandbox, cross that boundary, and gain control of execution. These are distinct technical achievements. In this benchmark, full control refers to the V8 process, not automatic control of an entire device or enterprise.

Historically, the difficulty of moving between those steps provided some protection. Finding a crash did not mean an attacker could reliably turn it into useful control. AI is reducing that barrier. In Anthropic’s reported evaluation, Mythos Preview achieved arbitrary code execution on 21 of 41 patched V8 vulnerability cases across two harness variants. Those were controlled tests with supplied vulnerability information, not 21 live breaches. But they illustrate why defenders must take the progression seriously. [4]

My concern is that enterprises still organize their response around individual findings while attackers benefit from connections between weaknesses.

A vulnerable business service, an overprivileged identity and an overlooked dependency can sit in three different teams’ queues. Together, they may create a route to a critical business system. The organization has to understand that route and interrupt it. Counting alerts tells us very little about whether that happened.

Why IT and security are one operational responsibility

Security identifies exposure and sets the controls. IT operates the devices, applications, identities, business services and infrastructure where those controls must take effect. The work crosses both teams, regardless of where the reporting lines sit.

When a critical advisory lands, someone has to establish where the affected component runs, whether it is reachable, what it can access, who owns it and what would break if it changed. Then comes containment, testing, deployment and verification. Each unanswered question adds time. Each handoff gives the exposure longer to remain useful to an attacker.

A patch being available does not mean it is deployed. A deployment completing does not prove that every affected instance is protected. And if an attacker has already gained access, patching the original flaw alone may leave that access intact.

The metric I want CIOs and CISOs to share is time to verified risk reduction: how long it takes to confirm that a relevant attack path has been blocked or removed, with evidence of what remains exposed. That creates a common outcome for detection, incident response and IT operations.

Jason Clinton, Anthropic’s deputy CISO, put it bluntly: things are going to get a lot worse before they get better.

There is also a more hopeful development. Logan Graham, who heads Anthropic’s Frontier Red Team, describes two ambitions: fix the bugs we have, then rebuild software foundations so those bugs cannot arise in the first place. [5]

Anthropic’s work with Theorem points toward the second ambition. They report proving security properties at the RISC-V assembly level across 123 open-source libraries.

Formal verification establishes that specified properties hold under explicit assumptions. LLMs can help produce the proofs, while formal verification tools check their validity. This can reduce the specialist effort that has historically constrained adoption. It does not certify that an entire application is free of every possible bug, configuration mistake or security failure. The specification and assumptions still determine what the guarantee means. [6]

The strategic opportunity is substantial. A security property established in a widely reused foundational component can benefit many downstream systems, provided their use matches the verified conditions. We should be asking which shared foundations deserve that investment first, and funding the maintainers who must integrate and sustain the work.

That creates two connected priorities for enterprise leaders. Reduce today’s exposure faster. Reduce tomorrow’s supply of exploitable weaknesses by improving the foundations. Neither priority replaces the other: stronger code still must be deployed correctly, and faster operations still depend on the quality of the software they operate.

This is where I see a meaningful role for Atomicwork AI Coworkers in enterprise IT and security operations.

How Atomicwork's AI Coworkers can solve for this

Go back to the PHP advisory. For most enterprises, the hard part was not learning that a fix existed. It was answering what came next: which servers run an affected version, which business services depend on them, who owns each one and when it can safely change.

This is the kind of work AI Coworkers can carry. With the CMDB as context, an advisory becomes a map: the devices, applications and business services it touches, and the people accountable for each. From there, the work moves between specialists. An Incident Ops Engineer triages and coordinates the response, a SecOps Engineer escalates with the evidence attached, and the remediation goes through change risk assessment and approval. The full history travels with every handoff, so no one, human or AI, starts from a blank ticket.

Because every step, from identifying exposure to confirming the fix is running, is recorded against the same piece of work, CIOs and CISOs get one timeline to measure time to verified risk reduction instead of a stack of separate queues.

These systems will themselves become privileged parts of the enterprise. Their identities, credentials and execution environments need the same discipline we expect them to enforce. Adding autonomous capacity without controlling its reach would create another problem for the security team.

We designed our AI Coworkers with that in mind. Each one has its own identity, scoped access to every tool and a human manager it reports to. Tools are set to Allow, Ask or Deny, so routine work runs immediately while risky changes wait for a person. Rules enforced in code block sensitive actions no matter what the model decides, and every action is logged.

At Atomicwork, this is the direction I believe enterprise IT and security operations must take: AI Coworkers doing the continuous operational work, governed by the teams accountable for the business.

The opportunity is bigger than adding another tool. It is to make the enterprise consistently capable of acting on what it knows, while making the software beneath it harder to exploit. The exploitation ladder is getting easier to climb. Our job is to remove its rungs and close the exposure before someone reaches the top.

See how Atomicwork AI Coworkers take on IT and security operations work: explore the AI Workforce.