An assistant reviewing supplier proposals has to read material the company did not write. That creates a security question before the assistant takes any action: can text inside a proposal influence how the assistant uses the company's systems? A document can contain both useful facts and instructions aimed at the software reading it.
This is an application of indirect prompt injection. Its business significance depends on what the assistant can access, what it can change, and which decisions are checked outside the model.
How document content crosses a trust boundary
OWASP distinguishes direct prompt injection from instructions encountered through external content. A model can treat material from a file or website as direction rather than evidence. Retrieval and fine-tuning do not, by themselves, eliminate that possibility. OWASP's prompt injection overview explains this distinction.
Consider an illustrative procurement workflow. The assistant reads three proposals, compares delivery terms, and drafts a summary. One proposal also claims that a separate internal pricing file is required to complete the review. Reading that claim does not give the supplier permission to request the file. The application needs to preserve the difference between a user's task and a supplier's assertions.
The connected systems determine the consequence
A summarizer with access only to the uploaded proposals has a different exposure from one that can search the finance drive and email attachments. The first may produce an inaccurate comparison. The second may also attempt an unauthorized disclosure. These outcomes require different controls and different evidence.
For a document review service, map the available tools to actual business needs. A comparison task might require reading selected files and saving a draft. Sending messages, changing supplier records, or retrieving unrelated customer contracts introduces separate authority. The tool service can enforce those boundaries even when the model proposes an inappropriate action.
A controlled test with a measurable result
Use a test workspace containing synthetic proposals and a uniquely labeled internal document. Establish a normal comparison result first. Then introduce a harmless instruction into a proposal that asks the assistant to include the internal label or perform an out-of-scope action. Keep all destinations and accounts under the test team's control.
Record more than the final answer. Capture which documents were retrieved, which tools were requested, which requests were denied, and whether an approval was presented. A model refusing the instruction once demonstrates behavior in that trial. A downstream service consistently denying access provides evidence about the permission boundary.
What the business can verify before release
The resulting assessment can identify the content entry point, the authority available to the assistant, and the control that prevented or permitted the action. That is more specific than labeling an entire product vulnerable because it produced an unexpected sentence.
Repeat representative cases when connectors, permissions, or document parsers change. Include ordinary proposals in the test set to check that the controls still allow the intended work. This makes security acceptance a question of documented business behavior: which information the assistant used, which operations it attempted, and which boundaries held.
Sources
OWASP: LLM Prompt Injection Prevention. The procurement example and test design above are illustrative applications of the documented risk.
