The prompt injection field guide.

What this covers, and what it does not.

This guide is about the security of systems that put a language model in the middle of a workflow. A support assistant that reads tickets. A coding agent with shell access. A search product that summarises pages it did not write. Anything where text arrives from somewhere you do not control and a model acts on it.

It is not about model alignment research, and it is not about training-time safety. Those matter, but they are decisions made by whoever built the weights. This guide stays inside the part you own: the application around the model.

Three conventions run through everything below.

• Defender's seat. Every technique is described by its tell and its cost, not as a recipe. You will not find a working payload here.
• Two numbers, always. A defence is never described only by what it stops. It is described by what it stops, what it misses, and who it blocks by mistake. See section 06.
• Named risks. Where something maps to an OWASP LLM Top 10 (2026) entry, it is labelled, so what you learn here has a name you can bring into a design review.

Everything follows from one defect.

A language model receives one stream of tokens. Your system prompt, the user's message, the document your app retrieved, the output a tool returned — by the time any of it reaches the model, it is a single flat sequence. There is no privileged channel. There is no bit on a token that says this part is an instruction and that part is only data.

So when a retrieved page contains a sentence shaped like an order, the model is not confused. It is doing exactly what it was built to do: continue the most plausible text. An instruction inside a document looks like an instruction.

Which reframes the whole job. The question stops being how do I detect every hostile string and becomes what can this model actually do, on whose authority, and what does it touch on the way out. Detection still earns its place — it is cheap, and it catches the loud majority — but it is the outer skin, not the skeleton. The skeleton is architecture.

The seven layers of the attack surface.

Most LLM security advice is a flat list, which makes it hard to tell whether you have covered anything. Layers help, because a control belongs at a layer, and you can ask a straight question of each one: what crosses this boundary, and do I trust it?

The OWASP LLM Top 10, mapped onto the layers.

The OWASP Top 10 for LLM Applications (2026) is the closest thing this field has to shared vocabulary. It is a list of risks, not a list of controls, so the useful move is to place each one on a layer and then ask what genuinely moves the needle there. The 2026 edition renumbered eight of the ten entries and renamed one, so the old number is shown alongside the new one wherever it changed.

A shorter version, if you only remember one line: LLM01 is the way in, LLM03 is why it hurts, and LLM10 is how it gets out. The middle of that chain is the part you control most cheaply.

Choosing a defence: filter, constrain, isolate, confirm.

Four shapes cover almost every control you will build. They are not ranked, and they are not alternatives — a real system uses all four at different layers. What matters is knowing which shape you are reaching for, because each one fails in its own way.

Each of these is written up with components, tradeoffs and failure conditions in the defence pattern library.

The two numbers, and the arithmetic nobody runs.

Every guardrail produces two failures. It misses attacks, and it blocks real people. Optimising either one alone is trivial and useless: allow everything and you never annoy a customer, block everything and you never suffer a breach. Neither is a filter. Detection calls these recall and precision; the point of naming them is that you cannot move one without paying in the other.

The part that surprises people is what happens when you multiply by real traffic.

Three consequences worth internalising:

• A false positive rate is only meaningful next to your traffic volume. "2%" is a number about you, not about the attacker.
• Blocking is not free, and the bill goes to someone. Usually the security trainer asking a fair question, the customer writing in a language your training data under-represents, or the developer whose legitimate work now looks suspicious.
• This is the argument for isolation. A control that reduces the value of a successful attack has no false positive rate at all. That is the whole reason section 05 puts it first.

You can run these numbers against your own traffic in the base rate calculator, and you can feel the tradeoff one decision at a time in the free unit of the training, which scores you on both counters.

How real deployments fail.

Not theoretical weaknesses — the recurring shapes. If you are reviewing a system, this is a decent checklist to read down.

• The prompt holds the security policy. Authorisation written as "never reveal data belonging to another customer" rather than enforced in the query. Instructions are advisory. Code is not.
• Retrieval is not treated as an input. The user's message is scrutinised; the 40KB of retrieved context sitting next to it is not.
• The agent runs as an administrator. One service account, full scopes, because scoping per task was going to be a follow-up ticket.
• Output goes somewhere with teeth. Model text rendered as raw HTML, passed to a shell, or concatenated into SQL. Old bug, new source of strings.
• The exfiltration leg is wide open. The model can be told what to leak and also has a way to send it — an image URL it can construct, an outbound fetch, a link it can render. Read, act, and send, all in one session, is the combination that turns an injection into an incident.
• Confirmation without comprehension. A dialog that says "run this tool?" without showing what the tool will do, to what, on whose behalf.
• Memory that persists an attack. An injection written into long-term memory keeps firing in sessions that never touched the poisoned document.
• No budget on the loop. A single request that fans out until the bill or the rate limiter notices.
• Nobody logs the guardrail's decision. You cannot compute either of your two numbers after the fact if you only stored the blocks and not the allows.
• Nobody appeals. There is no route for a wrongly blocked user, so your false positive rate is invisible and therefore, on paper, zero.

Contested ground.

Places where competent people still disagree. Presented as disagreements rather than settled advice, because pretending otherwise is how a field guide goes stale.

Can prompt injection be solved at the model layer?

One camp says instruction hierarchies and better training will eventually make models reliably prefer the system prompt. The other says a probabilistic system can be persuaded given enough attempts, so containment is the only durable answer. Where it stands: models have measurably improved at ignoring obvious injections, and adaptive attacks keep finding the ones that work (The Attacker Moves Second, 2025). Build as if it is unsolved.

Guardrail models, or architecture?

Detection vendors report strong benchmark numbers. Architectural approaches such as CaMeL argue for provable containment by separating control flow from data flow, at the cost of capability and engineering effort. Where it stands: benchmark scores for detectors tend to fall under adaptive attack (Are Firewalls All You Need?), while containment is real but slower to build. Most production systems will do both, and should be honest about which one is load-bearing.

Is "just don't give it dangerous tools" a real answer?

It is the most effective advice available and also the one product teams reject, because the tools are the product. Where it stands: the practical version is not removing capability but binding it — per-task scopes, per-step allow-lists, and a human on anything irreversible. If a capability cannot survive that, it probably should not ship yet.

Does publishing attack taxonomies help defenders or attackers?

The usual disclosure argument, with an LLM accent. Where it stands: the attacks are already widely circulated and largely obvious to try; defenders are the ones missing shared vocabulary. That is the reasoning behind the attack index here describing tells and costs rather than shipping payloads.

Questions.

Where to go next.

Four routes out of here, depending on what you came for.