An email assistant receives a message asking for a summary, retrieves related company documents, calls a calendar tool, and renders a concise HTML reply. One untrusted email can enter that flow as content, yet the model processes its text alongside the task instructions. If that content changes the output from summarize this message to take an unintended action, we have prompt injection, an input that alters model behavior beyond the application’s intended task.
Our running assistant has five places where content crosses into a model request. The user supplies email text, the retriever returns indexed passages, connected tools return data, the model emits text or tool arguments, and the renderer turns that output into HTML. Each hop has a different trust level, but the model receives a combined token stream rather than a security boundary enforced by the application.
Before we assess controls, inspect where data can become instructions in this flow.
The flow shows why filtering the chat box alone is insufficient. An external email can carry the injected instruction, retrieval can place it in context, and a tool result can repeat it in a later step. HTML rendering adds another boundary because output that is only text to the model may become an active link, markup, or request in the browser. Label every source before it reaches context as trusted, semi-trusted, or untrusted, then preserve that label in logs.
That mixed flow is the scope of OWASP LLM01:2026. It covers direct injection from user input and indirect injection from retrieved documents, emails, web pages, tool output, persistent memory, images, audio, and video. A direct case begins with a user message. An indirect case begins when an email body in our assistant’s retrieval index supplies text that the user never wrote or saw.
We can classify each case along three axes. Delivery surface is where the content entered, such as an email or tool response. Propagation is where it travels next, such as from one retrieval result into persistent memory. Encoding is how it is represented, including plain text, concealed Unicode characters, or instructions embedded in an image. This classification helps us test the actual route, not merely a phrase pattern.
Traditional parameterization prevents data from changing query syntax because the database treats parameters separately. Current LLM applications have no equivalent clean separation when instructions and data arrive as tokens in the same context. Delimiters and labels can clarify intent, but they do not enforce authority. The security boundary must instead sit outside the model, where code checks permissions, validates arguments, and restricts what output can reach.
Working assumption Treat every model input as capable of influencing output, even when it arrived through an internal retrieval system.
Once an injected email affects output, the outcome depends on what the surrounding application permits. If the assistant reveals hidden system content or a retrieved private passage, the storyline reaches OWASP LLM08:2026 Hidden Context Exposure. If it generates HTML that the renderer accepts without sanitization, or tool arguments that downstream code executes without validation, it reaches OWASP LLM10:2026 Improper Output Handling. LLM01 is the input-side compromise that initiates those outcomes.
The same injection can also attempt an unsafe calendar action or persistence in the retrieval corpus. Those consequences increase when a model can call broad tools, but the model’s request must never be its own authorization. The calendar service should verify the user’s authority, limit writable fields, and require approval for consequential changes. The renderer should allow only safe output formats. Each layer limits a different path after the model output changes.
Compare the outcomes to identify which boundary must stop each one.