OWASP Says Prompt Injection Is Unsolved. Configuration Will Not Save You.
The security industry has spent two years treating prompt injection like a bug: something a good filter, a stricter system prompt, or the next model version would eventually clean up. That framing is comforting because it implies the problem has an owner and a patch date. It also happens to be wrong, and the people closest to the problem have started saying so out loud.
However, the story from Infosecurity Europe, as reported by Infosecurity Magazine, is not "we found a better filter." It is the opposite. OWASP ranks prompt injection the number one risk to LLM applications, and an OWASP researcher used a public stage to warn that it remains unsolved. Not hard. Not partially mitigated. Unsolved. That is a different kind of statement than the industry is used to hearing about a top-ranked vulnerability, and it should change how you architect, not just how you worry.
Because if the field's own authority on LLM risk is telling you the problem has no fix at the model layer, then every defense that assumes a fix is coming is built on sand.
"Unsolved" is a design input, not a disclaimer
Most people hear "unsolved" and file it under bad news to be managed. That is the wrong place to file it. Unsolved is an architectural fact, and it dictates what a responsible design is allowed to assume.
Prompt injection is unsolved for a structural reason, not a maturity reason. A language model reads one stream of tokens and cannot reliably separate the instructions you gave it from the content it was asked to process. When it reads a document, the document's text and your commands arrive through the same channel, and the model has no privileged way to know which is which. This is why the problem resists patching: it is a property of how the model reads, not a flaw in a particular model.
Help Net Security's coverage of the same OWASP material frames the surrounding failures bluntly, and the through-line is consistent. The attack surface is not shrinking as models improve. It is growing as they get wired to more tools. Reports cited alongside the OWASP warning point to a large year-over-year surge in these attacks, which is exactly what you would expect if the underlying weakness is structural and the number of deployed agents is climbing.
So the honest planning assumption is not "injection will be reduced to an acceptable rate." It is "injection will succeed sometimes, and my architecture has to stay safe when it does." Everything downstream follows from accepting that sentence instead of arguing with it.
Configuration is not a boundary
Here is where most enterprise defenses quietly fail. Faced with an unsolved problem, teams reach for configuration: a better system prompt, a delimiter around untrusted text, a classifier tuned to flag suspicious inputs. These help, and you should use them. But none of them is a boundary. They are all probability reducers, and a probability reducer applied to a structurally unsolved problem lowers the failure rate without ever reaching zero.
The reason configuration is not enough became concrete in 2026. CVE-2025-6514, carrying a CVSS score of 9.6, was disclosed in core MCP infrastructure, remote code execution in the plumbing that connects agents to tools. And Microsoft documented, in its "when prompts become shells" research, how prompt injection stops being a text problem and becomes a code-execution primitive the moment an agent is wired to real tools. That is the escalation that matters. On a chatbot, a successful injection produces a bad sentence. On an agent with tools, the same injection produces an action, and if the plumbing has an RCE, it produces arbitrary code running in your environment.
No system-prompt tweak addresses that. The gap between "the model said something wrong" and "the agent did something wrong" is not closed by configuration, because the danger is not what the model believes. It is what the model is permitted to do once it believes it. A classifier that misses one crafted input has not degraded gracefully. It has handed an attacker the tools behind it.
A structural problem needs a structural answer
If the problem cannot be solved at the model layer, the only responsible move is to stop trying to make the model trustworthy and start making the model's mistakes harmless. That is a shift from probability to structure, and it has a specific shape.
A taint boundary. Untrusted data, anything the agent read rather than authored, is marked and can never become executable privilege. This is not a filter that untrusted content might slip past. It is a rule about what untrusted content is structurally allowed to become, enforced by the system rather than hoped for from the model.
The CaMeL dual-LLM pattern. Split the work across two models. A privileged planner plans and calls tools but never reads untrusted content. A quarantined reader reads the poisoned document and extracts what is needed but holds no tools and cannot act. On any doubt, the pattern fails closed. The component that sees the attack has no hands, and the component with hands never sees the attack. Where a classifier lowers the odds of confusion, this removes the capability to act on it.
Least-privilege non-human identity. Each agent runs under its own short-lived, scoped identity with an explicit egress allow-list, so a successful injection commands an actor that can perform only a handful of named actions to a handful of permitted destinations. A stolen or hijacked agent is worth almost nothing because there is no standing power to abuse.
Defense-in-depth. No single one of these is trusted to hold alone. They are layered so that a bypass of one lands on the next, precisely because "unsolved" means any individual control will eventually be beaten by something novel.
Notice what unites all four. None of them tries to make the model resist injection. Each one assumes the injection succeeds and ensures the success does nothing consequential. That is what a structural answer to a structural problem looks like.
The reframe
The question the industry keeps asking, the one that leads straight to another classifier, is "how do we stop prompt injection?" OWASP just answered it: you do not, not at the model layer, not yet, maybe not ever. Organizing your defense around solving it is organizing around a solution that does not exist.
The better question is this. When an injection succeeds, and OWASP is telling us it will, what does our architecture structurally prevent it from doing? If the answer is "it depends on the classifier catching it," you do not have a boundary, you have a bet. If the answer is "the component that read the attack has no ability to act, and the actor that can act runs under an identity scoped to almost nothing," you have contained an unsolved problem instead of pretending it is solved.
The model layer will not save you. Configuration will not save you. Structure is the only thing that holds when the thing you are defending against has no fix.
If you want to walk your live agents against the four structural controls and find where a successful injection would actually reach, book a meeting and bring us the one wired to the most tools.