Prompt Injection Is the New SQL Injection, With No Prepared Statement

Twelve published defences against prompt injection reported near-zero attack success rates. When a research team including Nicholas Carlini and Florian Tramèr attacked those defences adaptively in October 2025, most broke above 90%. Prompt injection is the SQL injection of the agent era in one respect: it is the defining vulnerability class of its decade. In every other respect the comparison should worry you, because SQL injection got a real fix and this does not have one.

The SQL injection comparison, tested

Both bugs have the same shape. A system receives a single stream that mixes trusted instructions with untrusted content. The system cannot tell the two apart. An attacker writes content that reads as instruction, and the system obeys.

That is not a loose metaphor. It is the formal classification. When MITRE recorded the Microsoft 365 Copilot flaw disclosed in June 2025, it filed it as CWE-74, improper neutralisation of special elements. That is the same parent weakness family that holds SQL injection.

The comparison is exact in one place

Neither bug lives in your application code. The confusion happens after your code hands the input to an interpreter, so no amount of care in your own functions removes it.

The trust boundary fails identically too. Your agent runs with your credentials. The attacker never touches your infrastructure. They leave text somewhere your agent will read it, and your agent does the work for them.

The industry has ranked this accordingly. OWASP has placed prompt injection first in its LLM Top 10 for three consecutive editions, most recently on 4 August 2026. The 2026 ranking gives 75% of the weight to a practitioner vote and 25% to 6,639 recorded incidents.

It breaks in the place that decides everything

SQL injection was not mitigated. It was fixed. A parameterised query sends the statement template and the values over separate channels, and the parser never sees user data as syntax. Get the pattern right and the class of bug is gone from that call site permanently.

That fix exists because SQL has a formal grammar and a parser that can be told exactly where the code stops and the data starts. A language model has no such component. Instructions and content arrive as one token sequence and pass through the same weights.

Meta's security team stated the position plainly on 31 October 2025, describing prompt injection as a fundamental and unsolved weakness in all large language models. That is a model provider writing about its own products, which is the kind of source worth more than a vendor benchmark.

Why there is no parameterised query for a prompt

The obvious idea is to mark the untrusted part. Wrap retrieved content in delimiters, tag it, and instruct the model that everything inside the tags is data rather than command.

Every version of that idea is a request the model can decline. A delimiter here is not enforced by a parser. It is a pattern the model has learned to usually respect, and usually is doing a lot of work in that sentence.

The measured consequence is the headline number in this post. In a paper submitted on 10 October 2025, researchers took 12 recent defences, most of which had reported near-zero attack success, and attacked each one with methods designed against its specific design. Gradient descent, reinforcement learning, random search and human-guided exploration. Most defences ended above 90% attack success.

The gap between those two numbers is not a scandal about any single defence. It is a statement about how the field reports results. A defence tested against a fixed list of known attack strings is measuring memory, not resilience.

I would treat any prompt injection benchmark result that does not describe an adaptive attacker as marketing. If a vendor cannot tell you what the attacker was allowed to know about the defence, the percentage is not a security claim.

Google's own researchers reached a similar place from the inside. Their May 2025 paper on defending Gemini against indirect prompt injections reports that automated attack techniques succeeded broadly against an earlier model version. Gemini 2.5, hardened through adversarial training, still failed in some realistic scenarios.

The attack patterns that reached production

None of the three patterns below is a laboratory construction. Each has a CVE record or a published disclosure attached to a shipping product.

Zero click, through the inbox

EchoLeak, recorded as CVE-2025-32711 and published on 11 June 2025, affected Microsoft 365 Copilot. An attacker sends an ordinary looking email carrying instructions hidden in HTML comments or white text. The recipient never has to open it. Copilot ingests the message during normal retrieval, then reads internal content and sends it outward.

Two details are worth keeping. The severity scoring disagreed: NIST assessed it at 7.5 and Microsoft at 9.3, which tells you the industry has not settled how to price this class of bug. And the user did nothing at all. The retrieval layer was the attack surface.

The coding agent that runs your shell

Cursor disclosed CVE-2026-22708 in July 2026, fixed in version 2.3. In auto-run mode with an allowlist enabled, certain shell built-ins including export executed without appearing in the allowlist and without user approval.

The consequence is specific. Injected text in a repository file could set PATH or LD_PRELOAD. A later allowlisted command such as git or npm then resolved to an attacker-controlled binary. The allowlist was the control, and the injection walked underneath it rather than through it. That is the same failure mode as a validated input reaching an unvalidated code path, and it lands where coding agents already struggle with real repositories.

Poisoned memory outlives the session

OWASP's agentic risk list carries memory and context poisoning as its own category. The description is persistent corruption of the context window or long-term memory, influencing decisions after the original session ends, and capable of spreading between cooperating agents.

This pattern has no SQL analogue whatsoever. A poisoned prepared statement does not persist into next Tuesday. An agent that wrote a false fact into its own memory store will keep acting on it until something notices. That is an argument for treating agent behaviour in production as a monitored signal rather than a launch checklist item.

What the defence numbers actually say

Put the published evidence in one place and a pattern appears. The approaches that operate on text report the largest gaps between claimed and measured performance. The approaches that operate on capability report smaller wins and admit their costs.

These rows are not directly comparable. Different benchmarks, threat models and task sets. The column that travels across all of them is the last one, where every honest result names a residual failure rate or a utility cost.

What a public attack challenge showed

Microsoft ran LLMail-Inject from December 2024 to February 2025 as an official competition of the third IEEE conference on Secure and Trustworthy Machine Learning. Entrants adaptively injected instructions into emails to trigger unauthorised tool calls in a simulated assistant.

The output was a released dataset of 208,095 unique attacks, deduplicated from 370,724 raw submissions in phase one and 90,916 in phase two. The prize pool was $10,000.

Read that as a supply statistic rather than a security result. Ten thousand dollars and six weeks produced roughly two hundred thousand distinct attacks against one simulated inbox. Now price the effort available to someone attacking a system that moves money.

The defences that hold are architectural

Every mitigation in the table above except the last operates on text. It inspects, rewrites or reinforces language, and language is the medium the attacker controls. The approaches with the better record operate on capability instead.

The framing that made this legible is Simon Willison's lethal trifecta: access to private data, exposure to untrusted content, and the ability to communicate externally. An agent holding all three can be converted into a data exfiltration tool by a single injected instruction, regardless of how good its filters are.

CaMeL, published by DeepMind researchers in March 2025 and revised that June, is the engineering version of the same insight. It extracts control flow and data flow from the trusted query, so retrieved untrusted data can never influence the program's path, and applies capability-based access control to tool calls. On AgentDojo it solved 77% of tasks with provable security, against 84% for an undefended agent.

That 7 point utility gap is the most honest number in this field. Any vendor claiming protection at zero cost to capability is either not measuring utility or not measuring attacks. The gap is the product decision, and it belongs to you rather than to your security reviewer.

The rule of two, stated plainly

Meta published the operational form on 31 October 2025. An agent should satisfy no more than two of three properties inside a single session: processing untrustworthy input, holding access to sensitive systems or private data, and being able to change state or communicate externally.

Meta is equally clear about what the rule does not cover. It is not sufficient against other agent threats such as excessive privilege or plain model error, and it does not address lower-consequence outcomes like a wrong answer. It is a blast radius control, not a correctness control.

The practical move is to pick the leg you cut before you build the feature, not after the penetration test. Tool exposure through the MCP interoperability layer makes that choice easier to defer and more expensive to reverse, because every added server widens the third property quietly.

Where this argument is weakest

Two things in this post deserve a harder look than the rest, and both cut against the urgency of the framing.

The incident record is genuinely thin

OWASP says so itself. If the 2026 ranking had been built on recorded incidents alone, prompt injection would not have appeared in the top ten at all. The stated explanation is a defence effect: teams fight injection hard, so fewer clean exploits reach a public database, and the public count understates what mature teams already spend holding it off.

That explanation is plausible and it is not proof. An equally consistent reading is that the attack is currently more interesting to researchers than to criminals, because a stolen credential still pays better than a coaxed agent. The published record is overwhelmingly disclosure research and competition data, not attributed criminal campaigns.

You will find numbers circulating in 2026 claiming triple-digit percentage growth in prompt injection attacks. Every one I traced ended at a vendor blog rather than at a named incident database, so this post uses none of them. That absence is the finding, and it is why the argument here rests on capability rather than on frequency.

Cutting a leg off costs real product value

The rule of two is easy to state and expensive to obey. The agent worth paying for is usually the one that reads your inbox and then does something about it, which is all three properties by definition.

CaMeL's 7 point utility gap is the measured version of that cost, and it was measured on a benchmark rather than on your customers. Your gap could be smaller. It could also be the difference between a feature people use and one they abandon, which is a failure mode agent pilots already hit for less interesting reasons.

The counter-case is fair. For many internal uses the residual risk is acceptable and the productivity gain is real. A read-only assistant over a document store with no egress path is close to harmless, and it is also considerably less useful than the thing your team actually asked for.

What to ask before you switch an agent on

The questions below are answerable. That is the point of them. Each has a form of answer that means something and a form that means the vendor has not done the work.

The fourth row is the one buyers skip and later regret. An agent acting under a human's session inherits that human's entire permission set. That is exactly the condition that turns a text bug into a breach, and it is why non-human identity has become its own governance problem. The sixth row belongs in procurement rather than security review, alongside the rest of the liability caps and remedies your agent contracts already need.

One caveat on all six. OWASP's June 2026 report found that only 37% of organisations had a policy for detecting shadow AI. You cannot ask any of these questions about an agent nobody told you existed, which makes discovery the prior step and gives unsanctioned AI use a cost you can actually estimate.

Frequently asked questions

Where to start this week

Open a spreadsheet and list every agent your company runs, including the ones a team stood up without asking. For each one, write three columns: does it read untrusted content, does it hold private data, can it act outward. Any row with three marks is your working backlog, ranked by how much data sits behind the second column.

Then take the single riskiest row and cut one property this quarter. Not all three, and not with a filter. Remove a tool, drop it to a logged-out session, or put a human between the proposal and the execution. You will lose something real, and you will know exactly what you lost, which is more than a classifier can tell you.

Related reading