Most security bugs are mistakes. Someone forgot to validate an input. Someone left a bucket public. Prompt injection is not a mistake. It is a consequence of how language models work.
An LLM reads instructions and data through the same channel: text. It has no reliable way to tell one from the other. If an attacker can place text anywhere the model will read, that text competes with your system prompt. Sometimes it wins.
OWASP ranks prompt injection as LLM01, the top risk for LLM applications, in both editions of its Top 10 for Large Language Models. At Zerotak, it is also the finding we report most often when we test AI features in production.
What Prompt Injection Actually Is
The comparison people reach for is SQL injection. It is close enough to be useful, and different enough to be dangerous. In SQL injection, the database parses commands and data from the same string. Sanitize the input, escape the characters, use prepared statements, and the class of bug goes away.
In prompt injection, the model interprets everything it reads as potentially instructive. There is no prepared statement for natural language. There is no escape character for “ignore what you were told earlier.”
Direct vs. Indirect Injection
OWASP splits the risk into two forms. The distinction matters, because they have very different blast radii.
Direct prompt injection happens when the user is the attacker. They type instructions into the chat window that override the system prompt. Reveal your configuration. Drop your safety rules. Act as a different assistant. The user attacks a session they already control. The damage is usually contained to that session.
Indirect prompt injection happens when the content is the attacker. The model reads an external source, and that source carries hidden instructions.
- A PDF resume with white text on a white background, telling the screening model to recommend the candidate
- A support ticket that instructs an agent to forward its context to an external address
- A web page that a browsing assistant summarizes, carrying commands inside a comment block
- A document in a RAG knowledge base, poisoned once, retrieved for every future query
The victim here is not the attacker. The victim is a legitimate user whose assistant just read something hostile on their behalf.
This is where the real incidents live.
Why It Gets Worse With Agents
A chatbot that leaks its system prompt is embarrassing. An agent that leaks your database is a breach.
The impact of prompt injection scales directly with what the model is allowed to do. Add tool calls, and injected instructions become actions.
- Read tools turn injection into data exfiltration
- Write tools turn injection into unauthorized transactions
- Code execution turns injection into remote code execution, through a text field
- Multi-tenant context turns injection into cross-tenant access
In Zerotak engagements we have found each of these. The pattern repeats: teams treat the LLM as a trusted component in the middle of an untrusted pipeline. It is not trusted. It is a parser that follows suggestions.
Why Traditional Pentests Miss It
A conventional web application pentest maps endpoints, tests authentication, and probes for injection at the protocol level. None of that surfaces prompt injection.
The payloads are semantic, not syntactic. The input space is unbounded, because it is human language. A payload that fails in English can succeed in base64, or in a low-resource language, or across three turns of conversation instead of one.
Testing an LLM application requires a different methodology:
- Prompt recon. Map every path where text reaches the model. User input, retrieved documents, tool outputs, file uploads, metadata fields.
- Semantic fuzzing. Adversarial payloads against every surface, measuring deviation from intended behavior rather than error codes.
- Trust boundary testing. Can retrieved content influence system instructions? Can tool output influence the next tool call?
- Agency review. What can the model do that it does not need to do?
- Output handling review. Is model output rendered as HTML, passed to a shell, or written to a query?
Zerotak runs this as a dedicated AI pentest, mapped to OWASP LLM Top 10 and cross-referenced with MITRE ATLAS, alongside the traditional web testing that the application underneath still needs.
What Actually Reduces Risk
There is no fix. There are controls that stack.
- Segregate untrusted content. Mark retrieved data clearly as data. It reduces success rates. It does not eliminate them.
- Constrain the model. Define expected output formats. Reject anything else.
- Enforce least privilege on tools. An agent that cannot delete records cannot be talked into deleting records.
- Treat output as untrusted input. Sanitize before rendering, executing, or querying. Improper output handling is where injection becomes exploitation.
- Put a human in the loop. For irreversible or high-value actions, require approval.
- Test adversarially, on a schedule. Model updates change behavior. A payload blocked last quarter may work today.
The last one is the one teams skip. Prompt injection defenses are probabilistic, and probabilistic defenses drift.
The Uncomfortable Summary
Prompt injection is not going away with the next model release. Instruction hierarchy research is progressing. It is not solved. The realistic goal is not an unbreakable model. It is an application where a successful injection does not reach anything worth stealing.
That is an architecture problem, not a prompt engineering problem. If you have shipped an LLM feature, or you are about to, it is worth knowing what an attacker can reach through it before someone else finds out.
Zerotak tests AI and LLM applications the way attackers approach them, from the prompt surface down to the tool layer.
Reach out at contact@zerotak.com.