OWASP's prompt injection reference explains how direct inputs or external content can attempt to change a model's behaviour. The reference belongs to the 2025 edition, but the question grows more important in the applications we are discussing during 2026: what if the assistant reads a file and then treats text inside it as a command it has the authority to carry out?
The difference between information and authorisation
Suppose an employee asks for a summary of the attachments to a case. The attachment's role is to supply the task with information, while the employee's request and the application's policy determine what may be done. A sentence inside the file asking for a change in how the work is done does not thereby become an approved instruction. This separation must be reflected in the design, not only in a verbal warning message.
The risk, as I see it, becomes clearer when the assistant has tools for reading, sending, and editing. That is why I would split the task into stages and limit each stage to what it needs. The summarising stage does not need permission to send, and showing a proposed edit does not require carrying it out straight away.
Layers of protection that can be tested
I start by identifying the expected data sources and classifying how far each can be trusted. Then I keep retrieved content distinct from application instructions, and check the format of outputs before passing them to another tool. These steps reduce the chances of external text turning into an unintended action, but they need continuous testing and updating.
- Give tools the least access the task requires.
- Show the user the details of any consequential action before it is approved.
- Restrict the destinations and fields a tool can work with.
- Log the source, the operation, and the result to make review easier.
Searching within the organisation's own documents is not, in my view, sufficient protection on its own. A document may have been attached by an external party, be an unapproved version, or contain text unrelated to the request. Nor does verifying the format of an answer prove that its content is correct or that its use is legitimate.
What should pass the test?
I suggest testing with safe sample files that contain instructions unrelated to the task, and confirming that the assistant treats them as content and does not expand its permissions. Success includes staying within access limits, stopping when there is a conflict, and not sending data to a destination the user has not approved.
What I look for in defensive design is behaviour that can be verified in difficult cases, with a clear path for human review. The more a system is able to act, the more valuable a precise separation becomes between the evidence it reads and the permission under which it acts.