Ask what happens to your documents, not which model reads them

Version 1.0 · Published 2026-08-03

Every time an AI security incident lands, the same question goes round procurement: which model is it running, and is that model safe? It is the wrong axis. If you are about to connect a document store to an AI platform, the thing that decides your exposure is not the model’s judgment. It is what the pipeline does to your text before any model sees it.

Put concretely, there is one question worth asking your vendor: when you ingest our documents, does that content pass through your system unchanged? Most answers are yes, and yes is the risky one.

A disclosure published at the end of July shows why.

The attack that makes the point

On 28 July, security researcher Håkon Måløy published the third part of his “Context Collapse” series, describing a prompt injection that turns Microsoft Word documents into carriers for their own instructions. Simon Willison wrote it up the following day.

An attacker puts hidden instructions in a document, usually white text on a white background at a tiny font size. Copilot for Word strips color and font size before it processes text, so it reads exactly the part the human cannot see. It may then treat those instructions as part of the user’s request, act on them, and copy them into the document it produces. That output file is now a carrier too, and using it as source material in another workflow can fire the instructions again, with the attacker’s original document nowhere near it.

CSO Online and CyberInsider both covered it, and Malwarebytes described the same self-spreading behavior. This is not one researcher’s edge case. It reproduces.

A better model was never the fix

The disclosure timeline is the part that should interest a buyer. Måløy reported the issue to Microsoft’s Security Response Center on 6 March 2026, and Microsoft confirmed it later that month. In early April it shipped a revised “Edit with Copilot” experience, and the original payload stopped working.

Then he reworded it and it got through. Microsoft opened a second case. On 14 July it upgraded the underlying Copilot for Word model, and by 15 July Måløy had broken that too. iTnews reported that modified payloads kept reproducing the attack class through 28 July, after 144 days of coordinated disclosure.

Credit where it is due: Microsoft responded twice, and quickly, and Måløy withheld the specific payload precisely because no robust mitigation exists. The failure is not sloppiness. It is that patching a payload and upgrading a model are both answers on the model axis, and the vulnerability does not live there. A better model changes what the system is likely to fall for. It does not change whether hidden text in a source document can reach the system’s instructions at all.

Why this is not just a Copilot problem

The reasonable objection is that this is one Microsoft integration, and Microsoft will eventually constrain it. Fair. But look at what the attack actually requires: a pipeline that carries source text forward largely intact, into an output that becomes the next input.

That is not exotic. That is what most document-aware AI does, because preserving your documents is normally the entire point. If a vendor indexes your files and retrieves passages from them, the original text is still the thing moving through the system, and a hidden instruction inside it is still moving too. The integration was specific. The property is general.

Which is why the question is about your documents rather than their model.

How we answer it

At UNLESS, Living Knowledge does not keep your documents as they arrived. Your business is continuously restructured and rewritten into one non-ambiguous Library, and the homepage puts the same thing plainly: what the agent knows is cleaned, rewritten, unambiguous and up to date. What the retrieval index holds is a generated content node, not the file you sent.

So our answer to the question is no, your content does not pass through unchanged, and that is the feature. A hidden instruction survives being copied. It does not survive being rewritten into something else. The propagation step this attack depends on is absent rather than blocked.

The same design gives a second benefit. Because every ingested item has to pass through that rewrite, the rewrite is one place where every item can be examined: for security problems, and for whether it belongs in this particular Content Library at all. One chokepoint is far easier to reason about than a thousand documents flowing straight through.

Around it sit controls we already document. Conflicting claims are surfaced rather than silently merged, so a library that disagrees with itself becomes visible work: the Inbox raises the conflict and it resolves in one click of Accept or Deny. Automated content changes wait for that human decision. Independent content silos mean one customer’s data never reaches another customer’s agent. And the agent takes no irreversible action without a human approving the boundary first.

What we are not claiming

We ingest documents for a living, so we are inside this problem rather than watching it. Nobody honest tells you a threat class is closed, and a vendor who does is telling you about their engineering culture rather than their product.

The claim is narrower and it is architectural. A pipeline that rewrites what it ingests carries a different shape of risk from one that forwards documents. That difference does not come from a better model and it will not arrive in the next one.

The question, once more

When the next disclosure lands, and it will, the useful thing to ask is not which model got fooled.

Ask what your vendor’s pipeline does to your text between the moment it arrives and the moment an agent reads it. Ask whether your documents come out the other side recognizable, and if the answer is yes, ask what stops what is hidden in them coming out recognizable too.

Ask it before you connect the document store, not after.