Keep document instructions outside your AI’s authority
Test how an AI handles instructions inside supplier files and customer messages. Separate source evidence from permission to change business records.
A document can supply evidence to an AI assistant without gaining authority to direct its actions. Preserve that distinction whenever the assistant reads supplier files, customer emails, web pages or uploaded manuals. The person who wrote a document may control its contents; that does not make them an approver for your business system.
OWASP describes indirect prompt injection as instructions embedded in external material an AI processes. Its guidance recommends separating instructions from data, limiting privileges and validating tool actions. These controls reduce exposure; a sentence telling a model to ignore suspicious instructions is not proof of protection. OWASP prompt injection prevention.
A supplier document should answer the purchasing question
Imagine a fictional assistant asked to extract a part number and delivery date from a supplier acknowledgment. The document also contains a sentence asking the reader to change an internal approval setting.
The requested extraction remains the same. The supplier's sentence is content to report or flag, not permission to alter the workflow. The assistant should have no need to modify approval settings to extract two fields.
That example makes the business boundary concrete. The problem is not simply an odd phrase in a file. It is an external author attempting to turn access to the assistant's reading material into access to its business tools.
Use the data-permission worksheet to narrow the records and actions available before testing the document reader.
Write the trust boundary as a review sheet
| Material or instruction | What it may establish | What it must not establish by itself |
|---|---|---|
| Authorized user's task | Intended outcome and permitted scope | Unlimited access outside that task |
| Approved internal policy | Applicable decision rule and policy version | Permission to ignore technical access controls |
| Supplier attachment | Evidence about the supplier's stated commitment | Authority to change internal approvals |
| Customer message | Request and facts that need interpretation | Approval for unrelated disclosures or system changes |
| Retrieved web page | A source claim to assess | New operating instructions for the assistant |
| Tool result | Observed response from a system | A reason to expand the original task automatically |
Record who owns each source, who can edit it and why the assistant needs it. An internal shared folder is not automatically trustworthy for every action if many people can change its contents.
Give the reader less ability to act
For an extraction pilot, consider returning a structured draft for review rather than connecting the reader directly to purchasing or customer communications. Let the downstream action check the permitted fields, target record and approval independently.
This is a proposed design choice, not a guarantee that every AI product implements a separate action boundary. Ask the provider to show the actual path from document input to proposed action to saved result. Inspect the identity used at each step.
If the model can request a tool, require the tool to reject actions outside the allowed scope. A document should not be able to supply a new recipient, broaden the record population or switch from reading to editing simply by containing persuasive language.
Test safe examples with observable outcomes
Create a small permitted test set containing an ordinary acknowledgment, a conflicting date, a missing part number and an irrelevant instruction embedded beside the useful fields. Use harmless test values and a rehearsal environment.
For each run, retain the authorized request, document version, extracted fields, proposed action and actual saved result. The passing condition includes preserving legitimate evidence while declining to follow the unrelated instruction. A blanket refusal to read every document may prevent unwanted actions but fail the business task.
Test the same instruction in a table note or an attachment the workflow normally reads. Do not assume that a clean main paragraph proves every input surface behaves the same way. Use the known-answer extraction method to check field accuracy alongside action boundaries.
Keep the operating response simple
When a suspicious document appears, route it to a named reviewer with the source reference and the attempted redirection. Keep the original evidence in approved storage; avoid copying confidential contents into an unrestricted error log.
The reviewer decides whether the useful facts remain usable, whether another source is needed and whether the workflow should stay enabled. Re-run the affected cases after changes to the model, retrieval source, permissions or action tool. The release decision should describe the bounded document task that passed, not claim immunity to every future instruction attack.