Why the most reassuring comparison in AI security is also the most dangerous one, and what boards should do about it
The comfort of a familiar name
When Simon Willison coined the term “prompt injection” in September 2022, he named it deliberately after SQL injection, because the underlying pathology looked identical: trusted instructions and untrusted content being mixed in a single channel, with no reliable boundary between them. It was a good name. It was also, in retrospect, an act of unintentional sedation.
Names carry inherited assumptions. Tell a seasoned application security professional that a vulnerability is “a kind of injection” and a whole solution architecture arrives unbidden: sanitise the input, escape the output, parameterise the query, add a rule to the WAF, close the ticket, move on. That reflex is precisely what the UK’s National Cyber Security Centre set out to interrupt in December 2025, in a blog post whose title does not equivocate: Prompt injection is not SQL injection (it may be worse). The NCSC’s argument is that the comparison is not merely imprecise but actively hazardous, because it leads organisations to reach for mitigations that cannot work, and then to believe they are protected.
Willison himself has watched the term drift. He now spends a good deal of energy distinguishing prompt injection, which is an application architecture problem, from jailbreaking, which is a model behaviour problem, because developers who conflate the two conclude that the risk belongs to the model vendor rather than to them.
So: is prompt injection the AI equivalent of SQL injection, or is it worse? The short answer is that it is worse in three specific and independently serious ways. The longer and more useful answer is that “worse” is the wrong axis altogether. It is a different category of problem, and the strategic error is not underestimating its severity but misclassifying its type.
Why SQL injection was, eventually, winnable
It is worth being precise about why the industry beat SQL injection, because the mechanism of that victory is exactly what is unavailable to us now.
SQL injection was defeated by a categorical fix. In a relational database, instructions are things the engine does and data is something the engine stores or uses. That distinction is real, structural, and enforceable at the interface. Parameterised queries exploit it: whatever a user types into the field, the engine cannot construe it as a command. The same logic underwrites the mitigations for cross-site scripting and, at the hardware level, for memory corruption, where ARM’s Memory Tagging Extension enforces the purpose of a region of memory rather than hoping developers get it right.
Crucially, the fix was class-level. Once the pattern was understood, it could be embedded into libraries, ORMs, frameworks and defaults, so that the average developer received the protection without understanding it. The security of the median application improved because the median application stopped hand-rolling its queries. As the NCSC notes, SQL injection was described in the late 1990s, peaked around 2010 when SQL had become ubiquitous but secure defaults had not, and then declined over roughly a decade as those defaults spread. It cost the industry a great many breaches to learn the lesson, but the lesson terminated in a fix.
Hold that shape in mind: a real distinction, enforceable at a boundary, encodable in a library, deployable by default.
Why prompt injection is not winnable in the same manner
Now consider what happens inside a large language model. There is no instruction plane and no data plane. There is a single token stream, and the model’s entire function is to predict what comes next. The system prompt, the user’s request, the retrieved document, the tool output and the attacker’s payload occupy the same undifferentiated sequence. There is no privileged register in which “these are your orders” can be written such that “and here is some text to consider” cannot reach it.
Every current defence is therefore an attempt to paint a distinction onto a substrate that does not possess one. Delimiters and spotlighting mark data sections and hope the model respects the marking. Instruction hierarchies train the model to prefer one region of context over another. Classifiers try to spot injections before they arrive. Adversarial fine-tuning reduces compliance rates. All of these are statistical overlays on an architecture that is, in the NCSC’s phrase, “inherently confusable”. A classical confused deputy vulnerability can be patched. This one, the NCSC argues, cannot be, because the confusion is constitutive rather than incidental.
Bruce Schneier has made the same point from the other direction: the property that makes these systems useful, namely that they treat all input uniformly and let data reshape behaviour, is the property that makes them exploitable. Writing with Barath Raghavan in IEEE Spectrum in January 2026, he argues that prompt injection is unlikely ever to be fully solved within current architectures, because the code and data separation that tamed SQL injection simply has no analogue inside the model. Recent interpretability work reinforces this uncomfortably: role tags such as system, user and tool, which the entire industry treats as security boundaries, appear to be represented internally as something closer to stylistic signals than as hard partitions.
The empirical record is consistent with the theory, and it is bleak. In October 2025, researchers from OpenAI, Anthropic and Google DeepMind published The Attacker Moves Second, which subjected twelve published defences to genuinely adaptive attackers using gradient descent, reinforcement learning, search and human red teaming. Most were bypassed with attack success rates above ninety per cent, and the majority had originally reported success rates near zero. Defences that scored around one per cent against AgentDojo’s static attack set collapsed above ninety-five per cent under adaptive search. Human red teams achieved universal success. The International AI Safety Report 2026 found that sophisticated attackers defeat even the best-defended models roughly half the time within ten attempts.
Willison’s framing of this asymmetry is the one to carry into a board meeting: if we had defended SQL injection with a mechanism that failed one time in a hundred, every bank account would have been drained. Security controls that work statistically are not security controls. They are friction. Friction has value, but it should not be booked as protection.
The second escalation: blast radius
Even if the failure rate were tolerable, the consequences would not be, because the thing being confused is no longer a text generator. It is an actor with credentials.
An LLM that can only produce prose has a bounded worst case. An agent that can read your mailbox, query your data warehouse, call internal APIs, execute shell commands, commit code and initiate payments has a worst case equal to, in the NCSC’s blunt formulation, whatever an attacker could achieve with direct access to those same tools. Prompt injection stops being an information disclosure issue and becomes remote code execution by social engineering, where the party being socially engineered is your own infrastructure.
Willison’s “lethal trifecta” is the cleanest diagnostic available: access to private data, exposure to untrusted content, and the ability to communicate externally. Any two are survivable. All three in one session, and an attacker who controls the untrusted content controls the outcome. Meta’s Agents Rule of Two, published in October 2025, formalises this into deployment policy: an agent should hold at most two of the three legs per session, and a human should be in the loop if it truly requires all three.
The incident record has caught up with the theory. EchoLeak (CVE-2025-32711, CVSS 9.3) demonstrated zero-click exfiltration from Microsoft 365 Copilot: an attacker sent an email, the victim later asked Copilot to summarise the inbox, and internal content flowed outward with no user interaction and no visible signal. Comparable severities followed in developer tooling, including GitHub Copilot and Cursor, and in agent frameworks where model output was permitted to influence sandbox configuration, which is the same error one layer down.
The move from proof of concept to production is now measurable. In April 2026, Google reported a thirty-two per cent relative increase in malicious indirect injection content across successive crawls of the public web between November 2025 and February 2026. Forcepoint’s X-Labs identified live payloads in the wild. Palo Alto’s Unit 42 catalogued twenty-two distinct payload delivery techniques in active use, with documented objectives including forced payment transfers, subscription fraud, recursive file deletion in IDE-integrated agents, credential exfiltration and biased recruitment screening. Unit 42 is careful to note that observed activity remains more opportunistic than the worst laboratory demonstrations, which is true and worth holding onto, though it describes the current state of attacker tooling rather than a ceiling.
Two further properties compound the exposure. Memory poisoning makes the compromise persistent: an injection that corrupts an agent’s long-term store survives the session, so the agent carries false beliefs about policy or configuration into future work. And the disclosure pipeline is incomplete, with several bug bounties paid for prompt injection flaws in major agent products producing no CVE and no public advisory, leaving downstream adopters without the tracking artefacts their vulnerability management processes assume exist.
The third escalation: you do not own the defect
This is the difference that most changes the governance conversation, and it is the one least often articulated.
With SQL injection, the flaw lived in your code. You could find it, own it, fix it, and prove the fix with a deterministic test that would fail loudly if someone regressed it. Remediation was an engineering task with an end state.
With prompt injection, the flaw lives in a statistical artefact you licensed from a third party and cannot inspect, modify or reason about formally. You cannot patch a transformer’s inability to distinguish instruction from data. You can only build around it. Worse, the system is non-deterministic, so absence of evidence in testing is unusually weak evidence of absence: the same payload may fail nine times and succeed on the tenth, and a model version upgrade can silently re-open a hole you believed closed. Testing regimes built for deterministic software produce false confidence when applied to this class of system.
The consequence for risk management is structural rather than tactical. Prompt injection is a permanent residual risk, not a defect awaiting closure. It cannot be transferred to a product, an appliance or a managed service, whatever the vendor’s marketing suggests. The NCSC’s procurement advice is the most quietly useful sentence in its blog: be wary of anyone claiming to stop prompt injection, and prefer suppliers who can explain precisely how much they reduce it and at what cost to utility.
Where the analogy still earns its keep
Intellectual honesty requires the counter-case, and it is stronger than the pessimistic framing suggests.
The lesson of parameterised queries was never “sanitise harder”. It was “separate the planes and enforce the separation at a boundary the attacker cannot reach”. That lesson transfers perfectly. It simply has to be applied outside the model rather than inside it.
This is exactly what Google DeepMind and ETH Zurich’s CaMeL demonstrates. A privileged model plans from the trusted user query and never sees untrusted content; a quarantined model processes untrusted content and holds no tools; a custom interpreter tracks provenance and enforces capability-based policy before any tool call executes. It resolved seventy-seven per cent of AgentDojo tasks with provable security guarantees, against eighty-four per cent for an undefended system. That is a real security property with a modest and quantifiable utility cost, achieved without asking the model to be trustworthy. Schneier’s assessment was that this represents proper security engineering: treat the model as an untrusted component and construct boundaries that hold even when it is fully compromised.
The follow-up work, Design Patterns for Securing LLM Agents against Prompt Injections, generalises this into six reusable architectures: action selector, plan then execute, LLM map reduce, dual LLM, code then execute, and context minimisation. Each imposes structural constraints and each trades flexibility for containment. The authors are candid about the limit of the approach: as long as agents and their defences rely on the current class of models, general-purpose agents are unlikely to offer meaningful safety guarantees. Narrow, well-scoped agents can.
There is also a chronological consolation. SQL injection took something like fifteen years to move from understood to rare, and it is not extinct. The security industry is roughly four years into prompt injection and already possesses a credible architectural response. What it lacks is the framework-level default that made SQL safety free for the median developer.
What this means strategically
The practical implications separate cleanly into five moves, none of which are principally technical.
Reclassify the risk. Prompt injection is not a vulnerability to be remediated. It is a hazard to be engineered around, closer in character to fire safety or process safety in heavy industry than to a patch cycle. Fire safety does not attempt to prevent every ignition; it compartmentalises, detects, suppresses and limits loss. Risk registers that carry prompt injection as an open finding with a target closure date are miscategorising it, and that miscategorisation will eventually be visible to a regulator.
Adopt a privilege rule and enforce it architecturally. The most portable heuristic in circulation, which the NCSC endorses, emerged from a public exchange between Simon Willison and Baibhav Bista: when a model processes content from a party, its privileges should drop to those of that party. An agent reading unsolicited external email should hold roughly the authority you would grant an anonymous stranger, which is to say almost none. This is a design rule, not a prompt instruction, and it should be enforced by deterministic code at the tool boundary.
Treat agents as insider risk, not as software components. Several practitioners have converged on this framing and it is analytically sound: agents are adaptive, manipulable, credentialed and capable of independent action. The governance apparatus that fits them is the one built for privileged staff, comprising least privilege, segregation of duties, approval thresholds for consequential actions, comprehensive logging of inputs, outputs and tool calls, and behavioural monitoring for anomaly. It is not the apparatus built for libraries.
Test adaptively or do not claim to have tested. Static benchmark results are close to worthless as assurance, given that most published defences reported near-zero attack success rates before adaptive attackers reduced them to rubble. Red teaming must be iterative, resourced and adversarial, and vendor claims should be discounted to the level of the adaptive evidence supporting them.
Accept that some use cases fail the test. This is the strategic point that most organisations avoid. The NCSC states it plainly: if a system’s security cannot tolerate the residual risk, it may not be an appropriate use case for a language model at all. Portfolio discipline of this kind is uncomfortable in an environment of competitive AI adoption pressure, but the alternative is discovering the constraint through an incident.
The regulatory clock adds urgency without adding clarity. The EU AI Act’s Digital Omnibus, agreed politically in May 2026 and signed in July, defers stand-alone Annex III high-risk obligations to 2 December 2027 and embedded Annex I systems to 2 August 2028, while leaving the Article 50 transparency duties and the Article 4 AI literacy duty on their original August 2026 timing. That deferral is runway rather than reprieve, and Article 15’s requirement that high-risk systems be resilient to adversarial manipulation across their action layer is precisely the obligation that prompt injection makes difficult to satisfy honestly. Meanwhile the Five Eyes agencies issued a joint statement on 22 June 2026 addressed explicitly to boards rather than to security teams, warning that the relevant timeline for AI-driven change in cyber risk is measured in months rather than years, and pressing leaders to demand secure-by-design and secure-by-default as non-negotiable.
The answer, and the better question
Is prompt injection worse than SQL injection? Yes, on three counts. It cannot be fixed at the root within current model architectures. Its blast radius scales with agency, which is currently scaling faster than any control. And the defect belongs to a supplier’s statistical artefact rather than to your codebase, which means it can never be closed, only contained.
But the more useful question is not comparative severity. It is whether an organisation has understood that it is dealing with a hazard rather than a bug, and has therefore reorganised its architecture, its assurance and its governance around containment instead of prevention.
The firms that will deploy agents most aggressively over the next two years will not be the ones with the highest risk appetite. They will be the ones whose containment architecture is good enough that aggression is affordable. Security here is not a brake on the agentic programme. It is the precondition for having one at scale, and it is one of the few genuinely defensible advantages available while everyone else is still writing “mitigate prompt injection” in a risk register and hoping a vendor turns up with a parameterised query.
Sources
Primary and authoritative
- NCSC, Prompt injection is not SQL injection (it may be worse), 8 December 2025: https://www.ncsc.gov.uk/blog-post/prompt-injection-is-not-sql-injection
- NCSC press release, Mistaking AI vulnerability could lead to large-scale breaches: https://www.ncsc.gov.uk/news/mistaking-ai-vulnerability-could-lead-to-large-scale-breaches
- Five Eyes cyber security agencies, The AI shift in cyber risk: why leaders must act now, 22 June 2026: https://www.ncsc.gov.uk/news/the-ai-shift-in-cyber-risk-why-leaders-must-act-now
- ETSI TS 104 223, Baseline Cyber Security Requirements for AI Models and Systems: https://www.etsi.org/deliver/etsi_ts/104200_104299/104223/01.01.01_60/ts_104223v010101p.pdf
- OWASP Top 10 for Large Language Model Applications: https://owasp.org/www-project-top-10-for-large-language-model-applications/
Research
- Debenedetti et al., Defeating Prompt Injections by Design (CaMeL), SaTML 2026: https://arxiv.org/abs/2503.18813
- Beurer-Kellner et al., Design Patterns for Securing LLM Agents against Prompt Injections, 2025: https://arxiv.org/abs/2506.08837
- Nasr et al., The Attacker Moves Second: Stronger Adaptive Attacks Bypass Defenses Against LLM Jailbreaks and Prompt Injections, 2025: https://arxiv.org/abs/2510.09023
- Prompt Injection Attacks in Large Language Models and AI Agent Systems: A Comprehensive Review, Information 17(1) 54, January 2026: https://www.mdpi.com/2078-2489/17/1/54
- Aim Labs, EchoLeak analysis (CVE-2025-32711), academic write-up: https://arxiv.org/pdf/2509.10540
Commentary and framing
- Simon Willison, The lethal trifecta for AI agents, June 2025: https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/
- Simon Willison, New prompt injection papers: Agents Rule of Two and The Attacker Moves Second, November 2025: https://simonwillison.net/2025/Nov/2/new-prompt-injection-papers/
- Simon Willison, CaMeL offers a promising new direction, April 2025: https://simonwillison.net/2025/Apr/11/camel/
- Bruce Schneier and Barath Raghavan, Why AI Keeps Falling for Prompt Injection Attacks, IEEE Spectrum, 21 January 2026: https://spectrum.ieee.org/prompt-injection-attack
- Bruce Schneier, LLMs’ Data-Control Path Insecurity: https://www.schneier.com/blog/archives/2024/05/llms-data-control-path-insecurity.html
- Bruce Schneier, Applying Security Engineering to Prompt Injection Security: https://www.schneier.com/blog/archives/2025/04/applying-security-engineering-to-prompt-injection-security.html
Threat intelligence and in-the-wild data
- Unit 42, Palo Alto Networks, Fooling AI Agents: Web-Based Indirect Prompt Injection Observed in the Wild, March 2026: https://unit42.paloaltonetworks.com/ai-agent-prompt-injection/
- Help Net Security, Indirect prompt injection is taking hold in the wild (Google and Forcepoint findings), 24 April 2026: https://www.helpnetsecurity.com/2026/04/24/indirect-prompt-injection-in-the-wild/
- Cloud Security Alliance, Indirect Prompt Injection in the Wild, May 2026: https://labs.cloudsecurityalliance.org/research/csa-research-note-indirect-prompt-injection-in-the-wild-2026/
Regulatory
- Gibson Dunn, EU AI Act Omnibus Agreement: Postponed High-Risk Deadlines and Other Key Changes: https://www.gibsondunn.com/eu-ai-act-omnibus-agreement-postponed-high-risk-deadlines-and-other-key-changes/
- Freshfields, EU AI Act unpacked #34: The final Digital Omnibus on AI: https://www.freshfields.com/en/our-thinking/blogs/technology-quotient/eu-ai-act-unpacked-34-the-final-digital-omnibus-on-ai-key-amendments-to-the-a-102nber
Note on currency: regulatory positions were accurate at the time of writing in late July 2026. The Digital Omnibus was signed on 8 July 2026 and its revised deadlines take legal effect on publication in the Official Journal, so verify status before relying on the dates.
