Most software vulnerabilities are bugs. Someone made a mistake, the mistake gets found, a patch ships, and the problem is over.
Prompt injection is not that. It is a consequence of how large language models work, and in December 2025 the UK's National Cyber Security Centre published a blog post whose title is the entire argument: Prompt injection is not SQL injection (it may be worse).
Their reasoning is one sentence long. In a database, you can force the engine to treat user input as data and never as a command. In a language model you cannot, because — in the NCSC's words — "there's no distinction made between 'data' or 'instructions'; there is only ever 'next token'."
That is why this article does not end with a fix. It ends with containment, which is what the people who study this professionally now recommend.
What Prompt Injection Actually Is
OWASP, which maintains the standard risk list for LLM applications, defines it plainly:
"A Prompt Injection Vulnerability occurs when user prompts alter the LLM's behavior or output in unintended ways."
It is listed as LLM01 — the number one risk in the OWASP Top 10 for LLM Applications, and it has held that position across editions.
The crucial part is that the model is not broken when this happens. It is doing exactly what it was built to do: read all the text in front of it and predict what should come next. It simply has no mechanism for deciding that one part of that text has authority and another part does not.
Direct and Indirect — The Second One Is the Dangerous One
OWASP splits the risk in two, and the distinction matters more than it first appears.
Direct injection is someone typing an instruction into the chat box that changes how the model behaves. This is the version most people have seen, and it is largely a content-moderation problem: the attacker and the victim are the same person.
Indirect injection is the model processing external content — a webpage, a document, an email, a calendar invite — that contains instructions. Here the attacker and the victim are different people. You ask your assistant to summarise your inbox. An email in that inbox contains text addressed not to you but to the model. The model reads it, because reading it is the job.
Indirect injection is the one that scales, because the attacker never needs access to your account. They only need to get text somewhere your assistant will read.
Why "It's Just SQL Injection for AI" Is Wrong
This comparison is everywhere, and it is the reason a lot of people assume a fix is coming. It is worth understanding precisely why it fails.
SQL injection was a catastrophe for roughly a decade, and then it largely stopped being one. The fix was parameterised queries: the query structure is sent to the database separately from the user's values. As the NCSC puts it, the input arrives in a form where "the database engine can never interpret it as an instruction."
That is not a filter. It is not a cleverer blocklist. It is an architectural separation — two channels, one for commands, one for data, enforced by the engine itself.
A language model has one channel. The system prompt, your question, the retrieved document and the email it just read all arrive as the same thing: tokens in a context window. There is no field to put the untrusted part in. The NCSC's summary of the mechanism is worth repeating because it is the whole problem:
"under the hood of an LLM, there's no distinction made between 'data' or 'instructions'; there is only ever 'next token'."
There is a neat irony in the official record. When the first major real-world case was catalogued, the US National Vulnerability Database filed it under CWE-74 — the same injection family as SQL injection. The classification is right. The remedy does not transfer.
If you want the mechanics of why everything ends up in one place, that is the subject of what a context window is and why it matters.
What It Looked Like in Production
In June 2025 a vulnerability in Microsoft 365 Copilot was published as CVE-2025-32711, nicknamed EchoLeak and found by researchers at Aim Security. The NVD description is terse: "Ai command injection in M365 Copilot allows an unauthorized attacker to disclose information over a network."
The severity score is 9.3, critical. But the interesting part is the vector string, because it describes the attack without any marketing language attached:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N
Read it piece by piece:
- AV:N — attack vector is the network. Remote.
- AC:L — attack complexity is low. No special conditions.
- PR:N — privileges required: none. No account needed.
- UI:N — user interaction: none. This is the zero-click part, stated by the scoring system rather than claimed by a vendor.
- S:C — scope changed. The impact crosses a security boundary.
- C:H — confidentiality impact high.
An attacker sends an email. The recipient does not have to open it, click anything, or reply. When Copilot later processes the mailbox on the user's behalf, it reads the attacker's instructions and acts on them. Microsoft fixed this one server-side and no customer action was required — but the fix was for that specific exfiltration path, not for the class of problem.
Three Bodies, One Conclusion
What makes this more than a researcher's opinion is that the organisations whose job is to write the official guidance have all landed in the same place, independently, in their own published words.
What the Standards Bodies Actually Say
Direct quotations from each organisation's own publication.
| Source | Publication | What it says |
|---|---|---|
| SourceOWASP | PublicationLLM01, Top 10 for LLM Applications 2025 | What it saysIt is unclear if there are fool-proof methods of prevention for prompt injection |
| SourceNIST | PublicationAI 100-2, Adversarial Machine Learning | What it saysThere is no foolproof way as yet to protect AI from misdirection |
| SourceUK NCSC | PublicationBlog, 8 December 2025 | What it saysThere is only ever next token — no distinction between data and instructions |
None of them describes a fix in progress
NIST co-author Apostol Vassilev put the state of the art plainly: available defenses currently lack robust assurances that they fully mitigate the risks.
NIST went further than describing the gap. Its announcement warned readers to be "wary of any who claim otherwise" — and the NCSC gave the same advice in procurement terms: "Beware any that claim they can 'stop' prompt injection."
Why Agents Raise the Stakes
A chatbot that gets talked into saying something foolish is embarrassing. An agent that gets talked into doing something is a different category of problem.
The moment a model can send email, call an API, run code or move money, a successful injection stops being a content failure and becomes an action taken with your credentials. The NCSC's term for this is precise: an "inherently confusable deputy" — software acting on your authority that can be convinced to use it for someone else.
This is why the risk has grown sharply without the underlying vulnerability changing at all. The vulnerability was always there. What changed is what we connected it to. The mechanics of that connection are covered in how the agent loop works and in what the Model Context Protocol is — every tool you expose is a capability an injected instruction can reach.
What Actually Helps
Nobody serious claims these eliminate the problem. They reduce how often it succeeds and how much damage it does when it does, which is the honest goal.
OWASP's recommended measures, condensed:
- Constrain the model's behaviour with explicit instructions about its role, scope and limits.
- Define and validate output formats with deterministic code, not with the model's own judgement.
- Filter inputs and outputs, including semantic checks on whether a response is relevant and grounded.
- Apply least privilege — keep tool access and API tokens in application code rather than handing them to the model.
- Require human approval for high-risk actions.
- Separate and clearly label untrusted external content.
- Run adversarial testing regularly, treating the model as an untrusted user.
The NCSC adds the structural point that ties these together: priority belongs to "deterministic (non-LLM) safeguards that constrain the actions of the system." A filter that asks the model to detect manipulation is asking the confusable component to police itself. A permission boundary enforced in ordinary code is not.
They also warn specifically against deny-list filtering — blocking known bad phrasings. There are unlimited ways to phrase an instruction, and the attacker gets to iterate.
How to Read a Vendor's Security Claim
Four questions, drawn from what these organisations actually recommend:
- Do they say "stop" or "reduce"? Both the NCSC and NIST single this out. A vendor claiming prevention is either misinformed or hoping you are.
- Are the safeguards deterministic or model-based? Code that enforces a boundary behaves predictably. A model asked to spot manipulation can be manipulated.
- What can the system do at its most compromised? Assume the injection succeeded. List what it can reach. That list is your risk.
- Is a human in the loop for consequential actions, and is that genuine review or a dialog people click through?
The Bottom Line
Prompt injection is not a bug with a patch pending. It is the direct consequence of a design in which instructions and data are the same substance, and the organisations that write security guidance — OWASP, NIST and the NCSC — have each said in print that they do not know of a complete fix.
That does not make language models unusable. It makes them a component whose compromise you plan for rather than rule out, the way systems are designed around any component that can fail — and it puts this firmly among the security topics worth understanding properly rather than the ones worth panicking about.
The NCSC's closing position is the one worth carrying, because it is the part most coverage leaves out: if you have reduced the risk as far as your design allows and the remaining exposure is still more than the system can absorb, then "it may not be a good use case for LLMs." Deciding that in advance is cheaper than discovering it from a CVE.
Frequently Asked Questions
Can prompt injection be fixed?
No complete fix is known, and the three organisations that publish guidance on it all say so explicitly. OWASP states it is unclear whether fool-proof prevention methods exist. NIST says there is no foolproof way as yet to protect AI from misdirection. The NCSC explains why: a language model has no internal distinction between data and instructions. Individual exploits get patched, as the Copilot vulnerability was. The underlying class does not.
Is prompt injection the same as jailbreaking?
They overlap but are not identical. Jailbreaking usually means getting a model to ignore its own safety policies — the attacker and the user are the same person, and the harm is mostly to the model's operator. Prompt injection includes that, but the serious case is indirect injection, where instructions hidden in external content hijack a session belonging to someone who has no idea it happened.
Why can't the model just be told to ignore instructions in documents?
Because that instruction is itself text in the same context window, carrying no special authority. You are asking the model to weigh your sentence against the attacker's sentence, and nothing in its architecture guarantees yours wins. It helps at the margin, which is why OWASP lists it, but it is a preference rather than a boundary.
Does this mean I shouldn't use AI assistants?
No. It means the sensible question is what the assistant can reach. An assistant that drafts text and has no tools has a small blast radius. One that can send email, move money or execute code on your behalf needs real permission boundaries and human approval on consequential actions. Match the containment to what a successful injection would let it do.
How do I know if a product is actually protected?
You can't verify it fully from outside, but the language is a reliable filter. Both NIST and the NCSC advise treating claims of prevention as a warning sign — NIST says be wary of anyone claiming otherwise, the NCSC says beware anyone claiming they can "stop" it. Vendors who describe how they reduce risk, where their deterministic limits sit, and what an attacker could reach at worst are describing a real design.
Is this risk getting worse?
The vulnerability has not changed; the exposure has. Connecting models to tools, inboxes, browsers and payment systems turns a wrong answer into a wrong action taken with your credentials. NIST's 2025 edition of its adversarial machine learning taxonomy added coverage of agent security for exactly this reason. The direction of travel is more capability, which means more to contain.
Sources
- LLM01:2025 Prompt Injection — OWASP Top 10 for LLM Applications
- Prompt injection is not SQL injection (it may be worse) — UK National Cyber Security Centre, 8 December 2025
- NIST Identifies Types of Cyberattacks That Manipulate Behavior of AI Systems — National Institute of Standards and Technology
- Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations (NIST AI 100-2) — NIST, 2025 edition
- CVE-2025-32711 — National Vulnerability Database
- Mistaking AI vulnerability could lead to large-scale breaches, NCSC warns — UK NCSC
