Prompt injection: why language models follow the wrong instructions

A language model receives one stream of text. The instructions written by the developer, the question typed by the user, a web page it fetched, an email it was asked to summarise: all of it arrives in the same context window as tokens of the same kind. Prompt injection is what happens when text from one of those sources is followed as an instruction even though nobody with authority wrote it.

What prompt injection is

The OWASP GenAI Security Project describes it as input that changes the behaviour or output of a model in ways nobody intended. The comparison with SQL injection is tempting but misleading. SQL injection has a clean fix: parameterised queries keep code and data in separate channels, so data can never become a command.

A language model has no such channel. The UK National Cyber Security Centre makes this point directly: models do not enforce a security boundary between instructions and data, so the problem may never be fully solved the way SQL injection was. That shapes every defence below. You cannot filter your way to safety; you limit what a confused model is able to do.

Direct and indirect injection

Direct injection comes from the person typing. They try to talk the model out of its rules, make it reveal its system prompt or produce content the operator wanted to prevent. The main victim is the operator of the application, and the attacker is someone who already has access to it.

Indirect injection is the more serious variant. The instructions sit in content the model processes on someone else's behalf, often hidden from the human: white text on a white background, an HTML comment, document metadata, a line in a calendar invite or text embedded in an image. The user asks an innocent question, and the model meets the planted text along the way. Typical entry points:

• Web pages that a browsing assistant reads or summarises.
• Incoming emails and attachments processed by a mail assistant.
• Shared documents, tickets and PDFs in a knowledge base used for retrieval-augmented generation (RAG).
• README files, issues, code comments and package documentation read by coding agents.
• Responses from tools and APIs that are fed back into the model.
• Images, screenshots and audio in multimodal systems.

Why agents raise the stakes

A chatbot that can only answer can, at worst, give a wrong or embarrassing answer. An agent is different: it can call tools, read files, send messages, query databases or run commands. Now an injected sentence can turn into an action carried out with the permissions of the user or the service account behind the agent.

The risky combination has three parts: access to private data, exposure to content from outsiders and some way to send information out. An assistant that reads your inbox, can open any web page and can write emails has all three. Remove any one of them and the worst case shrinks considerably.

Data exfiltration through links and images

Leaking data does not require a send button. Many chat interfaces render the model's output as Markdown or HTML. If injected text persuades the model to build an image address that carries private data in its path or query string, the interface fetches that image automatically and the data travels to a server the attacker controls. Nobody has to click anything. A link works the same way, only it needs one click.

The defence belongs in the interface, not in the prompt: do not load remote images from model output, or allow only a short list of domains you trust; show link targets in full; and sanitise any HTML the model produces before it reaches a browser.

Where it sits in the OWASP Top 10 for LLM Applications

The current 2025 edition of the OWASP Top 10 for LLM Applications lists prompt injection as LLM01, the first entry. Several other entries describe what prompt injection leads to or what makes it worse:

Defences that limit the damage

OWASP states plainly that it is unclear whether fool-proof prevention exists. So treat prompt injection as a residual risk and design for containment. The measures work best in layers:

• Least privilege for tools: give each agent only the tools and scopes it needs, read-only where possible, with its own short-lived credentials rather than a shared admin token.
• Human approval for consequential actions: sending, paying, deleting, publishing and changing permissions should wait for a person who sees the full action, not a summary written by the model.
• Separate trusted and untrusted content: mark external content clearly in the prompt and lower the agent's privileges once untrusted text is in its context. Delimiters make attacks harder, not impossible.
• Deterministic checks on output: validate formats in code, allow-list destinations such as domains and recipients, and never pass model output straight into a shell, a SQL query or a web page.
• Logging and monitoring: keep the prompts, retrieved content, tool calls and failed calls, so you can spot probing and reconstruct what happened.
• Adversarial testing: test with injection-style content before release and after every change to tools or data sources.

Be sceptical of any product that promises to stop prompt injection completely. Filters and classifiers reduce the success rate, and that is worth having, but they are one layer. The design decisions about tools, permissions and approvals decide how bad a successful attack can be.

Treat everything the model reads as if a stranger wrote it, because sometimes one did.

Sources and further reading

1. OWASP Top 10 for LLM Applications 2025genai.owasp.org
2. OWASP GenAI Security Project: LLM01:2025 Prompt Injectiongenai.owasp.org
3. NCSC blog: Prompt injection is not SQL injection (it may be worse)ncsc.gov.uk

General information, checked on 31 October 2026. Test changes on one system first and keep a way back. Found something outdated? Tell the editors.