Prompt Injection Is the New SQL Injection

In 2007, a cartoon came out that every security person still remembers. A school calls a mother about her son, Robert'); DROP TABLE Students;--, and the joke lands because everyone in the industry had seen the real version. SQL injection was the vulnerability that ate the 2000s. It was not sophisticated. It was a category error: the database could not tell the difference between code and data, so an attacker just handed it data shaped like code, and the database obeyed.

We fixed it the boring way. Parameterized queries. Input validation. Least privilege on database accounts. It took the better part of a decade, an OWASP Top 10 that never let the industry forget, and a long trail of breached retailers and government agencies before the discipline became default. I spent those years in IT operations. I remember what the remediation felt like: unglamorous, repetitive, and absolutely non-negotiable once leadership understood the alternative.

We are living through the same bug again. This time the database is a language model, the query is a prompt, and the industry is at the stage where it still treats the whole thing as a curiosity.

We have lived through this exact bug before

The shape of SQL injection was always simple. An application builds a database query by concatenating a trusted template with untrusted user input. The input contains SQL syntax. The database executes the whole thing as one command, because it has no reliable way to know which parts were the template and which parts were the stranger's contribution. The fix was architectural: separate the channel. Parameterized queries send the code and the data through different paths, and the database never confuses them again.

Prompt injection is the same shape with the serial numbers filed off. An AI agent builds its behavior by combining trusted instructions (the system prompt, the developer's intent, your request) with untrusted content (an email, a webpage, a document, a tool result, a calendar invite). The untrusted content contains instructions. The model follows them, because it has no reliable way to know which parts were the principal's intent and which parts were the stranger's contribution.

The industry even has the same two-stage history repeating. Direct prompt injection, the attacker typing malicious instructions straight into the chat box, is the equivalent of the form field nobody sanitized. It is the variant everyone understands and the one most defenses are built for. Indirect prompt injection, malicious instructions hidden in content the agent retrieves during normal work, is the second-order injection, the stored XSS of this era. And it is the one doing the real damage, because it arrives through channels the victim trusts.

The database could not tell code from data

It is worth remembering how long the industry spent in denial the first time. SQL injection was documented in 1998. For years it was treated as a coding mistake rather than a vulnerability class, something individual developers did wrong, not something the architecture invited. The turning point was not a better firewall. It was the recognition that any system mixing trusted commands with untrusted input, without an enforced boundary between them, will eventually execute the attacker's intent. The vulnerability was not in the code. It was in the design.

That recognition is what turned a bug into a discipline. Once the industry accepted that the boundary had to be structural, enforced by the platform and not by each developer's vigilance, the fixes followed: parameterized queries as the default, ORMs that made the safe path the easy path, static analysis that flagged concatenation, and database accounts with the minimum privilege to do the job. Nobody asks developers to "be careful" with SQL anymore. The safe pattern is the path of least resistance.

The model cannot tell instructions from data

Now look at where the AI industry is. Prompt injection is OWASP's number one risk in both the Top 10 for LLM Applications and the companion Top 10 for Agentic Applications, and the 2026 edition is the first built on incident evidence: 7,714 real-world AI security incidents. Attacks are up 340 percent year over year. Nearly three-quarters of production AI deployments assessed in security audits show exposure. Depending on configuration, attack success rates run between 50 and 84 percent.

And yet the dominant industry posture is still the 1999 posture: treat it as a novelty, a research curiosity, a prompt-engineering problem that the next model release will somehow outgrow. Vendors ship agents with broad tool access and standing credentials, then act surprised when the oldest trick in the book works on the newest system in the stack.

The numbers tell the story the marketing does not. Indirect injection, the kind that arrives inside content the agent was supposed to read, now accounts for the majority of attacks. Web-based indirect injection alone accounts for nearly 40 percent of all LLM security incidents. The attack surface is not the chat box. It is everything the agent is allowed to read.

The attackers are not waiting for the lesson

SQL injection's history has a second chapter the industry prefers to skip: the attackers industrialized it long before the defenders finished the remediation. Automated tools, exploit kits, mass scanning. The same industrialization is already underway here, and it is moving faster because the targets are richer.

Consider the incidents stacking up. EchoLeak (CVE-2025-32711) was the first zero-click prompt injection in a production AI system: hidden instructions inside an ordinary email caused Microsoft 365 Copilot to exfiltrate OneDrive and SharePoint data through a markdown image, with no click and no user action at all. Read that again. An email, the most routine object in enterprise computing, became a remote command channel for an AI with access to the file system.

In February 2026, a crafted GitHub issue title embedded a malicious instruction that triggered an authenticated AI coding session to install an attacker-controlled package, which was then distributed as an official update to roughly 4,000 developer machines. The developer had authorized the agent to act on their behalf. The agent delegated that authority to an attacker the developer never evaluated, configured, or consented to. Researchers called it Clinejection: the supply-chain equivalent of the confused deputy problem, the classic access-control failure where a privileged program is tricked by a less-privileged caller into misusing its authority. It is the exact failure mode SQL injection exploited, wearing a new uniform.

Then there was the week the industry should have treated as its wake-up call. Between January 7 and 15, 2026, researchers disclosed working exploits against four major AI productivity tools, IBM's Bob, Superhuman AI, Notion AI, and Anthropic's Claude Cowork, in rapid succession, all using the same pattern. Simon Willison had given the pattern a name months earlier: the "lethal trifecta." Any agent that simultaneously accesses private data, processes untrusted content, and can communicate externally is exploitable through a single poisoned input. Four products, one pattern, eight days. That is not a set of isolated bugs. That is a vulnerability class announcing itself.

And the strangest proof came from Moltbook, the social network built exclusively for AI agents. In its first 72 hours, roughly 506 injection attacks were flagged: agents prompt-injecting each other through the posts and comments they consumed, then replicating the payloads. The agents built a botnet out of each other before the humans finished onboarding.

Why this one is worse

Here is the part that should worry anyone who remembers how the SQL injection story ended. SQL injection had a complete fix. Parameterized queries work. They are deterministic, they are cheap, and they closed the class.

This is the fundamental asymmetry. A database is deterministic: separate the channels and the confusion is gone forever. A language model is probabilistic: every mitigation is a suggestion the model might follow, weighed against an attacker's instructions it might prefer. There is no architectural fix yet, only layers of probabilistic defense, each one waiting for an adaptive attacker.

And the blast radius is larger, because the modern agent is not a chatbot. It is a deputy with hands. It reads your inbox, queries your databases, executes code, calls APIs, and spends money. SQL injection gave the attacker the database. Prompt injection gives the attacker the employee: the credentials, the tools, the authority, and none of the judgment.

There is no parameterized query yet

Prompt injection has no parameterized query. A cross-lab study from researchers at OpenAI, Anthropic, and Google DeepMind, "The Attacker Moves Second," published in late 2025, put twelve published defenses through adaptive attacks using gradient descent, reinforcement learning, and human-guided exploration. Attack success rates exceeded 90 percent against most of them, even though those defenses had originally reported near-zero success rates. Static evaluation, the study showed, dramatically overstates how well defenses work. The attacker gets to adapt. The defense does not.

What the discipline looks like

So what does the discipline look like, while we wait for the architectural fix that may never fully arrive? It looks exactly like what the SQL injection era taught, translated for agents.

Separate instruction from data as far as the platform allows. Instruction hierarchies, tool-call boundary enforcement, and structured tool schemas are the parameterized queries of this era, imperfect, but the direction is right. Every layer that makes it harder for retrieved content to become executed instruction is a layer worth having.

Give the deputy the minimum authority to do the job. An agent that summarizes documents does not need the credentials to send email. An agent that triages tickets does not need production database writes. The short-lived credential modules some of us built for service accounts exist for exactly this reason: scope the grant, expire the session, log the use. Standing credentials for agents are the shared database service account of 2005, and we already know how that story ends.

Treat every input channel as untrusted. Email, webpages, documents, tool outputs, calendar invites, issue titles: if the agent reads it, it is an input, and inputs get validated. The EchoLeak lesson is that the trusted channel is the attack vector.

Log what the deputy did, not just what it was asked. Audit trails are the detective control while prevention is probabilistic. If you cannot reconstruct which instructions the agent followed and which data it touched, you cannot do incident response. You are flying blind with extra steps.

Put a human on the irreversible actions. The agent can draft the refund, the deploy, the purchase order. A human approves it. This is change control, and it is older than any of us.

None of this is novel. That is the point. The industry spent twenty years building this discipline for every other kind of software, and then shipped agents with the enthusiasm of a team that had never heard of any of it.

My takeaway

SQL injection went from documented curiosity in 1998 to the vulnerability that defined a decade, and it took the industry roughly ten years to build the discipline that tamed it. The OWASP Top 10, parameterized queries as default, least-privilege service accounts: none of that arrived because the bug was clever. It arrived because the industry finally accepted that the flaw was architectural and the fix had to be structural.

Prompt injection is on the same timeline, except the attackers are moving faster and the deputies have more authority. The incidents are already here: zero-click exfiltration through Copilot, supply-chain compromise through a coding agent, four products proven vulnerable in eight days on the same pattern, agents infecting each other on a social network. The evidence phase is over. What remains is the recognition phase, the moment the industry stops treating a vulnerability class like a curiosity and starts treating it like what it is.

The parameterized query for AI agents does not exist yet. Until it does, the only responsible posture is the boring one: separate what you can, scope everything, trust no input channel, log everything, and keep a human on the irreversible actions.

We learned this lesson once. The tuition was enormous. There is no reason to pay it twice.