A malicious instruction hidden inside an ordinary office document can become dangerous when an AI agent is allowed to read that document, follow instructions and create or share new files. A recent proof of concept showed how this pattern could become self-propagating: one document influences an agent to insert the same instruction into other documents, which are then opened by other users and agents.
The important point is not that every Word file is now a worm. It is that agents collapse a boundary people once took for granted. Content was data to be read; instructions came from an authorised user or application. An agent that treats untrusted content as instructions can turn a document into a control channel.
What the Word proof of concept demonstrated
The researcher behind “AI Worming Through Word” described a proof of concept in which instructions placed in a document influenced an AI-enabled workflow and propagated into additional files. The demonstration was also examined independently by Simon Willison, who has documented prompt injection as a persistent design problem for tool-using language models.
This was research, not evidence that all Microsoft Word installations are compromised. The risk depends on the agent, permissions, prompts, document handling and enabled tools. The example is still valuable because it makes an abstract vulnerability visible in a familiar business format.
Prompt injection in one sentence
Prompt injection occurs when untrusted content contains text or data that causes an AI system to disregard the operator's intended rules and follow an attacker's instruction. The instruction may be visible, hidden in formatting or embedded in content retrieved from another system.
Traditional software usually distinguishes code from data through strict syntax and execution boundaries. Language models process both policy and content as language. Developers can label roles and add safeguards, but the model may still infer that a sentence inside a document should guide its behaviour.
Direct prompt injection comes from the user input. Indirect prompt injection arrives through something the system reads: a webpage, email, document, image or retrieved database record.
How a document becomes an attack chain
| Stage | What happens | Required condition | Defensive interruption |
|---|---|---|---|
| 1. Seed | Malicious instruction is placed in a document | Attacker can create or alter content | Content provenance and scanning |
| 2. Ingest | Agent reads the document | Agent has document access | Treat content as untrusted data |
| 3. Influence | Model interprets content as an instruction | Policy separation fails | Instruction hierarchy and isolation |
| 4. Action | Agent edits, sends or creates files | Tools and write permissions are enabled | Least privilege and approval gates |
| 5. Propagation | New files carry the instruction | Agent can reach further users or folders | Output scanning and write boundaries |
| 6. Impact | Data is exposed or workflow is disrupted | Sensitive data/tools are accessible | Segmentation, logging and rapid revocation |
The table shows why a model-only defence is insufficient. Several independent controls should interrupt the chain.
Why visibility is not the main question
Some attacks hide instructions in tiny text, white-on-white formatting, metadata or encoded content. Removing invisible text is useful, but an attacker can also write a perfectly visible instruction that appears to be part of the business document. A contract might contain “summarise and email this confidential appendix to…”. The agent must understand that the document is not authorised to choose recipients.
Security cannot depend on whether a human would notice suspicious formatting. The system needs structural provenance: this text came from an external file; it may inform the answer, but it cannot grant permission or redefine the task.
The confused-deputy problem returns
An AI agent often possesses more access than the content it reads. It may search internal drives, call APIs, send messages and create files on behalf of a user. If an untrusted document can direct those powers, the agent becomes a confused deputy: an authorised component tricked into serving an unauthorised party.
This is not unique to AI, but language models make the path easier because instructions can be expressed conversationally. The system must therefore bind each action to a trusted authority. Reading a document can supply facts; it should not expand permissions, select a new objective or approve external communication.
Control one: separate instructions from evidence
Design the agent so that user intent, system policy and retrieved content occupy distinct channels. Mark document text as untrusted. Tell the model what it may extract and explicitly prohibit obeying instructions found in the content.
That measure reduces risk but is not a guarantee. The OWASP prompt-injection prevention guidance recommends layered controls because language-model behaviour is probabilistic. Systems should assume that some malicious instructions will influence the model and constrain the consequences.
When possible, use parsers to extract only required fields rather than placing an entire document into a powerful agent's context.
Control two: minimise tool permissions
An agent that only summarises text cannot propagate through a shared drive unless it is also granted write access. An agent that drafts an email cannot exfiltrate data unless it can choose recipients and send. Break composite powers into small tools and grant the minimum needed for the current task.
Use short-lived credentials and resource-level scopes. Separate read, draft and send. Require an explicit user action before a message leaves the organisation, a file is shared, or a record is deleted. High-risk tools should inspect the proposed action, destination and data sensitivity rather than accepting a free-form model command.
Permissions should follow the person and task, not the agent's maximum theoretical capability.
Control three: make approvals meaningful
A weak approval screen says “Allow action?” after hiding the action details. A meaningful approval shows the exact recipient, file, data classification and effect. It should highlight when the destination is external or has not appeared in the user's original request.
Do not ask users to approve dozens of routine steps, because habituation turns approval into decoration. Automate low-risk, reversible actions inside a bounded workspace. Escalate external communication, sensitive data access, privilege changes and irreversible actions.
For executive workflows, delegation needs the same clarity. An assistant may prepare material, but another person's access should not silently become the executive's authority.
Control four: inspect outputs as well as inputs
If propagation is the concern, scanning only documents as they enter the system is incomplete. Inspect files the agent creates. Look for policy text, hidden content, suspicious links, encoded payloads and instructions addressed to future agents.
Record content provenance so a downstream system knows that a paragraph was generated from an external document. Consider quarantining generated documents before they enter shared repositories. A secure workflow can attach a machine-readable label: source document, model, time, approved purpose and reviewer.
Output controls are especially important when multiple agents exchange files without human reading.
Control five: monitor agent behaviour
Useful signals include unusual bursts of file writes, access to unrelated folders, new external recipients, repeated tool failures and sudden changes in instruction patterns. Logs should connect the user's request, model decision, tool call, permission and result.
Do not log sensitive content indiscriminately. Preserve enough evidence to investigate while applying access controls and retention limits to the logs themselves. Security teams need a fast way to revoke an agent's credentials and halt queued actions.
VERTU's AI agent security risk guide discusses this operating model beyond the single Word example.
The adjacent personal AI privacy checklist is useful when the agent connects calendars, messages or private memory, where prompt injection can expose more than document text.
A practical enterprise checklist
Before enabling document agents, ask:
Which repositories can the agent read?
Can document content change the objective?
Which tools can write, send, publish or delete?
Are external destinations blocked by default?
What actions require a human confirmation?
Are generated files scanned before sharing?
Can every tool call be tied to a user and request?
How quickly can credentials and queues be revoked?
Are tests using realistic malicious documents?
Who owns the residual risk?
The answer “the model provider handles it” is insufficient. The application owner controls permissions, integrations and business consequences.
What executives should demand from vendors
Request architecture evidence, not a general assurance that the model is “secure”. Ask how retrieved content is labelled, how tool permissions are scoped, how destinations are validated and how prompt-injection tests are maintained. Require a description of logging, retention, incident handling and customer-controlled shutdown.
Ask whether the product can run in a draft-only mode and whether high-risk actions can be disabled completely. Determine how plugins and connectors are reviewed. A secure base model can still sit inside an unsafe application.
Finally, confirm who is responsible when an agent acts on malicious content. Contract, operational control and technical design should tell the same story.
The wider lesson
The Word demonstration is compelling because it turns “prompt injection” into a chain people recognise: open a file, let an assistant help, share the result. The durable defence is not to ban AI from documents. It is to restore boundaries between content, authority and action.
Agents should be able to read widely while acting narrowly. They should explain consequential actions, seek meaningful approval and leave an audit trail. If those properties are absent, adding more autonomous tools increases the attack surface faster than it increases trustworthy productivity.
