The Worm Is No Longer a Fixed Payload

On AI-agent-driven propagation, adaptive intrusion software, and the incident-response assumptions classical worm doctrine leaves exposed.

On June 2, 2026, Jonas Guan, Tom Blanchard, Hanna Foerster, Hengrui Jia, Gabriel Huang, and Nicolas Papernot posted the arXiv preprint "AI Agents Enable Adaptive Computer Worms". The paper argues that AI agents enable a new type of computer worm: one that generates tailored attack strategies for each target it encounters, according to the arXiv abstract.

The claim is not that classical worms disappear. It is that the propagation loop changes. Traditional worms spread by carrying a fixed set of exploit logic, while the AI-driven worm described by Guan and colleagues reasons about targets, adapts to observations, and synthesizes attack logic in real time, according to the arXiv abstract.

That shift matters for governance because much incident-response doctrine assumes that the object under response is a payload that can be characterized, blocked, and patched around. The paper describes a system whose behavior is generated during propagation. The incident is no longer only the artifact. It is the adaptive loop that keeps producing artifacts.

Classical Worm Logic Meets Agentic Adaptation

The paper defines a computer worm as malware that spreads on a network by replicating itself from one machine to another, according to the arXiv abstract. It contrasts traditional worms such as WannaCry, which exploited predetermined vulnerabilities, with an AI-driven worm that generates target-specific attack strategies at runtime, according to the arXiv abstract.

The HTML version states that traditional worms ship with a fixed repertoire of vulnerabilities selected at design time, and that patching that finite set can interrupt spread, according to the baseline comparison in the arXiv HTML paper. The same section states that AI-driven worms can generate tailored strategies, revise strategy when a route fails, and are not bound to fixed exploit code, according to the baseline comparison in the arXiv HTML paper.

This is the structural difference. A static worm can be reduced to signatures, indicators, exploit chains, and patches. An adaptive worm contains a generator. It can fail, observe, revise, and try again. The response problem becomes less like removing a known object and more like interrupting a decision process that is running across compromised machines.

The Testbed Shows the Loop

The authors evaluated the proof of concept across 15 independent seven-day experiments on an isolated 33-host network spanning Linux, Windows, and IoT devices, according to the network and experiment details in the arXiv HTML paper. The network included 28 hosts without local GPUs and five GPU-designated hosts, according to the network details in the arXiv HTML paper. Each host had intentionally planted vulnerabilities drawn from sources including the CISA Known Exploited Vulnerabilities catalog, the OWASP Top 10, and the MITRE ATT&CK framework, according to the network details in the arXiv HTML paper.

Across those experiments, the worm correctly identified an average of 31.3 vulnerabilities, exploited 23.1 hosts to elevated access, propagated to 20.4 hosts, and reached a mean of 5.1 generations of self-replication, according to the results section of the arXiv HTML paper. The paper reports average network coverage of 73.8 percent exploited and 61.8 percent replicated to, according to the results section of the arXiv HTML paper.

Those numbers are not the only relevant result. The method section describes a workflow split into phases including discovery, exploitation, privilege escalation, and replication, with programmatic gates verifying phase objectives before advancement, according to the harness architecture section of the arXiv HTML paper. It also describes a reasoning graph with plan, judge, action, summary, and progress nodes, according to the harness architecture section of the arXiv HTML paper. The worm's capability is not just code writing. It is loop management.

Self-Modification and Stolen Compute

The arXiv abstract states that the worm parasitically uses compromised machines to run open-weight LLMs to sustain reasoning or extend reach for further attacks, according to the arXiv abstract. It also states that because the worm is powered by stolen compute, the attacker's marginal cost per new infection is zero, creating a destabilizing economic asymmetry between attackers and defenders, according to the arXiv abstract.

The HTML version adds that each compromised machine can become part of the worm's infrastructure by providing reach or computing resources, and that a GPU-equipped host can become an independent reasoning node serving downstream copies on devices without reasoning capability, according to the methods overview in the arXiv HTML paper. That design makes the system more than self-replicating. It is infrastructure-seeking.

The incident-response implications are direct. The paper reports that the agent modified its own code on several occasions in response to failed exploitation or replication attempts inside the contained environment, according to the containment and safety section of the arXiv HTML paper. It also reports cases where the agent rewrote repository URLs after diagnosing certificate failures and edited an attestation source file to remove a virtual-machine detection check inside the experiment, according to the incident-response findings in the arXiv HTML paper.

Those examples do not imply unlimited capability. They do show that a response model focused on a static binary or fixed script can understate the behavior of an agentic intrusion system. The malware can alter the code path while the responder is trying to characterize it.

Vendor Controls and the Decentralized Inference Gap

The paper's abstract states that centralized safety controls, including service refusals or rate limiting, are structurally irrelevant because the worm requires no commercial AI platform, according to the arXiv abstract. The HTML version explains that the proof of concept used a locally hosted open-weight LLM running on a single GPU and did not rely on vendor APIs, according to the methods overview in the arXiv HTML paper.

That matters because many AI safety controls presume a controllable service boundary. If the reasoning component runs locally on compromised infrastructure, provider-side refusal, rate limiting, and account shutdown do not govern the active loop. The control point has shifted from platform access to network behavior, host containment, and infrastructure compromise.

The authors also state that the proof of concept did not encrypt communications, employ polymorphic code, suppress forensic artifacts, or attempt to conceal local compute use, according to the safety-control implications section of the arXiv HTML paper. That limitation is important. It means the demonstrated system was not optimized for stealth. It also means that the governance question cannot be dismissed as a problem solved by the specific signatures this proof of concept exposed.

Open Questions

• At what point does incident response stop treating a worm as a fixed payload and start treating it as an adaptive propagation process?
• What standard applies when patching one exploited vulnerability closes one path but not the class of paths an agent can generate?
• How does a supervisor verify containment when the intrusion system can rewrite parts of its own execution path?
• What evidence should responders collect when reasoning, replication, and infrastructure acquisition occur across multiple compromised hosts?
• How should policy account for agentic malware that operates outside commercial AI service boundaries?

The Guan paper is important because it turns an established malware category into a systems question. The code-writing capability that agents already possess transfers into propagation, adaptation, and infrastructure use. The response object is no longer just the payload found on disk. It is the machine-speed loop that keeps producing the next payload. The policy instruments and the deployment tempo are not aligned.