In the mid-2000s, the software industry learned an expensive lesson: any place where user input meets an interpreter is an attack surface. SQL injection turned login forms into database dumps for the better part of a decade, until parameterized queries, ORMs, and secure-by-default frameworks made the flaw largely a solved problem. Twenty years later, enterprises are wiring large language models into customer support, document processing, and autonomous agents — and rediscovering the same class of vulnerability in a nastier form. Prompt injection is what happens when untrusted content is interpreted as instructions. The difference this time: there is no equivalent of the parameterized query, and there may never be one. That changes how you have to defend.
Why the comparison fits — and where it breaks down
Both flaws share the same root cause: a system that cannot reliably distinguish data from code. SQL injection worked because the database executed whatever string reached it, whether typed by a developer or a stranger. Prompt injection works because a language model processes one undifferentiated stream of tokens — system prompt, user question, and the contents of whatever web page or PDF it just retrieved all arrive as text, and text can contain instructions. The comparison breaks down at the fix. SQL had a clean structural answer: separate the query template from the values, and the class of bug disappears. LLMs have no such boundary to enforce — instruction-following is the product, not a bug in it. OWASP has ranked prompt injection as the number-one risk for LLM applications since its first Top 10 for LLMs in 2023, and it remains unsolved at the model layer. That is why every serious defense today is architectural rather than a filter you bolt on.
| Dimension | SQL injection (2000s) | Prompt injection (now) |
|---|---|---|
| Root cause | Data concatenated into executable queries | Untrusted content interpreted as model instructions |
| Entry points | Form fields, URL parameters, cookies | Chat input, plus every document, email, web page, or database record the model reads |
| Blast radius | One database | Everything the agent can touch: email, files, APIs, purchases, other systems via tool calls |
| Structural fix | Parameterized queries — clean separation of code and data | None at the model layer — defense must be architectural |
| Industry status | Largely solved by frameworks and secure defaults | OWASP LLM01 — the top-ranked LLM application risk, still open |
Anatomy of an attack: it's the agent era that raises the stakes
Direct injection — a user typing adversarial instructions into the chat box — is the variant everyone knows, and the least dangerous. The serious threat is indirect injection: adversarial instructions hidden in content the model was going to read anyway. A resume that tells the screening bot what verdict to reach. A web page with invisible text instructing the browsing agent to forward the user's data. A calendar invite that tells an email assistant to search the inbox and exfiltrate what it finds. The user never sees the payload, and the model encounters it mid-task, wrapped in exactly the kind of content it was told to trust. Connect that model to tools — send email, call APIs, write files, browse — and a successful injection stops being a weird chatbot reply and becomes an unauthorized action taken with the user's own permissions. That is the qualitative shift from the SQL era: the interpreter now has hands.
The attack patterns worth threat-modeling cluster into a handful of families, each with a different failure mode.
| Family | How it works | Typical impact |
|---|---|---|
| Direct injection | Adversarial instructions typed straight into the interface | Policy bypass, off-brand or harmful output, prompt disclosure |
| Indirect injection | Payload hidden in retrieved content — web pages, documents, emails, RAG results | Hijacked agent behavior during legitimate tasks |
| Data exfiltration | Injected instructions route sensitive context out — e.g. into generated links, images, or outbound tool calls | Leakage of conversation history, retrieved records, credentials in context |
| Tool abuse | Injection steers connected tools: send email, modify records, make purchases, call internal APIs | Fraud, unauthorized transactions, lateral movement |
| Memory / knowledge poisoning | Payload gets stored — in agent memory, vector stores, or KBs — and re-triggers on future sessions | Persistent compromise that survives the original session |
Defense in depth: there is no single fix, so build layers
Because the model itself cannot be made injection-proof, mature teams assume some injections will land and design so that a successful one is worth little. Two principles anchor everything. Treat everything the model reads as untrusted input — including your own knowledge base, because someone else wrote what's in it. And treat everything the model produces as untrusted code — outputs that trigger actions deserve the same scrutiny as user input hitting an API. From those two principles, the practical layers follow: least-privilege tool design, isolation of untrusted content, filtering, human approval gates on consequential actions, and continuous monitoring. Each layer is imperfect; the point is that an attacker has to get through all of them.
| Layer | What it prevents | Honest limitation |
|---|---|---|
| Least-privilege tools | Caps the blast radius — a hijacked agent can only do what its narrowest credential allows | Requires real design discipline; convenience constantly pushes toward broad scopes |
| Content isolation | Reduces how often retrieved data is mistaken for instructions | Delimiters and markers help; none are watertight against a determined payload |
| Input/output filtering | Catches known patterns; allowlists block exfiltration routes like arbitrary URLs | Classifiers trail novel attacks — filtering is a seatbelt, not a wall |
| Human approval gates | Stops the worst outcomes: money moved, data sent, records destroyed | Approval fatigue is real — gate the consequential few, not everything |
| Monitoring & red-teaming | Finds what got through; audit trails make incidents reconstructable | Only works if someone owns the alerts — tooling without ownership is theater |
The governance frame: OWASP, and treating AI apps like the software they are
The good news is that this is no longer a niche concern with no vocabulary. The OWASP Top 10 for LLM Applications gives security teams a shared taxonomy — prompt injection sits at LLM01, alongside insecure output handling, data poisoning, and excessive agency, which is OWASP's apt name for giving an agent more tools and autonomy than its task justifies. Regulators are converging on the same expectations through a different door: the EU AI Act's requirements for robustness and human oversight, and sector rules on data protection, effectively mandate the architecture described above for high-risk deployments. The practical governance move is to stop treating LLM apps as a special category and start putting them through the same gates as any internet-facing software: threat modeling in design review, security testing before launch, pen-testing after, and an incident-response runbook that names an owner. If your SDLC would not let an unauthenticated API ship, it should not let an over-privileged agent ship either.
Where to start: the first 90 days
Most organizations do not need a research program; they need an inventory and some discipline. The first month is discovery: find every LLM-powered app in the building — including the unofficial ones — and record what each can read and what each can do. The tool list matters more than the model name. The second month is hardening the highest-risk apps: tighten tool scopes, add approval gates on consequential actions, strip or sandbox untrusted content sources, and put allowlists on outbound routes. The third month is verification: red-team the hardened apps with your own injection payloads, wire tool-call logging into your SIEM, and make LLM security review a standing item in change management rather than a one-time project.
SQL injection took a decade to tame. Start now.
The SQL injection era ended not because attackers gave up, but because the industry changed its defaults: frameworks made the safe path the easy path, and a generation of developers internalized that user input is never code. Prompt injection is earlier on the same arc, with one hard difference — the interpreter at the center of it cannot be patched into perfect obedience, and the same property that makes it vulnerable is the one that makes it useful. So the defaults have to live in your architecture instead: narrow tools, isolated content, gated actions, logged everything. Enterprises that internalize this now will ship AI capabilities their competitors are still afraid to turn on — not because they took more risk, but because they engineered it down to a size they could accept.
How exposed are your LLM-powered apps right now?
Apptad helps enterprises build and harden AI applications — least-privilege agent architectures, guardrails and approval gates, red-team testing, and the governance to keep it all auditable. Let's start with an inventory of what your AI can already touch.
Talk to Apptad →Explore Capabilities
