SQL injection taught a durable lesson, that data must never be allowed to become instructions, and that any input crossing a trust boundary has to be treated as hostile until proven otherwise. Prompt injection is the same class of failure appearing in a new medium, and most teams building on language models have not yet internalized it. The problem is structural rather than incidental. A language model receives instructions and data as a single undifferentiated stream of text, and it has no reliable internal boundary separating the developer's directions from content it was merely asked to process. Any text the model reads, a web page, an email, a document, a code comment, can address the model as though it were the operator.
The exposure is limited when the model can only read and respond, since a summarizer coaxed into producing wrong output is a contained problem. It becomes serious the moment the model is given tools, the ability to send email, call an API, execute code, or modify data, because now a crafted instruction embedded in untrusted content can drive real actions with the model's privileges. This is the distinction between an attacker who can influence what a system says and one who can influence what it does, and the industry is moving quickly toward the second by wiring models into agents and workflows, often without the corresponding controls. A retrieved document that instructs the model to exfiltrate the contents of the current session is not a hypothetical, it is a working technique against a naively built agent.
There is no single control that closes prompt injection, which is the uncomfortable and important truth, but the mitigations are the familiar disciplines of security engineering rather than anything novel. Treat all model input as untrusted, including content the model retrieves on its own. Constrain the model's privileges to the minimum the task requires, so that even a fully successful injection has little to act on. Place a human confirmation in front of any consequential or irreversible action rather than allowing model output to trigger it directly. Isolate execution so that tool calls run in a sandbox with scoped, short lived credentials, and validate outputs before they feed a sensitive operation. None of these eliminate the underlying weakness, they contain its blast radius, which is the appropriate goal for a problem that cannot be fully solved.
Prompt injection is not a defect that a future model version will patch away, it is a consequence of how these systems read, and it should be treated as a permanent property of the design rather than a temporary rough edge. The teams that will build safely on language models are the ones that assume from the outset that the model can be talked into anything, and that architect the surrounding system so that being talked into something remains survivable. That is a discipline the security field already knows well, applied to a new component, and the sooner it is taken up with that seriousness, the fewer avoidable incidents the coming wave of AI powered systems will produce.