Prompt injection boundaries
Supplier documents must not become agent instructions
An assistant may need to read an external document without accepting its requests. Keep the authority to act in application code and authenticated user intent.
In this article
A quote is evidence, not permission
A purchasing assistant reads a supplier's proposal to extract prices and delivery dates. In a footnote, the proposal asks the assistant to export the buyer's internal comparison sheet to an external address before continuing. The text arrives through an ordinary business document, not through the user's request.
This is the central problem with indirect prompt injection. Material the system needs to interpret can also contain instructions aimed at the model. The document may be relevant and accurately retrieved while still being an inappropriate source of authority.
A stronger instruction in the system prompt can help guide behaviour, but it does not remove the application's responsibility to control actions. Design the workflow so a mistaken model decision cannot turn a supplier's sentence into permission to export internal information.
Separate the proposed action from execution
Let the model produce a proposed operation using a narrow schema. The application then checks the authenticated user's authority, the target records, destination, allowed fields and any required approval. These checks should run for every execution, including retries and actions resumed from a saved conversation.
For the purchasing example, the document-reading stage needs access to the proposal. It does not automatically need an unrestricted email tool or the ability to read every internal comparison. Smaller capabilities reduce the consequence of a model following hostile content.
- Read proposalTreat supplier text as untrusted evidence
- Propose operationReturn a typed request with explicit targets
- Enforce policyCheck identity, scope, destination and approval
- ExecuteUse a restricted service identity and record the result
Make the allowed workflow concrete
A rule such as "do not leak data" is difficult to enforce directly. A rule that a comparison export may only be sent to an approved internal workspace is more concrete. Resolve the destination through application-owned configuration rather than accepting an arbitrary URL or email address from generated text.
Where an external destination is a legitimate part of the workflow, require the user to choose or approve it through a trusted interface. Bind that approval to the actual records and destination. If the proposed payload changes afterwards, the earlier approval should not cover it.
The same principle applies to read tools. A harmless-looking lookup can expose information to the model that later appears in its answer. Limit data access according to the task and user, not merely according to what the service account can technically retrieve.
Test the boundary even when the model fails
Use a synthetic supplier document containing an unauthorised export request. Observe whether the model proposes the export, then independently verify that execution is denied. A refused proposal demonstrates useful model behaviour. A denied execution demonstrates the application boundary. They are different results.
Also test a normal proposal so protective controls do not make the intended task unusable. The goal is a system that can read messy external material while preserving clear authority over what it reads, changes and sends.
Primary sources
OWASP: prompt injection overviewOWASP: authorisation guidanceReferences checked 11 September 2026.