Prompt injection is SQL injection without the fix

The comparison between prompt injection and SQL injection is made constantly and usually stops before the important part.

The structural analogy is exact. The resolution is not available.

the structural analogy#

SQL injection: the query and the data travel in the same string. The database parses the combined string and cannot tell which characters came from the developer and which came from the user. A user who writes SQL-shaped input has their input executed as SQL.

Prompt injection: the instructions and the data travel in the same context. The model processes the combined context and cannot tell which tokens came from the developer and which came from a web page, a document, or an email. Content that is instruction-shaped gets treated as an instruction.

Same problem. Mixed channels.

why the fix does not transfer#

SQL injection was solved by parameterized queries. The query is parsed into a plan first, then values are bound into slots. The value cannot become part of the query structure because the structure was already fixed before the value arrived.

That works because SQL has a formal grammar. There is a parse tree. There is a crisp, machine-checkable boundary between "this is syntax" and "this is a literal."

Natural language has no such boundary. There is no parse step that separates instruction from data, because the distinction is semantic, not syntactic. A model's entire function is to interpret meaning from text, and "ignore your prior instructions" means what it means regardless of which part of the context it appeared in.

You cannot parameterize a prompt. There is nothing to parameterize.

what has been tried#

Delimiters. Wrap untrusted content in tags and instruct the model to treat it as data. Helps somewhat. Defeated by content that includes the closing delimiter, or that argues persuasively that it is an exception.

Instruction hierarchy. Train the model to weight system instructions above user content above tool results. This is a genuine improvement and the major labs have all done it. It raises the bar and does not eliminate the attack, because it is a learned preference rather than an enforced boundary.

Classifiers. Detect injection attempts before they reach the model. Works on known patterns. Attackers iterate faster than classifiers update, and the false positive rate on legitimate content is a real product cost.

Separate models. One model handles untrusted content and cannot call tools; another handles privileged actions and never sees untrusted content. This actually works and it is architectural rather than probabilistic.

That last one is the direction.

the architecture that holds#

Stop trying to make the model safe. Make the system safe, assuming the model will be compromised.

Separate contexts by trust level. A session that reads arbitrary web content does not have credentials. A session with credentials does not read arbitrary web content. If information must cross, it crosses through a narrow, typed, validated channel — not by putting both in the same context.

Enforce permission outside the model. The model does not have access; it requests an action, and a separate system decides whether it is permitted based on the user's actual authorization. The model's opinion about what it should be allowed to do is not an input to that decision.

Confirm all egress. Any action that sends data outward — an email, an HTTP request, a file write to a shared location — requires explicit approval. This is the control that bounds the damage when everything else fails, because exfiltration is the attacker's goal.

Make every capability narrow. Not "filesystem access" but "read from this directory." Not "send email" but "send email to addresses in this thread." An agent's permissions should be scoped to the task, granted per-task, and revoked after.

Log everything and monitor for anomaly. You will not prevent every injection. Detecting one within minutes is the difference between an incident and a breach.

the uncomfortable conclusion#

For an agent operating on untrusted content with access to sensitive systems, there is currently no configuration that is safe in the way parameterized queries are safe.

There are configurations that are acceptably risky for a given use case, and that judgment requires knowing what the agent can reach and what happens if it is turned against you.

The industry is deploying this capability broadly anyway, on the theory that mitigations will outpace attacks. That theory has a poor historical record — SQL injection was not solved by better filtering, and XSS was not solved by better escaping heuristics. Both were solved by architectural changes that made the unsafe thing impossible to express.

Nobody has the architectural fix here yet. Until someone does, the safety of any deployment is a function of how carefully someone drew the boundaries, and most deployments have not drawn any.