Handle prompt injection in retrieved business documents

A document assistant needs to read business material without accepting that material as operating instructions. The distinction becomes critical when files come from suppliers, shared folders, or external websites. An uploaded document may mix useful facts with text that attempts to redirect the assistant. Plan for that possibility before connecting operational tools.

Identify the trust boundary

OWASP describes indirect prompt injection as behavior changes caused by content from external sources such as websites or files.[3] A document’s relevance does not make its instructions trustworthy. Keep the user’s request, application rules, and retrieved content conceptually separate in the design.

Mark retrieved passages as evidence to interpret, not authority to expand the task. Ask the assistant to cite factual statements and flag conflicting instructions. These measures can help communicate the boundary, but do not present them as a complete security control. OWASP does not identify a foolproof prevention method.[3]

Limit the consequences outside the model

OWASP recommends authorization in downstream systems rather than letting the model decide whether an action is allowed.[4] Apply that principle to every connected operation. A document answerer should not automatically inherit permission to send messages, export collections, or modify records.

Keep retrieval within the requesting user’s authorized scope. Validate tool requests with ordinary application code and narrowly defined interfaces. For consequential operations, require an independent approval step that shows the actual target and payload. A suspicious document should never be able to grant the permissions needed to follow its own instructions.

Test the whole document path

Test extraction and retrieval as well as the final prompt. A harmless-looking file name does not tell reviewers what text reaches the model. Use controlled test material and avoid real confidential records.

• Place conflicting instructions inside a relevant test document and inspect the resulting answer.
• Check whether hostile text can trigger a tool call or change its destination.
• Verify that restricted documents remain unavailable to unauthorized users.
• Record attempted actions, denied requests, and the evidence used for each response.
• Retest after changes to parsing, retrieval, prompts, models, or tool permissions.

Hypothetical example: a supplier comparison

A hypothetical sourcing team asks an assistant to compare maintenance terms from supplier proposals. One proposal includes text that directs the assistant to send the entire comparison folder to an external address. The application should treat that text as document content, not a new user instruction.

The proposed design offers no email tool during comparison. Export requires a separate workflow with recipient checks and human approval. Reviewers still test whether the answer itself exposes unrelated material. Removing one tool limits one consequence, but does not prove the model resists every injection attempt.

Define a containment response

When suspicious instructions appear, preserve a restricted diagnostic record, isolate the affected source, and offer an alternative way to inspect the material. Decide who can restore it. Layered controls add engineering and review effort. That cost should be weighed against the specific data and actions the assistant can reach, not against a promise of immunity.