Prompt injection is not SQL injection: the NCSC design lesson
The NCSC blog says prompt injection is not SQL injection: current large language models do not separate instructions from data, and the risk may never be fully removed the way parameterized queries remove SQL injection (https://www.ncsc.gov.uk/blog-post/prompt-injection-is-not-sql-injection). The NCSC news warns that the comparison is dangerous and challenges claims that the issue can be stopped (https://www.ncsc.gov.uk/news/mistaking-ai-vulnerability-could-lead-to-large-scale-breaches). Design lesson only. Not an attack guide and not legal advice.
Der Artikeltext ist in dieser Sprache nicht verfügbar; es wird Englisch angezeigt.
2026-10-09. This is a design lesson for engineers, drawn only from two NCSC pages. It is not an attack guide, not a recovery promise, and not legal advice. The NCSC blog, published 8 December 2025, is https://www.ncsc.gov.uk/blog-post/prompt-injection-is-not-sql-injection. The NCSC news item, published 10 December 2025, is https://www.ncsc.gov.uk/news/mistaking-ai-vulnerability-could-lead-to-large-scale-breaches. Those pages give no count of incidents, no loss figure, and no rate. This article adds none.
The NCSC blog describes prompt injection as the case where developers concatenate their own instructions with untrusted content in one prompt, then treat the model’s response as if a robust boundary separated what the application asked for from that untrusted content. It says current large language models do not enforce a security boundary between instructions and data inside a prompt.
## Why the SQL comparison misleads
The NCSC blog says comparing prompt injection with SQL injection is dangerous. In SQL, parameterized queries can keep supplied input from being treated as an instruction. Under an LLM, the blog says, there is no inherent distinction between data and instructions: the model is predicting the next token from the text so far. Because of that, the blog says prompt injection may never be totally mitigated in the way SQL injection can be.
The same blog lists research that tries to detect injection attempts, to train a model to prefer the application’s instructions, or to highlight which span is data. It presents those as overlays on a system that does not itself separate instructions from data. This article does not describe how to build those overlays.
## An inherently confusable deputy
The NCSC blog asks readers to treat the problem as exploitation of an inherently confusable deputy, not as a single code-injection fix. It says a classical confused deputy can be mitigated, while the risk in a large language model cannot be removed the same way. The useful aim is to reduce likelihood and impact. If the remaining risk is intolerable, the blog says the task may not be a good use case for an LLM.
When a system calls tools or APIs from the model’s output, the NCSC blog says the impact rises to the worst case of giving an untrusted party direct access to those tools or APIs. This article does not describe how to cause that call.
The blog also names an indirect pattern, at a high level only: someone with no direct access to the system writes something that is later processed and treated as an instruction. A document or a message handed to a model can carry that pattern. This article does not give wording to copy.
## Design steps the NCSC aligns to ETSI TS 104 223
The NCSC blog aligns the following steps to ETSI TS 104 223, which it cites as baseline cyber security requirements for AI models and systems. This article does not restate the standard, and it does not add clause numbers or test methods.
Awareness. The blog says developers, security teams, and the people who own the risk need to know that prompt injection remains a residual risk. It cannot be fully removed with a product or an appliance. It has to be risk-managed in design, build, and operation.
Secure design. The blog says the important controls are deterministic safeguards that are not themselves another LLM, and that constrain what the system is allowed to do. It describes a privilege rule: when a model processes information from a party, the privileges available to that processing drop to the privileges of that party. The email illustration in the blog is the same idea: do not give privileged tools to a model that is reading mail from arbitrary external senders.
Make the confusion harder, without treating a filter as a fix. The blog says marking sections of data as separate from instructions can reduce how often a model follows instructions that arrived inside data. It warns that blocking a list of known phrases fails, because the same request can be rephrased in many ways. It also says to beware products that claim they can stop prompt injection, and to look instead at how a control reduces likelihood or impact.
Monitor. The blog says to log enough to see suspicious activity, potentially including the model’s inputs and outputs and the tool or API calls. It treats a failed tool or API call as a possible early signal. This article does not describe how to produce those failures.
## What the NCSC news adds
The NCSC news item of 10 December 2025 summarizes that warning. It says the comparison with SQL injection is a dangerous misunderstanding, that prompt injection may never be totally mitigated the way SQL injection can be, and that large language models do not distinguish instructions from data. It challenges claims that prompt injection can be stopped, and it points designers, builders, and operators toward reducing risk and impact and toward resilience in the AI supply chain. It warns that, without addressing the misconception, websites risk breaches exceeding those from SQL injection in the 2010s. That sentence is the NCSC’s warning. The news page states no count, no loss, and no rate, and this article does not add any.
## What Mithril will and will not do
Mithril will point engineers at the public boundary, and it will not claim to stop prompt injection. The guardrails and firewall page, https://docs.mithril.fund/reference/guardrails-firewall, records that former named firewall versions, assurance rungs, content-screening receipts, and GET /v1/secure are not implemented. The current Worker checks request origin, principal, token scopes, passkey assurance for any token scope other than inference, model team, route configuration, and credit before metered inference. Those gates do not prove prompt screening or a complete acceptable-use control. Content moderation, refusal auditing, and provider handling need a measured, dated verification before inference is advertised as guarded. This article does not record that verification.
System One Coding, https://docs.mithril.fund/system-one-coding, is the public description of a staged coding harness and a registered free pilot at https://code.mithril.fund/. That page does not say the harness detects prompt injection or drops privileges around a model. This article does not copy any performance figure from it.
Hosted DAST and SAST are Planned: the security-services page lists them as gated and not available yet. Mithril does not investigate an incident, recover money, or give legal advice. More engineer-facing notes are at https://blog.mithril.fund/for/engineers.