Treat documents as untrusted input

A client sends a proposal. You drop it into an assistant and ask for a summary and a list of the terms that changed. The summary reads well. The list looks right. One figure in it is not the figure in the contract, and nothing on your screen looks wrong, because the document contained a line of text you could not see, addressed to the model rather than to you, and the model treated it as an instruction.

For thirty years a document was something you read. Once a file goes into an AI tool, it is also something the tool reads instructions from, and the tool has no reliable way to tell your instructions apart from the file’s. This guide is about the handling rules that follow from that, for a solo operator or a small team using ordinary tools on ordinary work. It is not a security programme. If you hold regulated data, or you have an admin who owns tenant settings and audit logs, the controls in your admin console matter more than anything here, and this is the wrong document for that job.

A model cannot tell your instruction from the document’s

Everything reaches a language model as one stream of text. Your request, the system prompt behind the product, the file you attached, the web page a research tool fetched: by the time the model sees it, the difference is a matter of formatting and convention, not enforcement. OWASP defines the resulting weakness as a vulnerability that “occurs when user prompts alter the LLM’s behavior or output in unintended ways”, and names the version that matters here as indirect prompt injection, which happens “when an LLM accepts input from external sources, such as websites or files” [1].

The distinction between the two versions is who does the typing. Direct injection is a person trying to talk a chatbot out of its rules, which is mostly the vendor’s problem. Indirect injection is text sitting inside content you supplied, which is entirely yours, because you are the one who decided that file was safe to hand over. NIST’s adversarial machine learning taxonomy places these attacks in the same family as other integrity attacks on deployed systems, and its blunt note on the state of the field is that “many of these mitigations may themselves be vulnerable to new discoveries and evolutions in attacker techniques” [7].

The practical consequence is small and awkward. A document you have not read closely is now closer to a script than to a page. You do not have to believe anyone is targeting you to act on that. You only have to accept that the file is capable of carrying instructions, in the same way an email attachment has been capable of carrying a macro since long before any of this.

Hidden text is the whole trick, and it is not sophisticated

The mechanism that made this concrete in mainstream office software is dull enough to be worth stating plainly. A researcher’s disclosure published on 28 July 2026 describes instructions embedded in a Word file as white text on a white background in a small font, invisible to anyone opening the document normally, and fully legible to Copilot because the tool strips formatting before processing the content [8]. There is no exotic payload. The attack is a sentence, written in a colour you will not notice.

Formatting is not the only place to hide text. Microsoft’s own documentation of its Copilot defenses says the product “helps protect against hidden-instruction attacks by detecting and sanitizing certain Unicode-based obfuscation techniques” in pasted prompts [5]. Read the word “certain” carefully, because it is doing real work in that sentence. Invisible characters, zero-width joiners, text in a footer nobody scrolls to, alt text on an image, a comment thread, a hidden column in a spreadsheet: anything the tool reads and you skim is a place to put a sentence.

Your side of that is cheap. The property the attack depends on works in both directions, so anything readable by the model is readable by you if you strip the presentation. Select everything in the document and set the text colour to black, or paste the contents into a plain text editor. White-on-white text appears. That takes ten seconds and it is the single check with the best ratio of effort to coverage for files from outside.

The output becomes the next input, which is how it spreads

The part of that disclosure worth carrying into every AI tool you use is not the hidden text. It is what happened next. When Copilot drafted a new document using the poisoned one as source material, it copied the hidden instructions into the new file, using the same concealment [8]. The new document looks like your work, sits in your folders, carries your name, and is now a carrier. Feed it to the tool again next quarter and the same instructions run again, without the original sender doing anything at all.

That is the durable lesson, and it survives whatever patch shipped last week. In a workflow where AI output becomes AI input, contamination does not stay where it landed. Your own file store is the transmission medium. An attacker who gets one document into it acts once; the spread afterwards is your normal filing behaviour, which is the same reason document macros were worth worrying about and email forwarding chains leak more than anyone intends.

The disclosure timeline is a useful thing to sit with. The issue went to Microsoft on 6 March 2026, a first mitigation shipped on 3 April, a model upgrade landed on 14 July, and the researcher still reproduced the complete attack chain against every deployed mitigation using a modified payload before publishing on 28 July [8]. The recommendation given to users was not a setting to change. It was “treating externally sourced documents as untrusted when used with Copilot” and “carefully reviewing Copilot-generated or Copilot-edited documents before reusing, sharing, or distributing them” [8].

Vendor defenses are layers, and layers are not a boundary

Every major vendor now publishes a defense stack, and they are worth knowing because they tell you what is and is not being caught. Microsoft describes controls across five stages of the prompt lifecycle, including block lists for known malicious prompts, responsible AI classifiers at both ingress and egress, Unicode sanitization, tool chain analysis that includes “assessing the risk of a prompt injection attack”, and Safe Links on the way out [5]. Google describes a layered strategy for Gemini built from prompt injection content classifiers, security thought reinforcement, markdown sanitization and suspicious URL redaction, a user confirmation step before risky actions, and notifications that tell the user when a defense fired [6].

Anthropic’s developer guidance is the most explicit about the shape of the problem, because it is written for people building on the model. Its advice for indirect injection is to deliver third-party content only inside tool results rather than in system or user text, to state in the system prompt that content returned from tools is untrusted data that must never override the user’s request, to JSON-encode untrusted strings so the boundaries are unambiguous, to apply least privilege to what the model can reach, to screen tool outputs with a small model such as Claude Haiku 4.5 before acting on them, and to red-team your own workflow with documents and emails containing deliberate injection attempts [2].

Notice that all of this is mitigation, and every vendor says so in its own register. OWASP’s assessment is that “given the stochastic influence at the heart of the way models work, it is unclear if there are fool-proof methods of prevention for prompt injection” [1]. Anthropic’s Claude Code security page carries the warning directly: “while these protections significantly reduce risk, no system is completely immune to all attacks” [3]. Microsoft’s page states the division of labour plainly, saying Copilot “is designed to assist users, who remain responsible for reviewing, validating, and acting on generated content” [5]. Read together, those three sentences say the same thing. The last layer of the defense stack is you.

Blast radius is the part you actually control

Since you cannot verify that a document is clean, the useful question is what a poisoned one could do if it got through. The answer depends on what the tool holding it is connected to, and that is a decision you make rather than one the vendor makes for you.

Three properties turn a bad document into a bad outcome: the assistant reads untrusted content, it can reach private data, and it can send or publish something. Break any one of those and the same injected sentence goes nowhere. OWASP lists least privilege access and human approval for high-risk actions among its prevention measures [1]. OpenAI’s safety guidance puts the same rule in one line: “wherever possible, we recommend having a human review outputs before they are used in practice”, and calls this especially critical in high-stakes domains and for code generation [4]. Google’s stack includes a human-in-the-loop confirmation before risky operations for exactly this reason [6].

For a small business, that translates into arrangements rather than settings. Summarise the client’s file in a session that has no access to your mailbox, and draft the reply in a different one. Give connectors read-only scopes when reading is all the job needs. Keep automation platforms such as Zapier, n8n or Make away from steps that both ingest an outside document and send something on your behalf without a person in between. If you use a coding agent, the same logic already exists in its defaults: Claude Code does not auto-approve commands that fetch content from the web such as curl and wget by default, runs web fetches in a separate context window to avoid injecting retrieved content into the main conversation, and advises against piping untrusted content directly into the model [3].

The handling rules worth making automatic

Treat every file from outside your business as untrusted the moment it might touch an AI tool, in the same way you treat an unexpected attachment. That includes vendor proposals, partner spreadsheets, candidate CVs, anything downloaded from a portal, and anything a research tool such as Perplexity or a browsing assistant pulled off a web page on your behalf. The category is not “suspicious files”. It is “files I did not write”.

Keep the original untouched and work on a copy, because you will want something to compare against when a number looks wrong. Do the plain-text check before the first prompt. When the output comes back, verify the figures that matter against the source document rather than against the summary, since an altered number is the quietest possible failure and reads perfectly. And when an AI-drafted file becomes source material for the next piece of work, that is the moment to look at it again, not the moment to trust it because it came out of your own folder.

One more habit is worth the discomfort. If an assistant does something you did not ask for while a document was in context, treat it as a signal rather than a glitch. Anthropic’s guidance to developers is to test workflows with documents containing deliberate injection attempts before deployment [2], which for a non-developer reduces to a smaller version of the same idea: notice the odd output, go back to the file it came from, and read that file properly before it goes anywhere else.

What still goes wrong

The plain-text check catches text hidden by colour and font size. It does not reliably catch instructions in document metadata, in an image the tool can read but a text editor cannot, or written with invisible Unicode characters, which is precisely the technique Microsoft describes sanitizing only “certain” cases of [5]. Checking numbers against the source catches an altered figure and misses an omitted clause, because absence has no signature. Every check here narrows the opening rather than closing it, and the standards bodies say the same about the vendor layers: fool-proof prevention is not currently on offer [1], and mitigations themselves get overtaken [7].

There is also a cost you should see clearly. All of this adds friction to the exact workflow you adopted the tool to speed up, and friction applied evenly is friction wasted. Spend it where the consequence lives. A newsletter draft built from a press release needs almost none of this. A contract redline, a file you will forward to a client, a spreadsheet that feeds your books, and anything an agent will act on rather than show you: those get the full pass, every time, however good the tools have become.

Finally, none of this is a substitute for administration if you are running a real workplace. Microsoft’s guidance for Copilot tenants involves Purview data loss prevention policies, Safe Links, restricted content discovery, and audit logs that flag JailbreakDetected events [5], and Google’s Gemini defenses include user-facing notifications when a mitigation fires [6]. Those are the controls that catch what individual diligence cannot, and they need somebody to own them. If your business has grown to the point where documents from outside flow through AI tools all day and no one person sees them all, procedure has stopped being enough and the next step is configuration, not care.