Prompt injection is the class of attack where adversary-controlled text is read by a large language model as instructions to follow rather than data to process. OWASP ranks it LLM01, the top risk in its Top 10 for LLM Applications, and there is no complete fix today. This page goes deep on injection as its own discipline: the direct and indirect attack surface, the confused-deputy problem that makes AI agents dangerous, and the layered defenses that shrink the blast radius. The retrieval-specific channel, poisoned documents and vector stores, is covered in the RAG security pillar.
Prompt injection is a class of attack in which adversary-controlled text is interpreted by a large language model as instructions to follow rather than as data to process. The core insight is architectural: an LLM receives one flat token stream and has no reliable, enforced boundary between the developer's instructions and the content it is asked to operate on. Whatever channel the words arrive through, the model weighs them as candidate instructions. There is no built-in privilege bit that marks some tokens as trusted commands and others as inert data.
Prompt injection comes in two shapes. Direct injection is when the attacker submits the malicious instruction straight into the prompt, for example typing an override into a chat box. Indirect, or cross-domain, injection is when the malicious instruction is planted in third-party content the model later reads, a web page, an email, a document, or a tool result, so the attacker never interacts with the model directly and the payload rides in on content the application trusts. OWASP ranks this whole class as LLM01, its top LLM application risk.
Classic injection attacks like SQL or shell injection have a formal grammar, so you can parameterize, canonicalize, and escape the payload before it reaches the interpreter. Natural language has no escape character and no grammar you can normalize against, and the model is simultaneously the parser and the executor, so there is no separate stage where you can neutralize the instruction before it takes effect.
The second reason it is hard is the source problem. Injected instructions can arrive from any content the model reads, and in an agent that means web pages, emails, PDFs, retrieved documents, and the outputs of other tools. You cannot enumerate that input space, and much of it is attacker-controllable. Any filter you add is a probabilistic classifier that raises the attacker's cost, not a parser that closes the hole. Plan on defense in depth, not a single gate.
The concrete surfaces map to how untrusted text reaches the model and what the model can do next. System-prompt override is the direct case: user text that instructs the model to ignore prior instructions, reveal its system prompt, or drop its guardrails. Indirect injection via retrieved or browsed content is the higher-leverage case, where the payload is embedded in a page, email, or document the model ingests. The retrieval and vector-store specifics of that channel are covered in the RAG security guide, so treat it here as one more untrusted input that can carry instructions.
Tool-call hijacking is the agent-specific surface: injected text steers the agent into calling a tool, often with attacker-chosen arguments, turning a read task into a write, send, or delete. Multi-turn and memory poisoning plant instructions in conversation history or persistent memory so they fire on a later turn, past whatever review happened at ingestion.
Underneath all of these sits the confused-deputy pattern: the agent holds credentials, scopes, and tool access that the attacker does not, so an injected instruction executes with the agent's authority rather than the attacker's. The privilege gap is what converts a text trick into real impact.
| Dimension | Direct injection | Indirect injection |
|---|---|---|
| Source of instruction | The user's own prompt input, submitted straight to the model | Third-party content the model ingests later, such as a web page, email, document, or tool output |
| Attacker access needed | Must interact with the application directly as a user | Only needs to control content the target will later read, no direct access to the app |
| Typical target | The app's own system prompt, guardrails, or a single session | Any user or agent that consumes the poisoned content, potentially at scale |
| Hardest challenge | You cannot reliably separate natural-language instructions from data in one context | Untrusted content enters through channels you do not control and can look completely benign |
| Example vector | A chat message that says to ignore prior instructions and reveal the system prompt | A hidden instruction embedded in a web page or email that an assistant reads while summarizing |
There is no complete fix for prompt injection today. The realistic goal is defense in depth plus blast-radius reduction, so a successful injection does something small and recoverable instead of something catastrophic. Start with privilege separation and least-privilege tools: give the agent the narrowest set of scopes and actions it needs, so hijacking a tool yields little. Consider dual-LLM or quarantined-LLM patterns, where a privileged planning model never sees raw untrusted content and a separate quarantined model processes untrusted content but cannot call side-effecting tools, with only structured, validated data passing between them.
Put deterministic allow-lists in front of side-effecting actions, so the permitted operations and targets are enforced in code rather than decided by the model. Parse and validate all model output, and treat every token the model emits as untrusted: never pass it straight into eval, exec, a shell, a SQL string, or another tool without checking it. Finally, require human confirmation for irreversible actions, the ones that spend money, send communications, or cannot be undone. Each layer is imperfect, which is exactly why you stack them.
Measure exposure, not vibes. Stand up a red-team injection test suite, track which agent actions are side-effecting versus read-only, and measure how many of your irreversible actions actually sit behind a human-confirmation gate. MITRE ATLAS is a useful reference for framing the adversarial-ML tactics your test suite should cover.
A maintained battery of direct and indirect payloads run through the real agent, scored pass or fail so regressions surface and releases can gate on it.
Of all actions the agent can take, the share that write, send, pay, delete, or execute. That is where injection turns into damage.
Share of money-moving, message-sending, and non-undoable operations that require an explicit human approval before running.
The scopes and data each tool can reach. Tracking it alongside the others gives an auditable picture of blast radius, not a claim of safety.
Injection often rides in through retrieval. See the RAG-specific channel next.
RAG security guide