The attack that never touches the chat box

Where does the instruction come from?

From content the system reads on the user’s behalf. A PDF attached to a routine query. A support ticket submitted by a customer. A page the agent browses. A calendar invitation. The output of another tool. A row in a database that somebody could write to.

The attacker never speaks to the assistant. They write text in a place the assistant will eventually read, and wait.

When it fires, a legitimate user has asked an ordinary question. Retrieval pulls the planted text into context, the model treats it as instruction, and whatever follows happens with that user’s permissions. The user sees a normal answer, and often a correct one, because a competent attack completes the task as well as its own.

Why the model cannot simply refuse

Instructions and data arrive through the same channel. A system prompt, a user question and a retrieved document are all text in one context window, and the model has been trained to be helpful about instructions it finds in text.

Provenance markers help and do not solve it. Telling a model that everything after a delimiter is untrusted works until the untrusted content includes text about delimiters. This is why the standards bodies describe mitigations rather than fixes, and why NIST’s March 2025 revision brought indirect injection into the formal taxonomy alongside attacks on agent tool chains.

What does a test for this look like?

It starts in the corpus, not the interface. Plant an instruction in a document that a realistic user would legitimately cause the system to retrieve. Then ask the ordinary question, from an ordinary account, and observe what the system does rather than what it says.

The assertion belongs at the action. Did a tool get called. With what arguments. Under whose identity. Did anything leave the system. A test that ends at “the model repeated the planted text” has established that the injection reached the model, which is the least interesting half of the finding.

Five places to plant, and what each tests

DocumentThe retrieval path, and whether uploaded content is treated as instruction.

Ticket or emailContent written by an outsider that staff-facing tools read.

Web pageAnything the agent browses, including pages an attacker controls.

Calendar or profileFields nobody classifies as untrusted input.

Tool outputOne agent trusting another, which is where multi-agent systems break.

Why the research matters more than the theory here

Johann Rehberger’s published work demonstrates these paths against shipped products rather than laboratory constructions, which is what makes it worth reading before designing a test plan. The attacks are not exotic. They rely on ordinary helpfulness: an assistant that summarises a document, follows a link, or calls a tool because the text in front of it asked.

What actually reduces the risk

Breaking the combination. A system that reads untrusted content and holds private data and can send information outward has a complete path. Removing any one of the three closes it, and that is an architectural decision rather than a detection setting.

Where all three are genuinely required, the remaining controls are ordinary: the model proposes and a deterministic policy decides, consequential actions need a person, outbound destinations are allowlisted rather than free-form, and every confirmed attack becomes a regression test that runs on each release.