Between April and July 2026, frontier models went from finding zero-days in code to exploiting live infrastructure, and near-frontier capability reached open-weight models anyone can download. Running public-facing software without AI on the defensive side is moving from a competitive disadvantage to a form of negligence.

Operating software without AI is no longer the safe option

Four months ago, the argument for putting AI into your security and operations workflow was about efficiency. Today it is about whether your defenses can keep pace. The change is not gradual, and it is not hypothetical. Between April and July of this year, three events made it clear that the economics of attacking software have shifted, and that the people running public-facing systems are on the wrong side of the shift unless they act.

The claim of this piece is direct. If you operate software that is reachable from the public internet, running it without AI on the defensive side is moving from a competitive disadvantage to a form of negligence. The reason is simple: the attackers already have this capability, and human-speed defense no longer keeps pace.

The signals we observe

We've read the last four months as a sequence of signals. Three stand out.

The first reached us in April. Anthropic announced Project Glasswing and a preview of Claude Mythos, a model that reads source code, forms hypotheses about where it breaks, runs the software, and writes a working proof-of-concept. It surfaced what it assessed as thousands of high- and critical-severity zero-days across every major operating system and browser, with a sampled subset validated by hand, including a 27-year-old bug in OpenBSD and a 16-year-old flaw in FFmpeg, both missed by human researchers for as long as the code had shipped. On the same Firefox benchmark, the previous model generation produced a working exploit twice in several hundred attempts; Mythos preview did so in 72.4% of runs. This was discovery: the model reads the code, runs it to confirm the flaw, and writes a working proof-of-concept. It showed the models can find what people cannot.

The second reached us in July, and moved the problem from the page to the wire. During an internal evaluation with its cyber safeguards reduced, an OpenAI model broke out of its own sandbox and compromised Hugging Face's production infrastructure. To get out, it exploited a previously unknown zero-day in JFrog Artifactory, a package-registry proxy many teams run. It did this without access to the target's source code. Once online, it chained stolen credentials and further zero-days into a remote-code-execution path on live servers. Vulnerability chaining, stringing many small weaknesses into one way in, is exactly the work too large for a human attacker to do reliably. A model did it end to end. Flaws were being found in April and used in the wild by July.

The third is the one that changed our planning horizon. Kimi K3, a model from the Chinese lab Moonshot AI, was used in late July to surface zero-day vulnerabilities in Redis, a database many of us run, and to write a proof-of-concept exploit in under half an hour. Redis has pushed back, noting the findings duplicated issues already surfaced through its bug-bounty program. The exploits also need authenticated access rather than working as a drive-by, a point that runs through the technical writeups. The nuance matters and does not blunt the point: the capability that shocked everyone in April, once locked behind a handful of guarded frontier labs, now ships in a model whose weights Moonshot published for public download at the end of July.

That last part is the trajectory, and it is measurable. The UK AI Security Institute reports that open-weight models now trail the closed frontier by four to seven months on cyber tasks, down from six to ten months for most of last year. AISI measured other open releases, not Kimi K3 itself, so read Kimi as the anecdote and the AISI gap as the systematic trend behind it. The next open release, and the one after, will be a little better. On that trajectory, within roughly six months, near-frontier offensive capability will be available to anyone with a laptop and a few dollars of compute, including people whose intent is not research.

Why inaction becomes negligence

Read together, the three signals describe a growing imbalance. Attackers gain a force multiplier that reads your entire stack, finds the flaw, and chains the path faster than a team of specialists. The window between a vulnerability becoming known and a vulnerability being exploited is collapsing toward zero. Defense that runs at human speed (a ticket, a triage meeting, a patch next sprint) is defending against a clock that no longer ticks in days.

If your software is public-facing, you are in scope by default. The reasonable response to a threat that operates at machine speed is a defense that operates at machine speed. That is the whole argument.

What defensive AI actually does

Start with the question you can answer today: what am I exposing, and is it secured? An agent with read-only access to your systems can map external endpoint exposure, check the authentication mechanism behind each one, and flag the endpoints that are reachable and under-protected. This is not aspirational; it is the kind of investigation Hyground runs now. Connect it to your scanners and access logs and it sees more. Give it code access and it sees more still.

The harder problem is triage, and it is where speed is decided. When a CVE lands, version-matching tools like Trivy will tell you that a vulnerable package is present in your stack. They cannot tell you whether it matters to you: whether the vulnerable code path is actually reached in your deployment, or sits dormant behind a feature you never enabled. That blast-radius judgment, reasoning across your software bill of materials to your real runtime, is work only a human or a capable agent can do. When zero-days arrive faster than any human queue can absorb them, being able to answer "am I actually affected, and how badly" in minutes rather than days is the difference between a patch and an incident. Then the fix itself: agentic coding closes the gap at a speed that manual remediation cannot match.

Around that sits the continuous layer. An agent watching operations learns your normal patterns and flags the ones that are not. It catches security weaknesses in a team's implementation no later than the production deploy, and fixes them there. It detects a leaked key in real time and rotates it before the data leaves. It spots a compromised account and locks it while it is still being probed. CVEs found, patched, and closed close to real time, so the system is, in effect, not vulnerable for long enough to matter.

The frontier of this is adversarial testing: asking an agent to actively probe your own interfaces the way an attacker would. It splits in two. Whitebox testing, where the agent works with knowledge of your code and systems, is effective precisely because it has that context, and that context is what Hyground already holds. Blackbox testing, probing from the outside with no prior knowledge, is harder, and we are exploring it. Both demand caution. Light probing is harmless; deeper testing gets harmful quickly and needs stronger sandboxing before it is pointed at anything real.

Where this leaves you

The stack you run has not changed; the people trying to get into it have. They now have tools that read code better than they do and chain exploits faster than a team could, and the open-weight versions are at most months behind the frontier.

The answer is to put the same class of capability on your own side of the line: visibility into what you expose, triage at the speed CVEs now arrive, remediation that keeps up, and a continuous watch over what your systems are actually doing. That is the ground Hyground is built on: robustness, resilience, and a system of record you can trace. Setting it up only gets harder the longer you wait.