AI Worms and the Economics of In-Band Signaling
Tech vendors profit from structurally unpatchable AI, and only strict software liability laws can stop them from externalizing catastrophic security risks.
By Victor Hale
Sparked by Document-borne AI worms can self-propagate through Copilot for Word · discussion

Back in the 1970s, if you blew a 2600 Hz toy whistle from a Cap'n Crunch cereal box into an AT&T payphone, you could hijack the routing hardware and make free long-distance calls. The mechanics of John Draper's famous exploit were embarrassingly simple. AT&T used the exact same audio channel to transmit both the customer's voice and the system's administrative routing instructions. The network listened for a specific pitch to know when a trunk line was free. By blowing the cereal toy, early hackers played that exact frequency into the receiver, forcing the system to hand over control. Engineers call this architecture in-band signaling—a design choice where the data you are sending and the commands controlling that data travel along the same path. It assumes the network can reliably distinguish between a normal user talking and a malicious user whistling.
Today, the tech industry is repeating this exact architectural failure, but dressing it up as artificial intelligence. Security researcher Håkon Måløy recently published a vulnerability disclosure detailing how an AI worm can spread autonomously through Microsoft Word documents. If a user simply opens a poisoned document, the embedded text secretly instructs the AI assistant to exfiltrate personal data and infect other files on the network. Parallel research has demonstrated similar capabilities with the Morris II malware, a tool that steals data by feeding malicious text directly into generative systems. If you read the Hacker News discussion reacting to these disclosures, you will see software engineers parsing this as a deeply sophisticated, futuristic cyber threat that requires cutting-edge defensive algorithms. It isn't.
The vulnerability is a 50-year-old structural ghost. Large language models inherently cannot distinguish between processing text as raw data and executing text as a system instruction. They process everything inside a single context window. When a corporate AI assistant summarizes a Word document or drafts an email reply, it takes the user's prompt and the document's contents and mixes them together into one continuous stream of text. A prompt injection attack—where a hidden string of text commands the AI to ignore its safety filters and forward your inbox to an attacker—is just the modern 2600 Hz toy whistle. The attacker is simply blowing a frequency the model's logic cannot ignore. Because of this in-band signaling flaw, the vulnerability is entirely structural. No amount of secondary filtering or clever system prompting can patch an architecture that fundamentally lacks a hard boundary between data paths and control paths.
If the flaw is mathematically unpatchable, we have to ask why software vendors are aggressively wiring these inherently vulnerable language models into our most privileged corporate workflows. They do it because the financial incentives are too massive to ignore. Selling enterprise access to these models is incredibly lucrative, with products like Microsoft Copilot charging $30 per user per month. Securing an architecture that lazily mixes data and control paths is impossible without fundamentally limiting the AI's access. But limiting access makes the product less appealing and threatens the subscription revenue.
The market resolves this tension through the deliberate externalization of risk. Just as a chemical factory might save money by dumping toxic waste into a nearby river, technology vendors reap the financial rewards of AI lock-in while dumping the entirely predictable risk of this unpatchable flaw onto the customer. The physical dynamic is identical. The factory owners get the profit, and the downstream town gets the poisoned water. So when a document-borne AI worm eventually ravages a corporate network, the software vendor who supplied the vulnerable assistant will not pay for the forensic incident response, the lost intellectual property, or the resulting regulatory fines. The customer will bear the full cost of the compromise.
This market dynamic is functioning exactly as incentivized. AI companies have zero financial reason to stop deploying insecure-by-design systems as long as corporate buyers carry the burden of the fallout. The economic friction is entirely one-sided.
We need to stop pretending that smarter algorithms will solve a basic economic failure. We need to stop waiting for software vendors to voluntarily secure their products when insecurity remains highly profitable. We need to stop treating catastrophic corporate data breaches as uncontrollable acts of nature.
We will not get secure AI systems until government regulation alters the underlying math of the market. We need strict software liability laws. If an AI vendor builds a system that can be hijacked by a malicious string of text, they must be legally and financially liable for the damage it causes. Otherwise, they will continue to privatize the profits while socializing the risks.