In December 2025 the UK National Cyber Security Centre argued that prompt injection is not like SQL injection and may never be fully solved. Its advice: assume the model can be manipulated, limit what it can do with deterministic controls, make attacks harder, and monitor tool use. If the residual risk is unacceptable, an LLM may be the wrong tool.
The core difference
SQL injection has a proper fix. Parameterised queries keep data and commands apart, so the database never executes input as a command.
Language models have no such separation. The NCSC blog post, written by Dave Chismon, puts it plainly: to the model there is only ever "next token". Instructions and data arrive as one stream of text. The post calls the result an "inherently confusable deputy".
That framing matters. A confused deputy is a program that has authority and can be tricked into using it for someone else. An agent with tools is exactly that.
The four recommendations
1. Awareness. Developers and risk owners should understand prompt injection and treat it as a residual risk that products cannot fully remove. It needs ongoing risk management, not a one-off fix.
2. Secure design. Assume the model can be manipulated, especially when its output drives tools or APIs. Use deterministic, non-LLM controls to bound what the system can do. The post cites a principle from Simon Willison: when an LLM processes input from a party, its privileges drop to the level of that party. An agent reading external email should not hold privileged tools.
3. Make it harder. Mark data separately from instructions, for example by wrapping external content in tags. But do not rely on deny lists of attack phrases, because attackers rephrase. Be sceptical of any product that claims it can stop prompt injection.
4. Monitor. Log inputs, outputs, tool use and API calls. Failed tool calls can be an early sign of an attack in progress.
What to do on Monday
- For each agent, write down whose text it reads and which tools it can call. If a low-trust party's text can reach a high-privilege tool, change the design.
- Move limits out of the prompt and into code: allowlists, scoped tokens, rate limits, approvals.
- Turn on tool call logging and review failures weekly.
- Ask vendors what they claim and how they test it. Treat "blocks all prompt injection" as a red flag.
When to say no to an LLM
The NCSC notes that if a system cannot tolerate the residual risk, it may be a poor fit for an LLM at all. That is a legitimate outcome of a risk assessment. A payment approval flow with no human check is a candidate.
Where Safeguard fits
Safeguard's MCP Guardrail, policies and gates are non-LLM controls on tool use, and agent identity lets you scope what each agent may do and review what it called.
Quick check
Can a good system prompt stop prompt injection?
No. The NCSC advises against relying on prompt level tricks alone and recommends deterministic controls outside the model.
Does tagging external content as data fix it?
It makes attacks harder but does not remove the risk, because the model still reads everything as text.
Sources
Last reviewed: 19 October 2026.
