Prompt injection occurs when input redirects an AI system in unintended ways. For a tool-using assistant, the key question is whether material it reads is allowed to change the task or authorise actions.
OWASP’s GenAI guidance explains that injections can arrive through content and that retrieval or fine-tuning does not fully remove the risk. The example here is deliberately non-executable and contains no instructions for attacking a real system.
A page can provide useful information while its embedded requests remain part of the material being read. Keeping that distinction visible helps explain the assistant’s task: use the relevant content to answer the user’s request within the permissions already granted.
Follow a harmless example
Suppose the user asks an assistant to summarise a supplied document. Inside the document is a sentence telling the assistant to abandon the summary and produce a promotional slogan. That sentence belongs to the material being analysed; it is not a new instruction from the user.
The trust boundary separates the user’s task from the document’s contents. Relevance to the task does not confer authority over the task.
Inspect the system around the model
| Boundary | Question |
|---|---|
| Inputs | Which sources can introduce content? |
| Instructions | Which parties may change the task? |
| Tools | Which operations can the assistant perform? |
| Data | Which information can it access or disclose? |
| Approval | Which proposed actions require a person’s decision? |
Review permissions as well as wording. The consequences of an incorrect interpretation depend partly on what the system can do next.
Evaluate with contained tests
Use approved, harmless test material and inspect whether the assistant preserves the intended boundary. Record each outcome with the test conditions and any remaining limitations. Treat suspicious outside instructions as content to assess, and keep any consequential action subject to the applicable authorisation rules.
Work through a document-reading example
The fictional user request is: summarise the maintenance dates in the supplied document. The document contains ordinary schedule information and a paragraph asking the assistant to replace its answer with a promotional message.
The requested output is still a summary of the maintenance dates. The extra paragraph can be recognised as content in the document while the assistant continues with the authorised task. If the user needs it noted, the summary can identify the unrelated request without adopting it.
Extend the example to a tool action
Suppose the same document also asks for a file to be sent somewhere. That request raises a separate authority question: the user authorised reading and summarising, while the document supplied a new proposed action. The application needs a clear permission boundary for any external operation.
A review record can capture the user task, source material, proposed tool action and expected handling. Use harmless test fixtures and compare actual behaviour with that expectation. Keep the read-only result and action controls separate in the assessment.
The useful outcome is a documented account of what the system did with untrusted material and which actions its configuration allowed. Tests can reveal a particular behaviour under stated conditions; ongoing controls and review remain part of operating the workflow.
In the fictional slogan example, the expected output can be written down before the test: a faithful summary of the supplied document. The review then checks how the assistant handled the embedded request as well as whether it completed the summary.
Sources consulted
- LLM01:2025 Prompt Injection — OWASP GenAI Security Project; consulted 3 November 2026.