AI worms that self-propagate through Copilot for Word are not science fiction. Here is what the attack surface looks like, why it matters, and how software teams should respond.

Document-Borne AI Worms: The Hidden Risk Inside Copilot for Word

A Word document opens. Copilot summarises it. Without the user clicking anything else, the malicious payload inside that document instructs the AI to rewrite outgoing files, exfiltrate context, and carry itself forward into the next document the assistant touches. That is not a hypothetical attack chain dreamed up in a lab — researchers have now demonstrated it working against Microsoft Copilot for Word.

This class of threat has a name: the AI worm. And it changes the security calculus for every team building on top of, or working alongside, large language model tooling.

What Is an AI Worm, Exactly?

Traditional worms propagate by exploiting vulnerabilities in operating systems or network services. AI worms exploit something far more fundamental: the fact that LLMs treat instructions and data as the same thing.

When Copilot reads a document to summarise or respond to it, it processes the text as a stream of tokens. If that text contains cleverly crafted natural-language instructions — a technique called indirect prompt injection — the model may execute those instructions rather than simply reporting on them. The "vulnerability" is not a bug in the traditional sense. It is an emergent property of how transformers work.

A self-propagating variant goes one step further. The injected instructions tell the model to embed a copy of itself — the malicious prompt — into any new document it helps generate. Each infected output becomes a new vector. The worm does not need a network socket or a CVE number. It travels inside .docx files, email attachments, shared SharePoint documents, and anywhere else Copilot reaches.

Why the Copilot Integration Makes This Worse

Microsoft 365 Copilot is deeply integrated with the user's identity context. It can:

Read and write documents across OneDrive and SharePoint
Draft and send emails via Outlook
Pull data from Teams conversations and meeting transcripts
Access connected line-of-business applications through plugins

That is a broad action surface. A successful AI worm operating inside this context does not need to steal credentials — it is already authenticated as the user. The blast radius scales with the user's permissions. A CFO with broad SharePoint access is a much more dangerous host than a junior analyst.

The Anatomy of a Propagation Chain

Here is a simplified illustration of how the instruction flow works:

[Malicious .docx] 
  └─► Copilot reads document
        └─► Injected prompt hijacks generation context
              └─► Copilot drafts new document
                    └─► New document contains embedded injected prompt
                          └─► Next reader opens file → cycle repeats

Each step looks entirely normal to the end user. The summary looks right. The draft looks professional. The worm is invisible inside the semantic content.

Three Threat Scenarios for SaaS Teams

1. Supply-Chain Document Poisoning

A vendor sends a proposal document. Your team runs it through Copilot to extract key terms and generate a contract draft. If the proposal contained injected instructions, every downstream document generated from that interaction is now a potential carrier.

2. Customer-Facing Workflows

SaaS products that allow document uploads — contracts, onboarding forms, intake questionnaires — and then process those uploads with an LLM are directly exposed. The customer-supplied document becomes an attack vector against your own internal AI pipeline.

3. Internal Knowledge Bases

Teams that feed documentation into RAG (retrieval-augmented generation) pipelines risk poisoning their own vector stores. A single injected chunk retrieved at inference time can alter the model's behaviour for every query that retrieves it.

What Defences Actually Look Like

The honest answer is that there is no perfect mitigation today. LLMs cannot reliably distinguish between "data to process" and "instructions to follow" — that is not a patch away. But there are practical layers of defence:

Principle of least privilege for AI agents. If Copilot or any AI assistant does not need write access to SharePoint, revoke it. Reduce the action surface aggressively.
Human-in-the-loop for write operations. AI-drafted documents should require explicit human review and approval before being saved, shared, or sent, especially in automated pipelines.
Input sanitisation at the application layer. Strip or escape common prompt-injection patterns before feeding user-supplied content to an LLM. This is imperfect but raises the cost of an attack.
Output monitoring. Log and inspect AI-generated outputs for anomalous instruction-like patterns. A document that tells its reader to "ignore previous instructions" is a detectable signal.
Sandboxed LLM contexts. When processing untrusted documents, run the LLM in an isolated context with no access to write operations, external APIs, or other documents.

None of these are silver bullets. Combined, they meaningfully reduce exposure.

The Deeper Engineering Problem

What this research surfaces is a category error that much of the industry is still making: treating LLMs as trusted executors rather than untrusted parsers. When you hand a document to a spreadsheet formula engine, it does not spontaneously decide to email your contacts. When you hand a document to an LLM with agentic capabilities, the boundary between "reading" and "acting" is soft and model-dependent.

Security engineering for AI-augmented applications needs to borrow from web security's hard-won lessons. SQL injection was solved not by training databases to be more discerning, but by separating data from query structure at the architecture level. The AI equivalent — reliably separating content from instructions at the token level — is an unsolved research problem. Until it is solved, architecture and access control are your primary tools.

Source: Context Collapse Part 3: AI Worming Through Word — https://enklypesalt.com/posts/context-collapse-part3-ai-worming-through-word/

Why this matters for your project: If you are building any feature that feeds user-supplied documents into an LLM — for summarisation, extraction, classification, or generation — you are operating on an active attack surface. Audit what actions your AI layer is permitted to take, enforce human approval gates on write operations, and treat every external document as untrusted input. The teams that build this discipline in early will be far better positioned as AI-native workflows become the default, not the exception.