Prompt Injection Is the New SQL Injection — and Agents Make It Worse

SQL injection taught the industry a hard lesson: when untrusted input reaches an interpreter, the input becomes code. Twenty years later, we are repeating the pattern with large language models — except this time the interpreter is the model itself, and the payload is plain English.

Why agents change the risk profile

A chatbot that produces text can be embarrassed. An agent that browses the web, reads your inbox, queries internal APIs, and files tickets can be weaponized. The blast radius of an injected instruction is no longer a bad answer — it is an action taken with your system's credentials.

• Indirect injection: hostile instructions hidden in web pages, documents, or emails the agent reads
• Tool abuse: coercing the agent into calling tools with attacker-chosen arguments
• Data exfiltration: smuggling secrets out through tool calls, links, or generated content
• Memory poisoning: planting instructions that persist across sessions

What we test in an agent security review

We treat every content source the agent touches as a trust boundary. For each boundary we ask: can content crossing it change the agent's behavior? Can that behavior reach a tool? Can that tool cause irreversible impact? The answers drive a severity model that engineering teams can act on — least-privilege tool scopes, human approval gates for consequential actions, isolation between retrieved content and instructions, and output filtering before anything leaves the sandbox.

Prompt injection is not fully solvable today. But like SQL injection, it is manageable with layered controls — if you design for it before the incident, not after.