If you come from the database world you know SQL injection, and you know it got solved: parameterised queries, problem gone. The natural question is why the same hasn’t been done for language models.
The answer is that it can’t be, at least not yet.
Why it is structural
The 2026 OWASP Top 10 for LLM Applications keeps prompt injection at number one. Its reasoning is the part that matters: the model processes instructions and untrusted content inside the same context window, and no equivalent of the parameterised query exists to separate them.
In SQL you can tell the engine “this is code, this is data” and it respects the boundary. In an LLM, everything is text. The document you are summarising may contain a sentence the model reads as an instruction, and there is no layer that structurally distinguishes one from the other.
OWASP adds an interesting detail: injection holds first place despite a thin public incident record, which it attributes to a defence effect — so much is invested in containing it that successful attacks don’t end up in public databases.
What changed in 2026
Excessive agency climbed from sixth in 2025 to third in 2026. It is no accident that this coincides with the year of agents.
The reason is direct: prompt injection stops being a content problem and becomes an action problem. A model that only drafts text and gets it wrong produces bad text. An agent with credentials, persistent memory and tool access that gets it wrong executes something.
Current deployments give these systems access to files, databases, code, messaging and business processes. The surface is no longer the conversation: it is everything the agent can reach.
How it gets contained
It doesn’t get eliminated. It gets contained, and the right framing is the usual one in security: assume compromise and limit the blast radius.
- Least privilege, genuinely. The agent reaches what it needs for that task, not what its service account permits. Credentials per task, not per system.
- Separate reads from writes. Reading untrusted content and writing to critical systems should not share a context without a human approval in between.
- Human confirmation on the irreversible. Send, pay, delete, publish, change permissions. Anything that cannot be undone goes through a person.
- Filter output, not just input. Watch what leaves: context data leakage, unexpected tool calls, URLs with odd parameters.
- Per-step logging and alerts. If you cannot reconstruct what the agent did and why, you cannot respond to an incident either.
- Treat all external content as hostile. Email, PDF, web page, customer ticket, search result. All of it.
The question for your vendor
If you are evaluating an AI tool with access to your systems, one question separates those who have thought about this from those who haven’t:
“What happens if the document your agent processes contains instructions aimed at it?”
If the answer is “the model is good enough to ignore them”, find another vendor. If the answer talks about isolation, scoped privileges and approvals, you are talking to someone who understands the problem.