LLM01: Prompt Injection — The Three-Axis Framework Nobody Reads
Part 1 of 6 in a series going through the OWASP LLM Top 10 one category at a time
If you’re building anything with LLMs in production, there’s a good chance you’ve heard of the OWASP LLM Top 10 without actually reading it. It’s the closest thing the industry has to a shared vocabulary for AI security risks — but the actual document is dense, heavily cited, and easy to skim past without absorbing the parts that matter.
Here’s what’s worth knowing from the LLM01 entry specifically, especially if you’re building RAG systems, agents, or anything with retrieval.
Why LLM Security Is a Different Problem
Traditional application security has a clear boundary: code is trusted, input is untrusted. SQL injection exists because you can parameterize queries to separate the two.
LLMs don’t have this boundary. The system prompt, the user’s question, retrieved documents, and tool outputs are all just tokens on the same stream. There’s no equivalent of a parameterized query — the model reads everything as potential instruction.
Three properties make this worse in real systems:
Context-window pooling. Everything shares one input — system prompt, user input, RAG documents, tool outputs, memory. No enforced trust boundary between them.
Memory persistence. An injection that writes to a vector store or RAG corpus doesn’t just affect one conversation — it poisons every future session that retrieves from that store.
Agentic execution. When a model’s output drives tool calls — file systems, APIs, email, MCP servers — the blast radius of a successful attack extends from the chat window to everything the agent’s tools can reach.
The Three-Axis Framework
The most practically useful thing in the entire OWASP LLM01:2026 document, is a framework for classifying attacks along three independent axes:
(a) Delivery surface — how the malicious content reaches the model. The document breaks this axis down into three trust levels, worth using directly to audit your own system:
Untrusted surfaces — public web pages, emails from unknown senders, public files, search results. Treat as suspicious by default.
Semi-trusted surfaces — issue titles in a public bug tracker, package READMEs and changelogs, third-party API responses. You trust the platform, not necessarily every contributor on it.
Trusted surfaces — code in a repository you own, rows in your own production database, internal documents, your own emails or calendar. This is the dangerous blind spot: you don’t expect an attacker here, but they can plant content via an unrelated upstream vector — a public bug-report form, a customer support ticket — that eventually lands somewhere you implicitly trust.
The shared insight across all three: the attacker doesn’t need to compromise your backend directly. They place text somewhere your LLM will eventually read it, and your own system — operating with your own privileges — does the damage. A defense that only scrutinizes the “untrusted” tier misses attacks arriving through the trusted tier entirely.
(b) Propagation — how far the attack's effect spreads: a single response, a multi-step chain across several turns, cross-session via memory or RAG, or self-replicating across multiple agents. A single injected instruction that only affects one reply is a very different risk than one that poisons a shared knowledge base for every future user.
(c) Encoding — how the payload is hidden: plain text, base64, invisible Unicode characters, or steganography embedded in an image or audio file. A payload hidden inside an image's pixel data can pass through a text-only content filter untouched, since the filter never sees anything resembling suspicious text.
Every real attack is a combination of one item from each axis. A documented proof-of-concept against Microsoft 365 Copilot (August 2024) combined document-based delivery (a trusted-surface- adjacent channel), a single-shot tool-invocation chain, and invisible Unicode encoding — three axes, one attack.
The practical exercise worth doing: list your system’s actual input sources and sort them into the three trust levels above. Most teams have only defended the first one.
The Finding That Should Change How You Think About RAG
As few as five documents injected into a RAG corpus achieved attack success rates above 95% on standard question-answering corpora, according to PoisonedRAG (Zou et al., USENIX Security 2025). You don’t need to compromise the backend, the model weights, or the infrastructure. You just need to get five documents into whatever corpus your RAG system retrieves from.
If your RAG pipeline ingests from any source you don’t fully control — scraped web content, user uploads, shared drives, third-party APIs — this number should worry you more than almost anything else in the document.
Five Mitigations Worth Actually Implementing
The OWASP document lists eleven mitigations. Five are worth prioritizing:
Minimum permissions. Hold API credentials and sensitive operations in application code, not in the model’s context. The model should request an action; application code should decide whether to perform it.
Human confirmation before irreversible actions. Any action that sends, deletes, or modifies something outside the conversation should require explicit confirmation — not because the model can’t be trusted, but because a single injected instruction shouldn’t be able to act unsupervised.
The Rule of Two. If an agent has (A) untrusted input, (B) access to sensitive data, and (C) the ability to change state — require human approval before any action. Having all three simultaneously is the actual danger zone; most production agents have this without realizing it.
Treat memory writes as privileged operations. Anything written to a persistent store — a vector database, a long-term memory system — should be logged with its source and, ideally, screened for embedded instructions before it’s trusted by future sessions.
Pin, sign, and verify MCP servers. As agent tooling spreads through the Model Context Protocol, the tool descriptions themselves become an attack surface. A malicious tool description can hijack agent behavior before the user ever types anything.
Numbers Worth Remembering
5 documents, attack success rates above 95% — PoisonedRAG, Zou et al., USENIX Security 2025
~90% attack success rate for adaptive attacks against defenses that showed near-zero success rate under static testing — Nasr & Carlini, “The Attacker Moves Second”, arXiv:2510.09023, October 2025
A defense benchmark measuring only static attacks tells you very little about resistance to an adaptive adversary who knows the defense exists.
What This Means If You’re Building RAG
Any RAG system that ingests from a source it doesn’t fully control — user uploads, scraped web content, shared drives, third-party APIs — is vulnerable to what the document calls indirect prompt injection and RAG repository poisoning, both covered directly in this entry.
The uncomfortable pattern across the document’s mitigations is how little of the burden falls on the model itself. Almost every effective defense lives in the application layer — permission boundaries, human confirmation, provenance tracking on what gets ingested. The model is not going to solve this problem for you.