Prompt injection is the new SQL injection

In 1998, the security community started warning that mixing untrusted input with executable commands was a category error. It took the industry about fifteen years, countless breaches, and a generation of parameterized query APIs to internalize the lesson. The lesson had a clean shape: data and instructions must never travel in the same channel.

Then large language models arrived, and we built an entire application paradigm on exactly that confusion. A prompt is one undifferentiated stream of text in which system instructions, developer intent, and user input all swim together. The model has no privileged channel, no equivalent of a parameterized query. Anything in the context window is, potentially, an instruction.

This is not a theoretical concern, and the interesting attacks are not the obvious ones. "Ignore previous instructions" typed into a chat box is the tourist version. The serious version is indirect: the malicious payload arrives inside content your system was asked to process. A resume that instructs the screening assistant to rank it first. An email that tells the summarizer to also forward the thread. A web page that a browsing agent reads, containing instructions addressed to the agent. A document in your RAG corpus, poisoned once, injected into every future answer that retrieves it. The user did nothing wrong. Your data did the attacking.

The uncomfortable truth, and anyone selling you a clean fix is lying: there is no parameterized-query equivalent for LLMs today. Delimiters help marginally. Instruction-hierarchy training helps marginally. None of it is a boundary the way prepared statements are a boundary. So the engineering answer is the one security always falls back to when a perfect primitive is missing: assume the component is compromised and constrain what compromise can cost.

In practice that means a few concrete disciplines. Give the model the least privilege you would give an intern on their first day: scoped API tokens, read-only where possible, no direct database access. Put consequential actions behind human confirmation, so an injected "send this email" becomes a draft, not a sent message. Treat model output as untrusted input to the next system, validated against a schema, never executed or rendered raw. Keep retrieval corpora curated and attributable, because a RAG system is only as trustworthy as the least trustworthy document it can retrieve. And log the full context of every consequential model decision, because the incident post-mortem will need it.

Notice that none of these are AI techniques. They are the same boring perimeter disciplines we apply around any untrusted component. That is the reassuring part of the story: the industry already owns the mental model, it just has to notice that it applies.

SQL injection stopped being an epidemic when the safe pattern became the default pattern in every framework. LLM security will get there too. Until it does, the teams that treat their model as a confused, eager, occasionally hostile intern will sleep considerably better than the teams that treat it as a colleague.