Imagine an accounts payable assistant reviewing an invoice. Its job is to extract the amount and match it to a purchase order. The invoice also contains text asking the assistant to change the supplier's payment details. This is a hypothetical example, but it exposes a precise design question: can text inside a document obtain authority that its sender never had?
Indirect prompt injection puts instructions in material an AI system reads, such as a document or a retrieved page. OWASP recommends treating that material as untrusted and combining several controls. A warning in the system prompt is insufficient on its own. OWASP: prompt injection prevention
Start with the work you actually authorized
For this invoice workflow, I would write the permitted job in ordinary language before choosing tools: read the invoice, compare it with an existing purchase order, and prepare a review item. Changing a supplier's bank account would remain a separate process with its own owner. That makes the product easier to evaluate. A reviewer can compare every proposed action with a short, agreed scope.
OWASP's agent security guidance calls for limited tool permissions and independent enforcement. An agent can propose an action, while an execution component checks whether its scope and approval allow it. The component that performs a change must enforce the boundary even when the model produces a persuasive explanation. OWASP: AI agent security
Keep the reader's access narrow
One pattern described by OWASP uses a quarantined model to parse untrusted material without tools. This limits what the reader can do directly. Its extracted output still needs validation before a more privileged component uses it; a tool-free reader can still return manipulated text. OWASP: quarantined parsing
In our hypothetical design, the reader would return invoice fields and the source location for each field. I would give the review screen space for missing or conflicting values. An invoice number that cannot be found should appear as missing, so the operator can resolve it. A polished summary that hides uncertainty would make that job harder.
Make approval specific enough to review
OWASP recommends human approval for high-risk actions and treats approval as something the execution layer must verify. Asking the model whether a change is safe leaves that decision inside the system being manipulated. OWASP: approval and execution controls
I would make our invoice review show the supplier record, the proposed update and the source evidence together. The reviewer should be able to see exactly what would change. If the proposed values change after review, the workflow should return for a fresh decision. A button labelled Approve AI work would tell the reviewer too little.
Test the boundary with an ordinary-looking document
For this example, I would add a test invoice containing a request outside the agreed task and run it through the same intake path as an ordinary invoice. The team would inspect attempted actions and actual downstream changes, then confirm that the legitimate extraction still works. A refusal in the chat window alone would not answer whether the connected system changed.
This test would be one part of the review, not a claim that prompt injection is solved. I would also ask the operations owner to use the resulting review screen without an engineer explaining it. If they cannot tell what was read, what was proposed and what still needs their decision, the workflow needs more work before it handles real invoices.
