When retrieved text becomes an instruction

A retrieval system finds a relevant document. The application places that document beside the user’s question. The model reads both. So far, this looks like a useful way to answer a question with supporting context.

The security question is what happens when the document contains instructions of its own.

A small thought experiment

Imagine a fictional internal assistant asked to summarize a public onboarding guide. Halfway through the guide, someone inserts a paragraph that asks the assistant to abandon its summary and send a private note to an external address.

That paragraph is document content. It carries no authorization from the user. Yet the application has placed it in a channel the model can interpret as language to act on.

This is a useful way to reason about indirect prompt injection: an instruction arrives through material the assistant was supposed to read as data. OWASP describes external documents and tool outputs as possible injection surfaces and recommends layered controls rather than reliance on a single prompt. OWASP’s prompt injection prevention guide.

Draw the boundary before choosing the defense

For this example, sketch the flow:

User asks for a summary
        ↓
Application retrieves a document
        ↓
Model reads the retrieved text
        ↓
Model proposes an answer or action
        ↓
Application checks and handles the proposal

Mark the document as untrusted input. Then mark every place the application might act: sending a message, opening another file, or invoking a tool. The consequential boundary is where a model proposal becomes an authorized operation.

Separate reading from permission

For our fictional assistant, the allowed job is narrow: read the selected guide and return a summary. A request to send a message should fail an application-level permission check regardless of how persuasive the document sounds.

Practical review questions for this design:

• Can the assistant retrieve documents the current user cannot read?
• Does a tool independently verify the action, destination, and resource?
• Can a document influence which credentials or tools are used?
• Does an approval screen show the actual proposed action?

These questions are a review checklist for the example, not evidence that a particular product is vulnerable.

What to test

Create a local fixture with ordinary document text and another with a harmless instruction to request an out-of-scope action. Keep the user task identical. Record the proposed action and the authorization decision separately.

A blocked tool call does not prove the model ignored the injected text. It shows that one application boundary held in that test. That distinction makes the result much more useful.

Try the interactive trust-boundary simulation to explore the difference without connecting a model or external service.