A retrieved document can inform an AI assistant without becoming its boss

Retrieved proposals can supply evidence without authorising disclosures, tool actions or changes to the task.

A retrieved document can inform an AI assistant without becoming its boss

An assistant is asked to compare two supplier proposals. One document contains delivery terms, a pricing table and a paragraph that tells the assistant to change its instructions. The paragraph may look like part of the proposal, but it is trying to exercise authority over the review. A useful system must be able to read a supplier's claims without granting that supplier control over what the assistant may disclose, change or send.

This analysis, prepared and source-checked on 17 October 2026, examines indirect prompt injection through retrieved documents. It draws on dated US and UK public guidance and the OWASP community's 2025 risk entry. It is not a report of an attack on a named organisation, a penetration test or a claim that any particular product is secure. The supplier-review scenario below is hypothetical and uses no real records.

Understand the failure being discussed

NIST's March 2025 adversarial-machine-learning taxonomy describes indirect prompt injection through resources that an attacker can influence, including material retrieved by an AI application. It distinguishes availability, integrity and privacy consequences and discusses mitigations without promising full protection against every technique. Its taxonomy is a way to describe the problem, not a certificate that a deployment has solved it. [NIST report, section 3.4](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-2e2025.pdf)

The UK's National Cyber Security Centre, in its 8 December 2025 analysis, cautions against assuming that prompt injection can be resolved in the same way as SQL injection. Its argument concerns the absence of an inherently enforced instruction/data boundary inside present language-model prompts. It recommends attention to the remaining risk and its consequences, rather than assuming a clever delimiter makes untrusted material harmless. [NCSC analysis](https://www.ncsc.gov.uk/blog-post/prompt-injection-is-not-sql-injection)

OWASP's LLM01:2025 entry distinguishes direct from indirect injection and recommends controls including limited privileges, separation of external content and human approval for high-risk operations. These are community security recommendations. They do not establish an attack rate or prove that a particular combination prevents all failures. [OWASP risk entry](https://genai.owasp.org/llmrisk/llm01-prompt-injection/)

The common implication is an application-design question. If a document persuades a model to make an inappropriate request, what can the surrounding software still prevent? That question is especially important when the assistant has access to private material or tools that can change something outside the conversation.

Trace authority through the supplier example

In the fictional review, the user authorises a comparison of proposals. The proposals provide evidence about what each supplier offers. They do not authorise sending internal budgets to a supplier, changing the evaluation criteria or updating a purchasing record. Those permissions should come from the organisation's actual workflow and the current user's approved role.

Start by drawing the path from document ingestion to output. Identify where external text enters, which other records become visible, which tools are available and what a proposed tool call could change. Include summaries and intermediate notes: text can pass through several transformations before reaching the assistant that acts. A document's filename, repository location or polished formatting should not silently turn its contents into trusted operating instructions.

Keep access checks outside the model's answer. The application should decide whether the signed-in reviewer can read a record and whether an operation is permitted. A model-generated explanation that access is justified is not the access check. Likewise, tool arguments need validation against the actual requested task and selected objects; a well-formed request can still target the wrong supplier or record.

Give the assistant only the action it needs

For an initial comparison task, a read-only assistant may be sufficient. It could draft a table of differences and link each factual statement to its source passage. A separate approved workflow could handle contacting suppliers or changing purchasing records. This is a proposed design boundary, not a claim that read-only output cannot mislead someone.

If later versions can act, define narrow operations rather than handing the model a general account credential. The software can constrain which object and fields an operation may affect, check the current user again and present the actual consequence for review. An approval should concern a concrete proposed action and destination. A vague request to “continue” should not conceal that a document caused the destination to change.

Treat source labels and warning text as supporting measures. They can help a model or reviewer understand where material came from, but their presence is not proof that the boundary held. Record attempted inappropriate requests even when the tool layer rejects them, without retaining unnecessary private document contents in diagnostic logs. This makes a blocked failure visible while preserving the distinction between an attempted request and an executed action.

Test the whole application in an authorised fixture

A bounded evaluation could use synthetic supplier documents with benign instructions that conflict with the assigned comparison. No real credentials, private bids or external destinations are needed. Ask whether the assistant remains on task, whether the application rejects unauthorised operations and whether the reviewer can still complete the legitimate work. Include ordinary documents so that a defence is not judged only by how much it blocks.

Keep model, prompt, retrieval settings, document versions and tool permissions fixed for a comparison. Then vary one part at a time. A change that reduces inappropriate tool requests might also remove useful evidence from summaries. Record both outcomes. Tests should cover the paths the deployed application actually uses, including imported files and retrieved notes, rather than only a chatbot input box.

Decide what happens when a concerning request appears. The system might stop the affected action, preserve a safe draft and explain that a source contained instructions outside the assigned task. It should give the reviewer a route to inspect the source or complete the comparison manually. It should not silently report that the supplier was rejected, contacted or approved when nothing of that kind occurred.

The benefit of this approach is a useful assistant with consequences limited by the surrounding application. The costs include narrower automation, additional review and continuing evaluation as models and documents change. There is no universal prompt that substitutes for those decisions. A retrieved document should be allowed to contribute evidence to the task; authority over the task must remain with the people and systems actually entitled to grant it.