We’ve been here before. A powerful new capability arrives, developers rush to build on it, and security is treated as something to layer on later, after the real work is done. In the early 2000s, that capability was dynamic database queries, and the result was SQL injection, a vulnerability so widespread and so costly that it still appears on OWASP’s top-ten list decades later. Today, the capability is large language models, and the vulnerability is prompt injection. The pattern is identical. The excuse is the same. And if you’re building AI-powered products right now, you are almost certainly making the same mistakes.
What makes the parallel exact
SQL injection works because applications mix trusted code with untrusted user input, then hand both to an interpreter that can’t tell the difference. A developer writes a query, a user fills in a form field, and if you concatenate the two naively, the user’s input gets executed as code. Prompt injection works the same way. You write a system prompt, a user submits a message, your app retrieves some documents and stuffs them all together, and the model, which cannot reliably distinguish instruction from data, may follow whatever instructions appear in the retrieved content instead of yours.
This isn’t a hypothetical. Researchers have demonstrated that a malicious webpage, when retrieved by an AI assistant browsing the web, can instruct that assistant to exfiltrate the user’s data, change its behavior, or lie about its capabilities. Johann Rehberger documented a prompt injection attack against ChatGPT’s browsing feature that could exfiltrate conversation history through image URLs. The attack surface is real, and it scales with how capable the model is. A more powerful model that can take actions, book things, send emails, make purchases, is a more dangerous target.
The SQL injection era taught us that developers initially dismissed the risk as unlikely or too complicated to exploit in practice. That defense aged badly. Prompt injection skeptics are making the same argument today.
The “we’ll fix it later” trap
The pressure to ship is real. You understand that. But “we’ll add security later” is not a plan, it’s a deferral, and deferred security debt compounds faster than technical debt.
With SQL injection, the fix (parameterized queries) required rewriting how applications handled database interactions at a fairly fundamental level. Organizations that had shipped years of vulnerable code spent enormous resources on remediation. Many never fully finished. The same dynamic is setting up in the AI space, where the equivalent of parameterized queries would be strict separation of instructions and data, sandboxed tool access, and explicit trust hierarchies. These are architectural decisions. They are much harder to retrofit than to build in.
If you’re deploying an AI agent with tool-use capabilities and you haven’t modeled what happens when the content it retrieves contains adversarial instructions, you’ve deferred a problem that will be expensive to fix later. The prompt you write isn’t the prompt the model reads, and the gap between those two things is where injection attacks live.
The industry’s structural incentives push the wrong direction
Here’s what makes this worse than the SQL injection era: the incentives are more misaligned. In the early web, developers and companies mostly bore the consequences of their own insecure code. Prompt injection in agentic AI systems can turn your application into a weapon used against your users, with the liability and reputational exposure that implies.
Yet the AI tooling market rewards capability demonstrations, not security rigor. Benchmark scores, feature breadth, and flashy demos drive adoption. A model that autonomously books your travel is exciting. The fact that it might be instructed to do so by a malicious calendar invite in your inbox is less exciting and rarely makes the demo. Vendors have little short-term incentive to highlight the attack surface they’re selling you.
This isn’t unique to dishonest vendors. It’s structural. The same thing happened with early database-driven web frameworks that made SQL injection trivially easy. The frameworks were solving for developer productivity. Security was the user’s problem.
The counterargument
The strongest pushback you’ll hear is that prompt injection is fundamentally different from SQL injection because LLMs are probabilistic, not deterministic. You can’t craft a single injection payload that works reliably across models and contexts the way ' OR 1=1-- worked across databases. The attacks are noisier, less reliable, harder to automate at scale.
This is true, and it matters, but it doesn’t close the argument. Noisy and unreliable attacks are still attacks. Determined adversaries targeting high-value systems, financial accounts, corporate data, healthcare records, will invest in making them reliable. And as models become more capable and consistent, injection attacks become more reliable too. The probabilistic nature of current models is not a security control you should design around.
The other counterargument is that defenses exist: input sanitization, output validation, privilege-restricted tool access, human-in-the-loop confirmation for high-stakes actions. All true. All good. But these defenses exist for SQL injection too, and SQL injection is still in OWASP’s top ten. The existence of defenses doesn’t mean the industry is using them.
We should know better by now
The SQL injection lesson wasn’t subtle. It was expensive, public, and drawn out over years. We don’t get to plead ignorance this time. The attack class is well-documented, the analogy is obvious to anyone paying attention, and the window to build AI systems correctly, from the ground up, is open right now.
If you’re building an agentic AI product, treat every piece of external content your system retrieves as potentially hostile. Separate your instruction layer from your data layer architecturally, not just by convention. Grant tools the minimum permissions they need. Build human confirmation into any action that can’t be undone. Audit what your system actually does with adversarial input before you ship.
The developers who ignored SQL injection in 2003 weren’t stupid. They were busy and optimistic. You can afford to be neither right now. The infrastructure for AI-powered software is being built today, and the security assumptions baked into that infrastructure will be very hard to change once they’re load-bearing.
