Three years into the LLM era, prompt injection remains unsolved, and the research consensus has quietly hardened into something more interesting than unsolved. It is unsolvable at the model layer — because it is not a bug.
A language model's core competence is treating text as potentially meaningful instruction. Injection is that competence pointed the wrong way. Every document an agent retrieves, every email it reads, every tool result it ingests is text, and any of it can say ignore your previous instructions.
The model has no channel that marks which text is command and which is data, because the architecture has only one channel. That is the whole vulnerability, and no fine-tune fills a channel that does not exist.
Why the comparison to SQL injection misleads
Practitioners reach for SQL injection as the analogy, and the reach is understandable — the names rhyme, and both involve untrusted content being interpreted as instruction. But the analogy is actively misleading in the one respect that matters, and pursuing it is why people keep expecting a fix.
SQL injection was solved, genuinely and permanently, by parameterised queries. The reason that worked is that the database has two channels available: a query structure and a set of values. The vulnerability existed because programmers were concatenating them into one string; parameterisation stopped the concatenation and let the boundary that already existed do its job. The fix did not make the database better at detecting malicious strings — it removed the need to detect anything.
There is no equivalent move for a transformer, because there is no second channel to route the data into. Attempts to build one — delimiters, special tokens, structured prompt formats — are all expressed in the same sequence the model reads, which means they are themselves content, which means they can be spoofed or reasoned around. The boundary would have to exist below the level at which the model operates, and it does not.
So the correct reading is that we are in the pre-parameterisation era with no parameterisation available. That sounds bleak, and it is the reason the answer has to move outside the model entirely.
Why the standard defences keep failing on schedule
Two defences dominate deployment, both worth having, neither a boundary.
Instruction-hierarchy training teaches the model that system prompts outrank retrieved content. It raises the attacker's effort measurably — the published results on trust-ordering compliance are real and improving. And every red-team study keeps finding paraphrases, encodings and role-plays that slip it, because the defence and the attack are made of the same substance: natural language persuading a language model. There is no asymmetry for the defender to exploit; both sides are playing the same game with the same pieces.
Injection classifiers sit in front and face the same regress in a purer form. A model judging whether text is adversarial is a model that can be persuaded the text is not. You can stack a classifier in front of the classifier, and the regress is infinite because each layer has the same defect as the one before it.
Both layers are worth deploying, and I want to be clear about that rather than dismissive. They catch the unsophisticated majority, and the unsophisticated majority is most of what any system actually faces. They are seatbelts. What they are not is brakes — they change the price of an attack, not whether one is possible, and a control that changes price is a control you cannot write a safety claim against.
The demonstration that ended the debate
EchoLeak (CVE-2025-32711, CVSS 9.3, June 2025) is the case I would put in front of anyone still waiting for a model-layer fix, because of what it does not contain.
A crafted email — never clicked, never even read by the victim — sat in a mailbox until an enterprise copilot's retrieval pipeline ingested it, at which point it instructed the assistant to exfiltrate chat history, OneDrive files, SharePoint and Teams content. Zero user interaction. The retrieval layer delivered the attack to the model itself.
Now walk the chain looking for the broken component. The mail system accepted mail, which is what mail systems do. Retrieval retrieved relevant context, which is the feature. The model followed instructions in its context, which is the capability being paid for. The data left through a destination the system was permitted to reach, which is what permitted means.
Every element was working as designed, and the outcome was still a breach. When that is true, the defect is not in any component — it is in the composition, and no component's patch would have prevented it. That is the signature of an architectural problem, and it is why this incident settled an argument that benchmark results had not.
There is a second lesson in it that gets less attention. The victim's own security behaviour was irrelevant. Every piece of user-directed security advice — do not click, verify the sender, be suspicious of unexpected attachments — had no purchase, because the user never acted. Any defence model that routes through user vigilance was already obsolete when this was disclosed.
What actually holds
If the model cannot distinguish content from instruction, the system around it must — by construction, not persuasion. The design family that survives red-teaming shares one principle, and everything below is a way of realising it.
The component that reads untrusted content must not be the component that holds authority.
Split the planes. CaMeL-style designs make it explicit: a privileged model sees only the trusted task and writes a plan; a quarantined model reads the untrusted content and returns extracted data — never control flow — through a defined interface. The injected email can scream instructions at a component that has no ability to act on any. The interface is the load-bearing part: it must carry typed values rather than anything the receiving side will interpret as direction.
Confine by capability, not by cooperation. The quarantined side runs with no standing authority: no tool access, no egress, nothing to abuse even when — not if — it is successfully persuaded. This is the mental shift that matters most. Security stops depending on the model resisting persuasion, which it will not do reliably, and starts depending on what a persuaded model can reach, which you control absolutely.
Gate at the point of action. Whatever the reasoning path, the action passes a policy check that never read the untrusted content, evaluated against the grant, deterministically. Injection can corrupt the proposal; it cannot corrupt an evaluator that operates outside the language channel. The word deterministically is doing work — a gate implemented as another model inherits the regress described above.
Readers of the governance argument will recognise the shape: these are the entitlement and enforcement layers, arrived at from the security literature instead of the regulatory one. The two disciplines are converging on the same architecture because they are solving the same problem — an actor that cannot be trusted to police its own inputs.
The cost, stated honestly
Architectural answers are easy to advocate and expensive to adopt, so the number matters.
CaMeL reports solving 77 percent of AgentDojo tasks with provable security against the injection class, against 84 percent undefended. Seven points of task success is the measured price of the property, and I think that is the most useful single figure in this literature — not because the exact number transfers, but because it establishes that the trade is bounded and small rather than catastrophic.
Two caveats belong with it. It is one benchmark, and AgentDojo's task distribution is not your task distribution. And provable security against the injection class is a precise claim with a scope: it does not mean the system is secure, it means this class cannot succeed by this route. Other classes remain.
The engineering cost is the larger one and is less often stated. Plane separation means two model calls where you had one, a typed interface to design and maintain, and a real constraint on what the quarantined side can express — which is exactly the constraint that makes some workflows awkward. Teams discover that the awkward workflows are the ones where they wanted the untrusted content to influence control flow, which is the thing the architecture exists to prevent. That discovery is the design working, not failing, but it does not feel that way in the sprint.
The transfer rules
Three, in the order I would apply them.
Treat every retrieved token as adversarial. Your RAG corpus is an unauthenticated input surface — anything that can write into an indexed source can write into your model's context, and in most enterprises the list of people and systems that can do that is far longer than anyone has enumerated. This compounds with the permission argument: content that should never have been retrievable becomes an injection vector as well as a disclosure risk.
Test the path, not the model. Red-team with injected documents placed in the actual retrieval flow, and score what the system did rather than what the model said. A model that produces an alarming completion but cannot act is a different finding from a model that produces a bland completion and exfiltrates — and evaluations that score text miss the distinction entirely.
And put one question in every design review: what can a fully-compromised model reach? Not what will it do, or how likely is this — assume the model is fully persuaded by the attacker and enumerate what remains available to it. If the answer alarms you, the fix is capability, not prompting.
The surface people forget: tool descriptions are content too
Almost every discussion of injection reasons about retrieved documents, because that is where the research started. There is a second surface with identical properties and far less scrutiny.
When an agent connects to a tool server, the server returns descriptions of what each tool does and when to use it. Those descriptions enter the model's context. They are, functionally, system-prompt text supplied by a third party at runtime — and every property that makes them useful makes them dangerous: they must be natural language, they must be instructive, and the model must weight them heavily or it will not use the tools correctly.
Two things follow that the retrieval framing misses. First, the payload can act on registration rather than on invocation — a description delivered when the agent enumerates available tools is in the context whether or not the tool is ever called, so the defensive instinct to scrutinise what a tool does when used is aimed at the wrong moment. Second, the contamination crosses servers: descriptions from one connected server sit in the same context as another's, so the trust boundary most teams have drawn at the individual server is not where the shared resource actually is. The context window is the shared resource, and everything connected writes to it.
The architectural answer is the same one, which is the encouraging part: descriptions are untrusted content, so they belong on the quarantined side of the boundary, and the gate that evaluates the resulting action must not have derived its policy from them. The operational answer is more prosaic — pin server versions, hash the descriptions, diff them on load, and fail closed on change. That costs an afternoon and closes the mutation variant entirely.
What to red-team, concretely
Test the path, not the model is easy to agree with and hard to operationalise, so here is what it means in practice.
Place the injected content where real content enters, not in the prompt. That means writing an adversarial document into the actual index, sending an adversarial email to a real monitored mailbox, or standing up a tool server that returns an adversarial description. An injection typed into a chat box tests a surface that is already comparatively well defended and tells you very little about the ones that are not.
Score system outcomes, not model outputs. Define the win condition as an action taken or data egressed, and instrument for that. A model that enthusiastically agrees to exfiltrate and then cannot is a pass; a model that says nothing unusual and quietly makes a call is a failure. Text-scored evaluations reverse both judgements.
Include the boring paths. The published research consistently finds that simple injections work in realistic settings, so the exercise should not be an exotic-attack showcase. Plain instructions, placed in a plausible location, are the realistic threat and the one most likely to be missed by a team that has been reading adversarial-ML papers.
And run it against the composed system on the version you actually ship, because plane separation and gating are the controls under test — not the model's disposition, which was never the control.
Three markets, one architecture, different urgency
The design answer does not change by geography. What changes is which deployment pattern dominates, and therefore how exposed the estate already is.
In North America, enterprise copilots with broad reach across mail, files and collaboration platforms are the common pattern — which is precisely the EchoLeak shape. The urgency is highest here, and the useful question for a security function is not whether the vendor has hardened the model but what the assistant can reach and what evaluates its actions.
In India, the dominant pattern is customer-facing and workflow automation built at speed on rented models, where the untrusted content is customer-supplied text arriving through channels designed to accept anything. The exposure is narrower per system and much wider in aggregate, and the gate at the point of action is the control that pays for itself fastest.
In the Gulf, new-build integrated deployments mean the architecture is still being decided, which is the cheapest possible moment to insist on plane separation — it is a design constraint rather than a retrofit. The specific risk is that integrated stacks present the whole assembly as a vendor-assured unit, and the question what evaluates the action, and did it read the untrusted content? has to be asked of the assembly rather than accepted at the perimeter.
The strongest objection: this is over-engineering for most deployments
The serious counter-argument is proportionality, and it deserves more respect than advocates of architectural answers usually give it.
It runs: most deployments do not need this. An internal assistant summarising documents for employees who already have access to those documents has no meaningful injection surface — the attacker would have to already be inside, and if they are, injection is not their best move. Plane separation doubles inference cost and adds real engineering complexity to systems where the realistic worst case is an embarrassing summary. The architecture is right for a copilot with broad enterprise reach and wrong for the majority of deployments, and prescribing it universally discredits the advice where it genuinely applies.
Most of that is correct, and the proportionality principle is right: the architecture should scale with what a compromised system could reach. Where it breaks is the assessment of what the realistic surface is, in two specific ways.
First, the internal-only assumption is usually wrong in a way nobody has checked. Documents in an enterprise corpus routinely originate outside it — supplier PDFs, customer correspondence, scraped reference material, ticket text written by external parties. The question is not whether the index is internal but whether every path into it is authenticated, and that is an inventory question most programmes cannot answer.
Second, and more consequentially, the summariser acquires actions. Systems that begin read-only gain the ability to send, file, update or approve, because that is where the value is, and nobody re-runs the injection analysis when they do. The architecture is expensive to retrofit precisely because it constrains what the system may be built to do — so the honest guidance is proportionate now with an explicit trigger: when this system gains its first ability to act on the outside world, the plane separation question reopens, and here is who owns that reopening.
Where this argument is weakest
Two admissions.
First, the design family described here is demonstrated at research scale rather than at enterprise scale. CaMeL is a strong result on a benchmark; I am not aware of published evidence that a large production deployment running plane separation has been measured against a determined adversary over time. The reasoning is sound and the mechanism is legible, but the confidence should be about the argument rather than about accumulated field evidence.
Second, I have presented the principle as cleanly separable when in practice the boundary between extracted data and control flow is genuinely contestable. A structured value can influence a branch. A returned identifier can select a tool. Real implementations spend most of their difficulty exactly there, and anyone adopting this should expect the interface design — not the model calls — to be the hard part.
The uncomfortable summary
The industry keeps asking when injection will be fixed, and the research keeps answering that the question is malformed. There is no channel to separate, so there is nothing to parameterise, so there is no fix of the kind the question imagines.
Content will never stop being able to persuade the model. Design so that it stops mattering.