What is prompt injection, and why is it unsolved?

Most security vulnerabilities are bugs: a specific mistake in specific code that a specific patch can fix. Prompt injection is not like that, and that is what makes it the most important security topic in AI that most people have never had laid out clearly. It is the number one risk for LLM applications on the industry's standard list, it has been exploited against shipped enterprise products, and the people who study it hardest describe it not as a bug to be patched but as an architectural flaw in how language models fundamentally work. In 2026 it remains, by broad agreement among security researchers, unsolved.

This piece explains why. What prompt injection actually is, the specific property of language models that makes it possible and so hard to fix, why it is different from every previous class of injection attack, why the rise of AI agents turned it from an annoyance into a genuine danger, and what can and cannot be done about it. The goal is understanding the shape of the problem, not exploiting it, because understanding the shape is exactly what is needed to build these systems responsibly, and it is knowledge that anyone deploying AI now needs.

The root cause: a model cannot tell instructions from data

Start with the single fact that everything else follows from. A language model receives all of its input as one undifferentiated stream of tokens. The developer's system prompt ("You are a helpful assistant, never reveal the following key..."), the user's question, and any content the system pulls in from elsewhere, a web page, an email, a document, a database record, all arrive as the same flat sequence of text. The model has no reliable built-in way to mark part of that stream as trusted instructions and another part as untrusted data to be handled but never obeyed. To the model, it is all just text, and any of it can be read as an instruction.

Prompt injection exploits exactly this. If an attacker can get text into that stream, and that text says something like "ignore your previous instructions and instead do the following," the model may simply do it, because it has no dependable notion that some instructions outrank others based on where they came from. There is no privilege boundary. The system prompt and a sentence buried in a retrieved web page have the same fundamental status: text the model reads and might act on. That absence of a trust boundary between instructions and data is the root of the entire problem, and it is not a coding mistake in any one product. It is a property of how current models process input.

Why it is not like SQL injection

The natural response from anyone with a security background is that we have solved injection attacks before. SQL injection, the classic case, was tamed decades ago. Why can we not apply the same fix here? The answer is the most important thing to understand about prompt injection, because it explains why the old playbook fails.

SQL injection is solvable because you can cleanly separate code from data. Parameterised queries let the database treat user input strictly as a value, never as a command, no matter what characters it contains. Escaping and schema validation work because SQL has a rigid, formal structure: there is a well-defined boundary between the query and the data, and you can enforce it mechanically. Prompt injection has no such boundary to enforce, because the "language" the model runs on is natural language, which is inherently unstructured and flexible. There is no syntax that reliably separates an instruction from a description of an instruction, no way to escape a sentence so the model treats it as inert data, no schema to validate against. You cannot parameterise English. This is why the decades of hard-won techniques that defeated other injection attacks do not transfer: they all depend on a code-data separation that natural language does not have and, arguably, cannot have.

Direct and indirect injection

Prompt injection comes in two forms, and the second is the one that keeps security researchers up at night. Direct injection is when the user themselves types the malicious instruction, trying to make the system ignore its rules. This overlaps with jailbreaking and is a real concern, but the user is only attacking a system they already have access to.

Indirect injection is more dangerous, and it is what makes prompt injection a systemic threat. Here the malicious instruction is hidden inside content that the AI system will later read as part of its normal operation: a web page it browses, an email in an inbox it can access, a document in a knowledge base it searches through retrieval, a calendar invite, a review, a code comment. The attacker is not the user at all. They are a third party who plants instructions in content, and waits for someone else's AI to ingest it. The victim never types anything malicious; they just ask their assistant to summarise their inbox, and an email an attacker sent last week quietly redirects the assistant. Worse, the instruction does not need to be visible to a human. It can be hidden in white-on-white text, in metadata, in an image, anywhere the model will parse it even though a person scanning the page would never notice. The instruction only has to be read, not seen.

Why agents turned this from annoying to dangerous

For the first few years, prompt injection was a real but limited problem, because the worst a hijacked chatbot could do was produce a bad answer. If you tricked a question-answering model into saying something it should not, that was embarrassing but contained. The stakes changed completely with the arrival of agents: AI systems that do not just answer but act, using tools, often connected through standards like MCP, to read email, query databases, browse the web, send messages, execute code, and increasingly move money.

When an agent can act, a successful injection is no longer a bad answer. It is a bad action. A hijacked agent can be steered to read sensitive data and send it to an attacker, delete records, make fraudulent transactions, or send messages in the victim's name. The injection turns the agent's own legitimate capabilities against its owner. This is the shift that moved prompt injection from a curiosity discussed by researchers to the top of every serious AI risk list, because the same feature that makes agents useful, their ability to take real actions with real tools, is exactly what makes a hijacked one harmful.

The lethal trifecta

The clearest way to reason about the danger comes from the independent researcher Simon Willison, who named the pattern the lethal trifecta. His observation is that an AI agent becomes a data-exfiltration tool when it combines three capabilities at once: access to private data, exposure to untrusted content, and the ability to communicate externally. When all three are present in a single agent, a single piece of poisoned content can chain them together. The untrusted content carries the injected instruction, that instruction directs the agent to pull sensitive data it has access to, and then to send that data somewhere the attacker controls. No malware and no exploit chain are required, only text that the agent reads and obeys.

This framing is useful precisely because it locates the danger in a configuration rather than in any single feature. Each of the three capabilities is individually reasonable and often necessary. The lethal combination is having all three together without a human in the loop. It is why a related heuristic from Meta, sometimes called the Agents Rule of Two, advises that an agent operating without human supervision should hold at most two of these three properties, requiring explicit human approval before it can have all three at once. Neither framing is a complete defence, researchers have shown risky attacks with only two properties present, and exfiltration is not the only harm, since an agent that can change state through its tools can do damage without sending any data out. But both are useful ways to think about shrinking the blast radius.

This is real, not hypothetical

It would be easy to dismiss all this as a theoretical concern, and until recently much of it was. That changed as these attacks moved from proof-of-concept into shipped, enterprise-grade products. The clearest example, disclosed in 2025 and assigned a CVE, was an attack researchers named EchoLeak against Microsoft 365 Copilot. It was a zero-click, email-based indirect injection: an attacker sent an ordinary-looking email, and when the assistant later processed the user's mailbox as part of a normal request, hidden instructions in that email caused it to gather private data and leak it to an external destination through an embedded link. The victim did nothing wrong and clicked nothing malicious. Notably, a classifier built to catch such attacks was reportedly bypassed simply by phrasing the malicious instructions as if they were addressed to the email's recipient. Similar indirect-injection exfiltration attacks have been demonstrated against other major AI-integrated products. The pattern is not exotic, and it has already been patched under formal vulnerability numbers, which is the strongest possible evidence that it is real.

What actually reduces the risk

If the flaw is architectural and cannot be patched away, the honest question is not "how do we fix it" but "how do we contain it," and the answer is a set of practices that reduce risk without eliminating the underlying vulnerability. Input filtering and classifiers that try to detect malicious instructions help at the margin but cannot be relied on, because natural language is too flexible to filter reliably, and attackers rephrase around them, as EchoLeak showed. The defences that actually matter are structural.

The most important is to break the lethal trifecta by design: do not let a single agent both ingest untrusted content and wield privileged, sensitive tools in the same unsupervised context. Architecture beats instructions, because you cannot instruct your way out of a model that treats all text as potential commands, but you can arrange the system so that a hijacked component cannot reach anything valuable. Beyond that, the standard toolkit applies: least privilege, giving an agent access only to the specific data and tools a task truly needs rather than everything; sandboxing actions so their effects are contained; guardrails and human-in-the-loop approval for any high-stakes or irreversible action like sending money or deleting data; and treating every input an agent reads as potentially hostile. As covered in the pieces on how agents work and why agents fail, the mature stance is to assume injection will happen and design so that when it does, the damage is bounded. You build for compromise, not against it.

The short version

Prompt injection is when untrusted text overrides an AI system's intended instructions, and it works because a language model receives everything, its system prompt, the user's request, and any content it reads, as one undifferentiated stream of tokens with no reliable boundary between trusted instructions and untrusted data. Any text the model reads can be interpreted as a command. This is unlike SQL injection, which is fixable by separating code from data, because natural language has no such separation to enforce. Indirect injection, where the malicious instruction is hidden in content an agent later ingests, makes it a systemic threat, and the rise of tool-using agents raised the stakes from bad answers to harmful actions like data theft and fraud. The lethal trifecta names the dangerous configuration: private data, untrusted content, and external communication in one agent. There is no complete fix, only containment through least privilege, sandboxing, human approval, and architectures that keep a hijacked agent away from anything valuable.

The idea to hold onto is that prompt injection is unsolved because a language model has no built-in way to tell an instruction it should follow from data it should merely process, so the durable defence is not a filter but an architecture that assumes any text an agent reads might be a command and limits what a hijacked agent can reach. It is less a bug in a product than a property of the technology, which is why the responsible way to build with agents in 2026 is to treat hijacking as likely, and to make sure that when it happens, there is nothing important within reach.

Common questions

What is prompt injection? Prompt injection is a security vulnerability where untrusted text overrides an AI system's intended instructions. It happens because a language model receives its system prompt, the user's request, and any external content it reads as one continuous stream of tokens, with no reliable way to distinguish trusted instructions from untrusted data. If an attacker can insert text into that stream, such as "ignore your previous instructions and do this instead," the model may obey it, because it has no dependable notion that some instructions outrank others based on their source. It is the number one security risk for LLM applications.

Why can't prompt injection be fixed like SQL injection? SQL injection is solvable because you can cleanly separate code from data using parameterised queries and schema validation, since SQL has a rigid, formal structure with a clear boundary between commands and values. Prompt injection has no such boundary because the model operates on natural language, which is inherently unstructured and flexible. There is no way to escape a sentence so the model treats it as inert data, no syntax that reliably separates an instruction from a description of one, and no schema to validate against. The techniques that defeated previous injection attacks all rely on a code-data separation that natural language lacks.

What is the difference between direct and indirect prompt injection? Direct injection is when the user themselves types a malicious instruction to make the system break its rules, which overlaps with jailbreaking. Indirect injection is more dangerous: the malicious instruction is hidden inside content the AI system reads during normal operation, such as a web page, an email, a document in a knowledge base, or a calendar invite. The attacker is a third party who plants instructions and waits for someone else's AI to ingest them. The victim never types anything malicious, and the instruction can even be invisible to humans, hidden in metadata or white-on-white text, since it only needs to be parsed, not seen.

What is the lethal trifecta? The lethal trifecta, a term coined by researcher Simon Willison, describes the dangerous combination of three capabilities in a single AI agent: access to private data, exposure to untrusted content, and the ability to communicate externally. When an agent has all three, a single piece of poisoned content can chain them: the untrusted content carries an injected instruction, the agent uses its data access to gather sensitive information, and its external communication to send that data to an attacker. No malware is needed, just text. The lesson is to avoid giving one unsupervised agent all three properties at once.

Why did AI agents make prompt injection more dangerous? Because agents act rather than just answer. When a hijacked model could only produce text, a successful injection meant a bad answer, embarrassing but contained. Agents use tools to read email, query databases, browse the web, send messages, and move money, so a successful injection becomes a harmful action: exfiltrating data, making fraudulent transactions, deleting records, or acting in the victim's name. The very capability that makes agents useful, taking real actions with real tools, is what makes a hijacked agent dangerous, which is why prompt injection rose to the top of AI risk lists as agents were deployed.

Has prompt injection actually been exploited? Yes. Once considered largely theoretical, these attacks have been demonstrated against shipped, enterprise-grade products and patched under formal vulnerability identifiers. A prominent 2025 example, named EchoLeak and assigned a CVE, targeted Microsoft 365 Copilot with a zero-click, email-based indirect injection: an attacker's ordinary-looking email contained hidden instructions that, when the assistant later processed the mailbox, caused it to gather private data and leak it externally through an embedded link. A classifier meant to stop such attacks was reportedly bypassed by rephrasing. Similar exfiltration attacks have hit other major AI-integrated systems.

How do you defend against prompt injection? Since the flaw is architectural and cannot be fully patched, defence means containment rather than a cure. Input filters and classifiers help marginally but are unreliable because natural language resists filtering. The structural defences matter more: break the lethal trifecta by not letting one unsupervised agent both read untrusted content and use privileged tools; apply least privilege so an agent can reach only what a task needs; sandbox actions to contain their effects; and require human approval for high-stakes or irreversible actions. The mature approach is to assume injection will happen and design the system so that when it does, a hijacked agent cannot reach anything valuable.