Practical AI
An AI assistant should read a supplier document—not take orders from it
Keep document reading separate from permission to act when adding AI to supplier intake and purchasing support.
The document is evidence, not the manager
Imagine an assistant that reads supplier submissions and prepares a purchasing comparison. A document contains product specifications and a sentence telling the assistant to send internal pricing information to an outside address.
The assistant was asked to read the file. It was not authorized to follow instructions from the file’s author. That distinction matters even if most supplier documents are ordinary and useful. Once a document-reading assistant also has tools that send messages or change records, a content mistake can become an operational action.
This is an illustrative risk scenario, not a report of an incident at Quarro or a customer.
Why “ignore suspicious instructions” is only one layer
The familiar starting point is a clear prompt: extract the requested fields and ignore unrelated commands. That remains useful guidance, but it should not be the only protection around an application that can act.
OWASP describes indirect prompt injection through material such as documents and retrieved content. Its prevention guidance recommends separating untrusted input from trusted instructions and enforcing permissions outside the model. It also cautions against treating screening or structured prompts as a complete defense. In business terms, a document can inform a proposed action without having authority to approve it. OWASP LLM Prompt Injection Prevention Cheat Sheet.
The practical improvement is not simply a longer warning in the prompt. The UK's NCSC argues for deterministic safeguards that constrain actions rather than relying only on blocking hostile text. The following supplier example applies that principle by separating reading, proposing and executing. NCSC design guidance, December 2025.
A proposed three-stage workflow
Read. The document-processing step extracts the product, quantity, stated lead time and source locations needed for a comparison. It does not need a tool that sends email or edits supplier payment details. Keep the original document associated with the extracted result so a reviewer can check the evidence.
Prepare. The application forms a proposed comparison or draft update using only the fields appropriate to that task. Missing information stays missing. A statement in a supplier file that says a manager approved something remains a supplier statement; it is not converted into an approval record.
Act. If the workflow includes an action, the application checks the authenticated requester, permitted operation, target record and approved values. Those checks belong in the execution path. A model’s explanation that an action is safe is not the authorization itself.
For a read-only first release, the third stage may simply be absent. Producing a reviewable comparison can be useful without giving the assistant an unrestricted operational role.
Make the review screen answer a real question
A generic “approve AI output” button leaves too much to interpretation. In this proposed design, the reviewer sees the exact record, proposed field changes, supporting passages and any unresolved disagreement. If an action would send information externally, its destination and content should be visible as part of that specific action.
For this supplier comparison, place the quoted specification beside the proposed field so the reviewer can inspect a concrete discrepancy—for example, whether a lead time describes dispatch or arrival. A page-level approval of the whole document would not explain which interpretation the purchasing team selected.
Evaluate the boundary with representative documents
Before adding operational tools, prepare controlled test documents containing both ordinary purchasing information and irrelevant instructions. Ask whether the assistant still extracts the legitimate information, whether unsupported values are flagged, and whether any attempted action reaches an execution boundary it should not cross.
Include documents with missing pages, conflicting values and quoted instructions that are legitimate content—for example, a product manual explaining a command. Rejecting every document containing imperative language would damage the useful task. The goal is to keep data interpretation separate from authority, not to ban particular words.
Record the actual outcomes and limits of these tests. Microsoft's researchers distinguish AI red teaming from safety benchmarking and emphasize understanding a system's capabilities and application context; their January 2025 paper also describes securing AI as continuing work. A handful of supplier examples should therefore be reported as a limited check, not a universal safety result. Lessons From Red Teaming 100 Generative AI Products. A read-only comparison still needs source review: it can misstate a dispatch estimate as an arrival promise without making any tool call.
Scope the first engagement around one document decision
A sensible starting point is one supplier-document type and one comparison task. Identify the requested fields, the allowed sources, what reviewers need to see and which actions are deliberately outside the first release. Then evaluate the extraction and the permission boundary separately.
That makes a potential AI implementation concrete: a documented reading task, a reviewable output and measured test evidence. It avoids selling an all-purpose autonomous purchasing agent before the business has defined what it should be allowed to do.