Most security vulnerabilities have a fix. SQL injection was solved by parameterized queries — the database gets the query structure and the user data through separate channels, so no amount of clever input can turn data into commands. Engineers reasonably assume prompt injection is the same shape of problem awaiting the same shape of solution. It isn't. Prompt injection sits at number one on the OWASP Top 10 for LLM applications, and the uncomfortable truth is that there is no parameterized-query equivalent, because the thing that makes it possible is the same thing that makes language models work.
What it is
OWASP defines it plainly: "A Prompt Injection Vulnerability occurs when user prompts alter the LLM's behavior or output in unintended ways." You wrote a system prompt telling the model to be a polite customer-service bot; a user writes something that persuades it to be something else entirely.
The root cause is architectural. A model receives one flat sequence of tokens. Your carefully written system prompt, the retrieved document, and the user's message all arrive in the same context window with no cryptographic or structural boundary between them. To the transformer, all tokens are equal — there is no privileged channel that says "these are the real instructions and everything after this point is inert data." Whether a sentence gets treated as an instruction or as content is a matter of the model's learned judgment, not enforcement. That is why a
Direct and indirect
OWASP splits the risk in two, and the second half is the one that catches teams off guard.
Direct prompt injection "occurs when a user's prompt input directly alters the behavior of the model in unintended or unexpected ways." This is the familiar version — a user typing something adversarial into your chat box to extract the system prompt or bypass a restriction. It's the one everyone tests for.
Indirect prompt injection "occurs when an LLM accepts input from external sources, such as websites or files." Here the attacker never touches your application. They plant instructions in content your system will later ingest — a web page your agent browses, a PDF in your RAG index, a code comment, a support ticket, an email. When that content lands in the context window, the model may follow it.
Indirect injection is the serious one for agents, because it inverts the trust model. Your retrieval pipeline may be perfectly secure and still deliver a hostile payload, since the retrieval being trusted says nothing about the content being trustworthy. The moment your agent reads the open internet, anyone who can influence what it reads can attempt to influence what it does.
Why it can't be patched away
OWASP is refreshingly blunt about the ceiling here: "Given the stochastic influence at the heart of the way models work, it is unclear if there are fool-proof methods of prevention for prompt injection."
That sentence deserves to be read twice, because it reframes the whole problem. This is not a filter that needs tightening or a model that needs more safety training. Instruction-following is the product. A model that could not be talked into changing its behavior by text in its context would also be a model that couldn't follow your instructions. Detection heuristics and classifiers raise the cost of an attack, and they're worth deploying, but they are probabilistic defenses against an adversary who gets unlimited attempts to rephrase.
So stop designing for prevention and start designing for containment: assume the model will eventually be successfully injected, and make sure that when it happens, nothing catastrophic follows.
Containing the blast radius
This is where the tool-calling architecture becomes your security boundary. The model never executes anything — it only proposes a call, and your code decides whether to honor it. That gap is where real enforcement lives. OWASP's mitigations map onto it directly:
- Enforce privilege control and least privilege. Give the agent its own credentials with the narrowest possible scope. An injected agent that holds a read-only token scoped to one table is an incident; one holding an admin key is a breach.
- Require human approval for high-risk actions. Sending money, deleting data, emailing customers, pushing code — put a person in the loop. Deterministic, and immune to whatever the model was persuaded to want.
- Segregate and identify external content. Mark clearly which parts of the context came from untrusted sources so both your prompt and your downstream checks can treat them accordingly.
- Constrain behavior and validate output formats. Define what a valid action looks like and reject anything outside it, rather than trusting free-form output.
- Filter input and output, and run adversarial testing — red-team your own agent the way you'd pen-test an API.
# Illustrative: enforcement lives in YOUR code, not the prompt
ACTION = model_response.tool_call # untrusted proposal
if ACTION.name not in ALLOWED_TOOLS: # allowlist, not blocklist
reject()
if not schema_valid(ACTION.arguments): # validate types and ranges
reject()
if ACTION.name in HIGH_RISK: # money, deletion, outbound comms
require_human_approval()
execute_with_scoped_credentials(ACTION) # least privilege, alwaysThe pattern is the old one: never trust input, and put your controls where they can actually be enforced. The only difference is that with an LLM, the untrusted input is everything in the context window — including content your own systems retrieved.
Key Takeaways
- Prompt injection is OWASP's top LLM risk and occurs when prompts "alter the LLM's behavior or output in unintended ways."
- The cause is structural: instructions and data share one channel, and to the model all tokens are equal — there is no parameterized-query equivalent.
- Indirect injection (via web pages, files, or documents the agent ingests) is the dangerous variant for agents, since attackers never touch your app.
- OWASP itself states there are no known fool-proof prevention methods — so design for containment, not prevention.
- Enforce least-privilege credentials, human approval on high-risk actions, allowlisted and schema-validated tool calls, and adversarial testing.