RE.SIGNAL
Prompt injection:
the vulnerability that cannot be patched
Every serious security problem of the last thirty years has eventually had a fix. This one may not — not because nobody is trying, but because it is not a flaw in the software. It is how the software works.
What follows is an attempt to explain it plainly, and to say honestly which parts are settled and which are still argument.
In June 2025, researchers disclosed a flaw in Microsoft 365 Copilot. An attacker sent an ordinary-looking email. The recipient never opened it.
Later, that person asked Copilot something entirely unrelated. To answer, Copilot searched their mailbox for context — and pulled in the attacker’s email along with everything else. Hidden inside it were instructions. Copilot followed them, and company data was sent out.
The vulnerability was catalogued as CVE-2025-32711 and given the name EchoLeak. Microsoft fixed it on their side and reported no evidence of it being used in the wild. Credit for the discovery is reported inconsistently — most accounts name Aim Labs, at least one names Aim Security — which is worth mentioning because it tells you something about how young and unsettled this field still is.
Nobody clicked anything. That is the part worth sitting with.
Why this is not a bug
Here is the thing most coverage skips, and it is the only part you genuinely need to understand.
A language model reads everything you give it as one continuous stream of text. The instructions from whoever built the product, your question, and the contents of any document, email or web page it was asked to look at all arrive as the same kind of thing: words, in order.
There is no reliable mechanism inside the model for marking one part as commands I must obey and another as material I am merely reading. Speaking at Infosecurity Europe in 2026, OWASP contributor Ariel Fogel described it as an unresolved architectural problem rather than a defect awaiting a patch.
A letter telling you to rob a bank is still just a letter. The difficulty is that a language model does not reliably know that.
You and I hold that boundary without effort. We can read a hostile instruction inside a document and treat it as content — something the document says, not something we have been told to do. A model’s grip on that distinction is probabilistic rather than structural. It usually holds. It can be talked out of it.
Why the obvious fix does not work
Anyone with a technical background will reach immediately for the parallel to SQL injection, and the comparison is genuinely useful — including where it breaks down.
SQL injection was the same shape of problem: data getting treated as instructions. We solved it properly, with parameterised queries, by keeping code and data in separate channels the database could tell apart with certainty.
That solution is not available here, because with a language model the instructions and the data are both natural language, travelling down the same channel, interpreted by the same mechanism. There is no second channel to move one of them into.
A 2026 preprint by Abdelnabi and Bagdasarian goes further and argues that defences based on separating data from instructions face an impossibility-style barrier — not merely difficult, but structurally unavailable. That is a preprint and an argument, not a settled result, and we would be overstating it to call it proven. It is, however, consistent with the pattern practitioners keep reporting: published defences fall to adaptive attacks.
The lethal trifecta
Simon Willison’s framing, from June 2025, and the most useful thing written on this subject for people who are not security researchers. Three capabilities. Danger lives where all three overlap.
Your mailbox, your files, your client records, your calendar. Anything an assistant has been connected to in order to be useful.
Any text written by someone outside your organization: an inbound email, a web page it browsed, a supplier’s PDF, a shared document.
Sending email, posting to a service, calling an external tool, or fetching a URL — which quietly carries data in the request itself.
Remove any one leg and the attack largely collapses. The data can be read but not sent. The content can be read but reaches nothing worth taking. The usual mitigation is subtraction, not better filtering — and Willison himself is openly sceptical of products claiming to detect most attacks.
What has actually happened, and what has not
This is where most writing on the subject becomes unreliable, so let us be careful.
Documented incidents exist and they are real. EchoLeak is one. In a separate 2026 case, an AI coding agent read the title of a pull request, found an instruction inside it, followed it, and wrote a credential into a build log the attacker could read.
The public record is also thin. OWASP keeps prompt injection at the top of its 2026 list for large language model risks, while noting there have been few publicly recorded incidents. OWASP attributes this partly to defences working. It could equally reflect detection being hard and disclosure being unattractive. We do not know which, and neither does anyone else. Treat confident claims about scale in either direction with suspicion.
In May 2026, the Five Eyes agencies issued joint guidance on agentic AI naming prompt injection as a central mechanism of attack, and stating plainly that no single safeguard is sufficient. When five national security establishments publish the same caution, the risk is not hypothetical — but neither is it the same thing as a wave of incidents.
Why it is getting worse rather than better
Until recently, a manipulated model produced a wrong answer. Unpleasant, rarely expensive.
What changed is tools. Assistants now read mailboxes, open files, browse pages, call services and take actions on your behalf. Each capability makes them more useful and widens what a successful manipulation can reach.
The feature and the vulnerability are the same feature. An assistant that cannot read your email cannot leak it, and cannot help you with it either.
Which is why this will not be resolved by a patch cycle. It is a design tension, and design tensions get managed rather than fixed.
What this means if you run a small organization
Now the proportionate part, because a great deal of coverage on this subject is written to frighten.
If you use an AI assistant in a browser tab and paste text into it, your exposure is low. It holds no standing access to your systems. The realistic risk is what your staff paste in, which is a governance question rather than a security one, and we cover it elsewhere.
Exposure rises sharply the moment you connect something. An assistant plugged into your mailbox, your file storage or your CRM has acquired the first leg of the trifecta. If it can also read inbound mail or browse the web, it has the second. If it can send, post or fetch, it has the third.
Most organizations acquire all three without ever deciding to, because each step was individually sensible.
What to actually do
- Inventory what your assistants are connected to. Not which AI products you use — what they can reach. Most people are surprised, and you cannot reason about any of this without the list.
- Break a leg of the trifecta deliberately. Usually the third is easiest: an assistant which can read but cannot send or fetch is dramatically less dangerous and still useful.
- Require a human approval step for anything irreversible. Sending money, sending email externally, deleting, publishing. Treat an agent acting alone on those as a decision you have made rather than a default you inherited.
- Be sceptical of detection products. The research record is consistently unkind to them, and the person who named the trifecta is openly suspicious of vendors claiming high catch rates.
- Assume anything an assistant reads could be hostile, because inbound email and web pages are written by strangers. That is the whole mechanism.
None of this requires a product. It requires knowing what is connected to what, and being deliberate about the third leg.
The honest conclusion
We are not going to end this with reassurance, because the reassurance is not available yet.
Prompt injection is an unsolved problem which the industry is shipping around rather than through. The mitigations that work are architectural — restricting what systems can reach and what they can do — rather than clever filtering. That is an unsatisfying answer, and it is the accurate one.
The practical position for a small organization is neither panic nor dismissal. It is knowing which of your tools hold all three capabilities, and deciding on purpose whether they should.
Where we are standing while writing this
We use AI tools, including in the production of work for clients, and we are not neutral about this subject. Saying so seems the minimum, given the article argues you should be sceptical of anyone with something to sell in this space.
This piece is educational. It is a starting point for your own reading rather than advice about your systems, your contracts or your obligations. Where the evidence is contested we have said so in the text instead of smoothing it over, and proceed at your own risk.
Sources, and how much weight to give them
Strongest. CVE-2025-32711 is the primary record for EchoLeak and the reference we would trust over any write-up of it. The Five Eyes joint guidance on agentic AI (May 2026) and OWASP’s Top 10 for LLM applications are institutional positions rather than vendor material.
Attributed opinion. The lethal trifecta is Simon Willison’s framing, June 2025. Ariel Fogel’s “architectural problem” remark was made at Infosecurity Europe 2026 and reported by Infosecurity Magazine.
Weakest, and flagged as such in the text. The impossibility argument regarding data-instruction separation comes from a 2026 preprint by Abdelnabi and Bagdasarian — not peer-reviewed, and an argument rather than a result. Much of the remaining material circulating on this subject is vendor marketing, including from companies selling detection, and we have not relied on it.
One disputed detail. Sources disagree on whether EchoLeak was discovered by Aim Labs or Aim Security. We have not been able to resolve it and have said so rather than picking one.
Our methodology and limitations statement explains how we reach the positions we take, and where we rely on judgement rather than evidence.