The document your AI trusted more than your instructions

An engineering manager at a legal tech company described a demo that went sideways in a quiet way. Their assistant let a user upload a contract and ask questions about it. During testing, someone dropped in a file with a hidden line near the bottom, written in small text, telling the model to disregard the summary and instead output a link that pointed somewhere else. The assistant printed the link. The rest of the summary looked normal, which is what made it dangerous.

The attack did not come through the chat box. It came through the document. That is the part teams underestimate. You can lock down what a user types and still hand the model a booby-trapped file to read.

Indirect injection hides in the content you ingest

Most teams learn about prompt injection as something a user types. The harder version is indirect. The hostile instruction lives inside content your AI pulls in on its own. An uploaded PDF. A web page the agent fetches. A row in a spreadsheet. A comment field synced from another system. The model reads that content as part of its job, and if the content contains an instruction, the model may follow it.

This matters because the content often comes from outside your control. A customer’s file. A public web page. A record created by a third party. You cannot review every one of them by hand. So the assumption that “our users are trusted” does not save you, because the payload can ride in on data your users did not write.

The result looks like a feature working normally, right up until the one document that carries a command. And because the output can look plausible, the failure is easy to miss. A wrong link, a redacted section quietly summarized in full, a made-up instruction to email someone. All of it wearing the costume of a helpful answer.

Assume ingested content is hostile

The mental model that helps is simple. Anything the model reads that a person outside your team could have shaped is untrusted. Not because you distrust your customers, but because you cannot vouch for every byte that reaches the prompt.

What that looks like in practice:

Fence the ingested content. Pass fetched or uploaded material as labeled data, kept separate from your instructions, so the model knows it is reading a document rather than taking orders.
Reduce before you reason. Where you can, extract just the fields you need from a document rather than dumping the whole thing into the prompt, so there is less room for a hidden payload to hitch a ride.
Limit the blast radius. If the assistant can only answer questions and cannot send data or take actions, an injected command has far less to work with.
Watch the output for surprises. An answer that suddenly contains a link, an address, or an instruction the task never called for is worth flagging.

None of this makes injection impossible. It makes the damage small when it happens, which is the realistic goal. The teams that handle this well stop trying to sanitize their way to perfect trust and instead design so that a trusted-looking instruction inside a document cannot reach anything that matters.

How we approach it at Density Labs

When we scope an AI feature in the AI Opportunity Assessment, we map every source the model ingests, not just the chat input. Uploads, retrieved pages, synced records, anything the feature reads on the user’s behalf. For each one we ask what a hostile instruction hidden inside it could reach, and we design the boundaries before the feature ships.

If your AI reads content from outside your walls, some of that content will eventually be written to talk to your model. Build as if it already has.