Security teams often describe prompt injection, an attack on AI systems, as “the new SQL injection.” The UK’s National Cyber Security Centre (NCSC) argues that the comparison is misleading, and that the difference changes how any business using AI should design its systems.
What is prompt injection in plain terms?
A large language model (LLM) is the kind of AI behind modern chatbots and writing assistants. Applications built on one usually assemble a single block of text, called a prompt, that mixes the developer’s instructions with other material: a customer’s question, an uploaded document, a web page, an email.
Prompt injection happens when that other material contains instructions the attacker wrote, and the model follows them. According to the NCSC’s December 2025 blog post, the problem arises when developers combine their own instructions with untrusted content in one prompt and then trust the output as though the two had been kept apart. The NCSC notes the term was coined in 2022.
There are two flavors worth separating:
- Direct injection: the person typing into the system tries to override its rules.
- Indirect injection: an attacker who has no access to the AI system plants content that the system later reads and treats as an instruction.
The NCSC gives a hiring example of the indirect kind. A recruiter’s AI tool screens applications, and a candidate hides text in a CV telling the model to approve the application. The recruiter never sees the text, but the model reads it.
Why does the SQL injection comparison feel natural?
SQL injection is a decades-old flaw in which a database mistakes data for a command. A web form that expects a name receives database commands instead, and the database runs them. The NCSC describes it as a flaw around 30 years old, which peaked around 2010 and was followed by a decade of breaches before better defaults became standard.
The parallel is easy to see. In both cases, text supplied by an outsider ends up being treated as an instruction. That is why many security teams reached for the SQL analogy when prompt injection first appeared.
Why is the comparison misleading?
The key difference is that SQL injection has a root-cause fix. Parameterized queries keep the command and the data in separate channels, so the database never interprets user input as an instruction. Done properly, the whole category of attack goes away.
The NCSC’s point is that current LLMs have no such boundary. Inside the model there is no built-in distinction between “instruction” and “data”; it processes everything as text and predicts what should come next. The NCSC’s technical team calls this the root issue and concludes that prompt injection may never be fully mitigated in the way SQL injection can be.
In its accompanying news release of December 10, 2025, the NCSC called the misunderstanding “dangerous” and warned that, if it persists, websites could suffer data breaches larger than the SQL injection breaches of the 2010s. It also rejected claims that prompt injection can be “stopped.”
| SQL injection | Prompt injection | |
|---|---|---|
| Root cause | Data executed as a command | Instructions and data mixed in one prompt |
| Structural fix | Parameterized queries | None known; model has no enforced boundary |
| Realistic goal | Eliminate the flaw | Reduce likelihood and impact |
| Treat the component as | A parser to be fed safe input | An “inherently confusable deputy” |
What does “confusable deputy” mean?
The NCSC borrows from an older security idea, the confused deputy. A deputy is a component with legitimate privileges, such as permission to send email or read files. A confused deputy is tricked into using those privileges on behalf of someone who lacks them.
The NCSC suggests thinking of an LLM as an “inherently confusable deputy.” The word “inherently” matters: the weakness is not a bug awaiting a patch but a property of how the technology works. The practical conclusion is to assume the model can be confused and to limit what a confused model could do.
This framing shifts the question. Instead of asking “can we make the model never fall for it?”, which no one can currently guarantee, teams ask “if it does fall for it, what is the worst outcome?”
How can teams limit the damage?
The NCSC’s post sets out four broad areas. They are consistent with a published European standard for securing AI, ETSI TS 104 223.
Make people aware that residual risk remains
Developers need to know the risk exists, and security teams and risk owners need to accept that some of it will remain. The NCSC says it cannot be bought away with a product or appliance.
Design so a confused model can do little harm
The strongest advice is architectural. Use deterministic safeguards, meaning ordinary code with fixed rules rather than another AI model, to limit the actions a model can take, especially through tools and application programming interfaces (APIs), the connections that let software call other software. The NCSC also describes a principle that an LLM’s privileges should drop to those of the least-trusted party whose content it is processing.
A worked example: an assistant that summarizes inbound customer emails should not also be able to issue refunds. If an email says “refund this order,” the summary tool has no refund permission to misuse.
Make attacks harder, without relying on that
The post says developers can help the model tell content apart, for example by marking external material so it is clearly labeled as data. It cautions against deny-lists, which block known bad phrases, because attackers can simply rephrase. And it advises caution toward any product that claims to stop prompt injection outright.
Monitor what the system does
Log inputs, outputs, tool use and API calls. The NCSC notes that failed tool calls can reveal an attack in progress, because a manipulated model may try actions it was never meant to take.
Where does this fit with wider AI risk practice?
Prompt injection is one concrete risk that general frameworks ask organizations to manage. Readers who want the broader structure can start with this explainer on the NIST AI Risk Management Framework, which organizes AI risk work into governing, mapping, measuring and managing.
The NCSC’s emphasis on limiting privileges also echoes the logic of zero trust security: assume something will be compromised, and design so that one compromise does not unlock everything.
What changes when AI systems take actions?
The risk grows with what the model is allowed to do. A chatbot that only produces text can mislead, but it cannot move money or delete records. Systems that act, as described in AI agents explained, combine reading untrusted content with the ability to use tools. That pairing is exactly where an injected instruction becomes consequential.
A simple review checklist for any AI feature:
- What untrusted content can this system read (emails, web pages, files, tickets)?
- What can it do with tools, data and accounts?
- If an attacker’s instruction were followed, what is the worst result?
- Is there a non-AI control that blocks that result?
- Would we notice, through logs, if it happened?
If the answers to questions 1 and 2 are both “a lot,” the design deserves a second look before launch. Businesses starting out can pair this with the guidance in how businesses can start using AI responsibly.
What the NCSC’s warning means going forward
The NCSC’s message is neither alarmist nor dismissive. Prompt injection is a real class of weakness, it is not solved, and the SQL injection playbook of “fix it once at the root” does not apply. What does apply is older and less glamorous: least privilege, careful design, human approval for consequential actions, and good logging.
For founders and operators, the sensible stance is to treat AI features as components that can be confused, to keep their permissions narrow, and to be skeptical of any vendor promising a complete cure. As the NCSC puts it, the realistic aim is lowering likelihood and impact, and the teams that design for that now will be better placed than those who wait for a silver bullet.
This article provides general information about technology risk and is not legal, security-certification or professional advice for your specific systems.
Sources: UK National Cyber Security Centre
