Prompt Injection: Direct, Indirect And Why It Cannot Simply Be Patched

Prompt injection is the first entry in both the 2025 and 2026 editions of the OWASP Top 10 for LLM Applications.¹ It happens when text that reaches a large language model changes what the model does in a way the application’s developer did not intend. Sometimes a user types the hostile instruction. More worrying is when the instruction is hidden in an email, a web page or a shared document that the model reads on someone else’s behalf.

This article explains the two forms, why the problem is structural rather than a bug waiting for a patch, and the kinds of controls that reduce the harm. It stays at the level a defender needs. It does not include working attack text.

Direct And Indirect Injection

In direct injection, the problem text arrives through the application’s own input, usually the chat box or the request a program sends to the model’s interface (its API). Most often the user is the attacker and tries to talk the model out of its instructions, for example to reveal its hidden configuration or produce content the application is meant to refuse. Intent is not required, though. OWASP counts cases where an honest user unknowingly submits material that redirects the model.¹ Jailbreaking, covered later in this group, is a close cousin.

In indirect injection, the attacker never talks to the model at all. They plant instructions in content the model will later process: a web page an assistant summarises, an email a copilot reads, a file in a shared drive, or the result returned by a tool. The victim is an ordinary user who asked an innocent question. NIST’s adversarial machine learning taxonomy treats these as two separate attack classes against generative AI.²

Kai Greshake and colleagues described indirect injection in a paper first posted in February 2023. They showed that planted text could steer real LLM-integrated applications, including Bing’s GPT-4 powered chat and code-completion tools, towards data theft, manipulated answers and unauthorised API calls.³

How An Indirect Attack Unfolds

The steps below show the general pattern. Each step is ordinary behaviour for an assistant; the harm comes from the combination.

This pattern has been shown to work against a production product. In June 2025 Microsoft published CVE-2025-32711, a flaw in Microsoft 365 Copilot that researchers nicknamed EchoLeak. NVD describes it as AI command injection that lets an unauthorised attacker disclose information over a network; Microsoft scored it 9.3 (critical), while NVD’s own score is 7.5 (high).⁴ A case study of the flaw published in September 2025 describes a chain that needed no click from the victim and started with a single crafted email, which got past several separate safeguards to move data out of the user’s context.⁵

Why It Cannot Simply Be Patched

Security teams know how to fix SQL injection, where attacker text slips into a database command. They use parameterised queries, which send the command and the user’s data to the database separately, so the database never confuses one for the other. The UK National Cyber Security Centre argued in December 2025 that prompt injection has no such fix, because inside an LLM there is no separation between data and instructions. The model sees one stream of tokens, the small chunks of text it reads and writes, and predicts what comes next.⁶ Its blog post concludes that prompt injection may never be mitigated as completely as SQL injection, and that the realistic aim is to lower the likelihood and impact of attacks.

NIST reaches a similar view. Its 2025 taxonomy notes that current mitigations do not give full protection, and suggests designing systems on the assumption that injection is possible whenever a model reads untrusted input.² OWASP’s 2025 entry says it is unclear whether any fool-proof prevention exists, given how models work.⁷

What Reduces The Risk

Because no one has shown a way to close this weakness reliably inside the model, defence shifts to limiting what a fooled model can reach and do. OWASP’s guidance and the NCSC’s advice point to the same families of control:⁷⁶

• Least privilege. Give the model and its tools only the data and permissions the task needs, ideally the permissions of the current user and no more.
• Separate and mark untrusted content. Keep retrieved content clearly labelled as data so the application, and where possible the model, can tell it apart from instructions.
• Validate outputs. Check model output against an expected format before it reaches a browser, database or tool, and block outbound links or requests that are not needed.
• Human approval for high-impact actions. Sending money, deleting data or emailing outside the organisation should need a person to confirm.
• Monitoring and testing. Log prompts, retrieved content and tool calls, and run adversarial tests before and after launch.

None of these is new to security teams. What is new is applying them to a component that can be talked into following instructions from whatever it reads. The architectural patterns that contain injection are covered in Designing LLM Applications That Stay Safe When The Model Is Fooled, and agent-specific risks in Agentic AI Security.