Two things happened over the last two years, and they pull in the same direction.

First, AI made attacking cheaper. Anthropic’s September 2026 threat report puts it bluntly: “Sophisticated attacks no longer require sophisticated attackers.” Second, AI got good at fixing code. DARPA’s AI Cyber Challenge ended with autonomous systems finding and patching planted bugs in real open-source projects, and Google DeepMind has been sending AI-written security fixes upstream.

Put those together and the conclusion seems obvious: if attackers move at machine speed, defenders should patch at machine speed. Let the AI patch the planet.

I think that conclusion is half right. The speed is real, and we will need it. But the hard part of patching was never writing the fix. It’s knowing the fix is correct, that it was approved by someone accountable, and that rolling it out won’t hurt anyone. That’s a trust problem, and AI doesn’t solve it by being faster.

flowchart TD
    A["AI makes exploits cheap"] --> B["Time from disclosure to exploit shrinks"]
    B --> C["Pressure to let AI patch without waiting for humans"]
    C --> D["New failure modes: bad fixes, one mistake everywhere, poisoned inputs"]
    D --> E["The limit is trust: security, compliance, public safety"]

Exploits Are No Longer a Specialist Skill

For most of security’s history, a working exploit for a hardened target was expensive. It took someone who could read unfamiliar code, understand the bug, and build something reliable enough to use. That expertise was the moat.

AI has been draining it.

The research said it first. In April 2024, researchers showed that an LLM agent could exploit 87% of a set of 15 real one-day vulnerabilities when given the CVE description. Without the description, it managed 7%. That gap matters: AI was strongest at turning a published vulnerability into a working attack, which is exactly the window between a patch and its rollout.

Then it showed up in the wild. In November 2025, Anthropic reported the first reported AI-orchestrated cyber espionage campaign: a state-sponsored group used Claude Code against roughly thirty targets and succeeded in a small number of them, with the AI carrying out an estimated 80–90% of the campaign. Humans stepped in at perhaps four to six critical decision points.

By 2026 it had stopped being a single case:

The window was already closing. Mandiant’s time-to-exploit data shows the average gap between disclosure and exploitation falling from 63 days in 2018–2019 to 32 days in 2021–2022, then to five days in 2023, once a handful of outliers are left out (with them, the average is 47 days). That was before most of the AI tooling above existed.

What hasn’t changed. It’s worth being precise, because the “AI hacker” story gets oversold:

  • Most AI-generated exploits are unreliable. Getting from “works once in a lab” to “works against a hardened production target” still takes skill.
  • Anthropic’s report notes that none of its operations depended on an entirely new technique, even though one actor’s AI-driven research did turn up previously unknown vulnerabilities. For now, AI mostly scales known attacks.
  • Defenders have the same tools, and they’re using them.

So the right claim isn’t “anyone can hack anything.” It’s this: the number of people who can run a competent, multi-stage attack has grown a lot, and the time defenders get after a patch is published keeps shrinking.

Anansi, the open-source pentesting framework covered here before, draws the line where that evidence points. Its optional AI mode gets a condensed list of the hosts, open ports, services and versions a scan found, and returns a risk summary with the top three fixes for the report. The model never chooses a target, a check or an exploit. Those stay in ordinary modules that the operator configures and runs, under the written-permission rule the tool states up front. That split is the useful one today: AI explains and prioritizes what was found, and everything that touches a target stays predictable and reviewable.

So Defenders Reach for AI Patching

If exploits arrive in days or hours, patching on a monthly cycle with a human writing every fix doesn’t hold up. The pitch for AI patching follows naturally, and the evidence that it can work is real:

  • In August 2025, the finalists in DARPA’s AI Cyber Challenge found 54 unique synthetic vulnerabilities across the final’s 63 challenges and patched 43. Along the way they found 18 real vulnerabilities, which are being disclosed to the projects’ maintainers. Team Atlanta won, and several of the systems were released as open source.
  • Google DeepMind’s CodeMender, announced in October 2025, had already upstreamed 72 security fixes to open-source projects, some of them very large codebases. Every patch was reviewed by a human before it was submitted.

That last detail is the important one. The most credible AI patching work so far keeps a human between the AI and the merge button. The question this post is really about is what happens when we remove that human, and where we shouldn’t.

What Can Go Wrong When AI Patches on Its Own

A fix that breaks something else

A patch is a change to production behaviour. AI can write a fix that closes the reported bug and quietly breaks an edge case nobody tested, or that “fixes” the symptom while leaving the cause. Humans do this too. The difference is volume: an agent that ships a hundred fixes a day ships a hundred chances to do it.

One mistake, everywhere at once

When thousands of projects use the same few AI systems to fix the same class of bug, they tend to get the same fix. If that fix pattern is wrong, the failure isn’t isolated. It’s correlated across everyone who accepted it.

We already know what a mass update failure looks like without AI. In July 2024, a single faulty CrowdStrike update took down an estimated 8.5 million Windows devices, under one percent of all Windows machines, and still grounded flights and disrupted hospitals. Microsoft’s own explanation for the outsized damage was that the product was used by enterprises running many critical services. Autonomous patching at planetary scale builds exactly that kind of concentration.

Poisoned inputs

A patching agent reads issues, bug reports, comments, dependency code and documentation, and any of those can contain instructions written by an attacker. An agent that can open and merge pull requests is a new target: trick it, and you get your change shipped with the project’s own credentials.

The trust problem predates AI. The xz-utils backdoor (CVE-2024-3094) was a multi-year effort to win a maintainer’s trust and slip malicious code into a widely used library. It was caught because an engineer noticed SSH logins had gotten slower. An AI reviewer optimizing for “does this fix the reported issue” is not obviously better at catching that kind of patience.

Patches as a roadmap for attackers

Every published fix shows where the bug was. AI is very good at reading a diff and working backwards to the vulnerability, which is exactly the one-day exploitation the 2024 research measured. Faster patching helps only if the rollout is faster than the attacker reading the patch. For anything that can’t be updated quickly, publishing the fix may raise the risk before it lowers it.

Maintainers drowning

Open-source maintainers already carry the cost of AI-generated security noise. curl’s Daniel Stenberg ended the project’s bug bounty in January 2026 to remove the incentive for made-up reports. By October he wrote that the slop had practically disappeared since spring, but that every one of the hundreds of reports received in recent months had AI involved to some extent. The problem is no longer junk. It’s a high volume of good reports. AI-generated patches move that load from triage to review. Someone still has to decide whether to merge.

Compliance: Who Approved This Change?

Most security frameworks assume a person is accountable for each production change. SOC 2 and ISO 27001 change-management controls expect changes to be authorized, tested and traceable, often with separation between whoever writes a change and whoever approves it. An agent that writes, approves and deploys its own fix collapses those roles into one, and an auditor will ask who signed off.

Regulation is also adding time pressure. Since 11 September 2026, the EU Cyber Resilience Act requires manufacturers of products with digital elements to report actively exploited vulnerabilities: an early warning within 24 hours, a notification within 72 hours, and a final report within 14 days of a corrective measure being available. Open-source software stewards take on reporting duties from 11 December 2027, to the extent they’re involved in developing the product.

That creates a real tension. The CRA rewards moving fast on exploited vulnerabilities, which favours automation. Change-management controls reward deliberate, accountable approval, which favours humans. Organizations will have to show both: fast response, and a clear record of who or what made each change and why it was trusted.

Public Safety: Where “Move Fast” Doesn’t Apply

For a website, a bad patch means an outage and a rollback. For industrial control systems, medical devices, vehicles and utilities, a bad patch can hurt people, and many of these systems can’t be patched quickly anyway: they need certification, maintenance windows, or someone physically on site.

This is where the two trends collide hardest. AI makes exploits for these systems cheaper to build, while the systems themselves are the slowest to fix and the least suited to autonomous changes. For this class of system, AI is more useful for finding exposure, prioritizing, and designing compensating controls than for pushing patches.

What Trustworthy AI Patching Looks Like

None of this argues for keeping AI away from patching. The exploit side won’t slow down, so the defence can’t either. It argues for matching autonomy to the damage a change could do:

Change Example How much autonomy
Low risk, easy to undo Dependency bump with a passing test suite AI may merge and deploy, with monitoring and automatic rollback
Medium risk Fix in application logic AI writes the patch and tests; a human approves the merge
High risk Authentication, cryptography, access control AI proposes; a named human reviews in depth
Safety-critical Industrial, medical, vehicle firmware AI assists analysis; humans decide, test and deploy

A few controls make that model hold up:

  • Tests as the gate. An AI patch without a test that reproduces the bug, and proves the fix, shouldn’t merge, whoever wrote it.
  • Provenance. Record which model, which agent and which inputs produced each change, and sign builds so you can prove what shipped. Frameworks like SLSA and tools like Sigstore already exist for this.
  • Staged rollouts with a kill switch. Ship to a small slice first, watch, then widen. That’s the lesson of every mass update failure.
  • Treat agent inputs as untrusted. Issues, comments and dependency content can carry instructions. An agent with merge rights needs the same suspicion as a new contributor.
  • Audit logs an auditor would accept. If you can’t answer “who approved this?” for an AI change, you have a compliance finding waiting to happen.

SecOps Central, a free catalog of hardened cloud machine images, already runs the low-risk row of that table without a person in the loop, and its gates show what that takes. Every image is rebuilt weekly, and no one approves each rebuild, because a weekly rebuild that waits on a person stops happening. The gates are what make that safe:

  • Test the real thing. A smoke test launches the actual image and checks it before anything is published.
  • Scan it, and fail closed. The same run takes a software bill of materials from the running image and scans it. Publishing stops on any critical CVE that has a fix available. A scanner that can’t run, or a vulnerability database more than three days old, counts as a failure, not a pass.
  • Exceptions need a person. Each accepted finding records who approved it and when it expires. When it expires, the gate fails again.
  • Soak before stable. A new image goes public as a candidate at once, so fixes reach anyone who wants them. Launch links move to it only after it has run for 24 hours, or seven days for a new application version, without a critical finding. If the soak fails, the previous stable image stays where it is.

None of these gates cares who wrote the change, so an agent’s patch would pass through them the same way. What the pipeline never automates is the exception: accepting a known risk takes a named person and an expiry date.

Where This Goes

A few things seem likely over the next couple of years:

  • Autonomous patching becomes normal for low-risk changes. Dependency updates and well-tested fixes will be merged by agents by default, the same way automated dependency updates became normal.
  • Provenance becomes a requirement. Customers, auditors and regulators will ask not just “is this patched?” but “who or what patched it, and how was it verified?”
  • Insurers start asking. Cyber insurers already ask about patching practice. Expect questions about AI-made changes and the controls around them.
  • The window keeps shrinking. Attackers get the same improvements defenders do. AI patching doesn’t end the race; it raises the speed at which it’s run.

The goal isn’t to let AI patch the planet unsupervised, or to forbid it. It’s to build the trust infrastructure — tests, provenance, staged rollouts, accountable approval — that lets us hand over more of the work safely, one class of change at a time.