Prompt injection is not an old story 🧩

TL;DR: calling prompt injection “the new SQL injection” is useful for remembering a risk exists. It is harmful if it makes you apply the wrong defence.

Where the analogy breaks 🔧

With SQL you can separate structure and value: parameterized queries, parsers, types. A prompt is text a model interprets together with instructions, data retrieved from a document, and user input. A hostile instruction can arrive in a web page, a PDF, or the record your RAG considers authoritative. It is not “the malicious user in the input field”: it is anyone — or any document — that manages to enter the context window.

There is no magic character that “escapes” a document from the model’s reasoning. Saying “ignore previous instructions” is not a parser bug. It is an attempt to influence a probabilistic system that must understand language in order to function. And here lies the philosophical point: SQL injection attacks an interpreter that distinguishes code from data; prompt injection attacks a system where code and data are the same thing, because an instruction is just text with a probability of being followed.

The control/data boundary has vanished 🧱

For thirty years, modern security was built on one obsession: separating input from interpretation. Parameterized queries, template escaping, content security policy… everything rests on the idea that we can brand “this is code” and “this is data.” In LLMs that boundary no longer exists: the system instruction is text, the document is text, the user input is text, and the model decides each time, with a probabilistic weight, which portion to treat as an instruction.

This is not a bug to be patched: it is the architecture of the medium itself. The model must interpret untrusted language to be useful — if it stopped trusting content, it would become the hostage of every single message and therefore useless. Which means the defence cannot sit “before” the model, like escaping, but after: at the point where the output meets reality with privileges.

A secure agent is not one that never reads a malicious prompt. It is one that cannot turn it into silent harm.

Attack demos are not a strategy 🎪

The market is full of them: videos where a researcher gets the model to do anything that crosses its mind, and then the company announces it “fixed the problem.” Watch out: an adversarial eval is not a frontier to cross once, it is a gym to attend regularly. Malicious prompts do not arrive for the agent’s birthday: they can come from a PDF received by email, from a scanned page, from a database record written years ago by a user you will never meet. If your defence is a sequence of “educational” examples in the system prompt, you are building a sandcastle with a tide on a strict schedule.

The first useful eval is not the most spectacular one: it is the one that tests the actions — that tries to make the agent do things it should not, like sending emails, deleting records, updating balances. Because the difference between a vulnerable agent and a robust one rarely lies in the thinking: it lies in the muscles. And muscles, unfortunately, are hard to measure in a demo.

Defend the actions, not the wishes 🛡️

The most human temptation is to ask the model to be prudent: “do not obey malicious inputs, you are a trusted assistant.” It works about as well as telling a colleague “do not get manipulated”: good intention, zero enforcement. The most reliable defence is not asking the model to resist — it is taking away the muscles it would need to do harm.

The operational translation is boring and magnificent: least-privilege tools, structured and validated output, confirmations for irreversible effects, data isolation, audit logs, and evaluation with hostile content. There is nothing brilliant about it, and it works. The principle is to invert the cliché: do not make the agent wiser, make it less powerful over what it does not need.

This shift — distrusting the action, not the thought — is the same lesson we already see with coding agents and the orchestrating senior: the risk is not what the model “wants,” but what we allow it to do. When execution is confined, the malicious prompt becomes just text that passes through — annoying, but harmless. And that is the silent victory no “prompt injection defence percentage” bar will ever manage to sell.

Coexistence, not immunity 🧬

An uncomfortable thing needs to be said, and said clearly: a system built on a language model will never be immune to prompt injection, exactly as code is never immune to bugs. The goal is not immunity — a brochure adjective — but supervised coexistence: the hostile prompt enters, is read, and produces no effect. It is a distinction founded on character: assuming you can block every entry is an anxiety strategy; designing systems that tolerate the entry without suffering it is an engineering strategy. The day we accept that the problem is not “preventing the malicious actor from talking to the agent” but “making sure it is not worth it,” we will stop chasing the perfect prompt and start building the legible perimeter.

The guide Injection and supply chain digs into the mechanisms; agents in production shows how to design oversight and kill switches. Because the honest question we must stop asking is not “will the model realize it was an attack?” — the question is “even if it did not, could it break something for me?”