You already know the attack. Untrusted data lands in the model's context carrying an instruction, the model can't tell it apart from yours, and the agent runs the attacker's errand instead of the user's. What I want to work through is the defense side, because that's where the arguments are still live. Which of these actually shrinks your blast radius, which ones just decorate a slide, and where any of them has to live before it can do a single useful thing.
This is for people building or reviewing agent deployments right now. I'll group the controls by where they live, give you the numbers behind each family, and be specific about what gets through anyway.
The request path is the map
Draw a line from the moment outside text reaches your system to the moment your agent does something irreversible. Everything you might buy or build sits at one spot on that line. Text arrives, it gets packed into a prompt, the model writes something back, and then your code runs whatever tool calls it asked for. A guard posted at one spot can do nothing about a weakness at another. That's the most useful lens I know for reviewing an agent design, and most of the broken ones I've looked at broke the same dull way, by parking a check somewhere it could never observe the behavior it was meant to catch.
Four buckets keep showing up in the literature, and they sort neatly by where they live. Training work fine-tunes the backend model. Detection work bolts on a separate checker that reads incoming text before the agent ever sees it. Prompt-augmentation work rewrites your system prompt and hopes the wording holds. System-level work borrows from ordinary security engineering, so you get sandboxing and privilege limits wrapped around whatever the agent is allowed to do (PromptArmor).
Figure 1: The four families and the point on the path where each one acts. Three of them decide by asking a model what counts as an instruction, and that's the property that degrades under an attacker who adapts. The system-level family decides on something the injected text can't argue with.
Hold that four-way split in mind. I'll walk it from the family with the weakest evidence to the one with the strongest, because they're not equal, and treating them as interchangeable checklist items is how you end up with a defended-looking system that folds the first time somebody adapts to it.
Prompt augmentation is the family to stop counting
Start with the one most teams reach for first, because it's free and ships in an afternoon. Prompt augmentation means telling the model to behave. You wrap fetched text in delimiters, repeat the user's real goal underneath it, and tack on a line telling the model to disregard anything that fights its original job (PromptArmor).
Here's what it buys you. On AgentDojo with GPT-4.1 as the backend, an undefended agent sits at 54.53% attack success. Add a delimiter and it drops to 51.51%. Repeating the user prompt does better at 29.89%, which still means roughly three attacks in ten land (PromptArmor). Those are the measured numbers, and a three-point improvement is inside the noise of a control that costs you nothing.
The reason isn't that nobody has found the right wording yet. Models have trouble telling instructions from data even when you hand them explicit delimiters, which Perez and Ribeiro showed back in 2022 (Ignore Previous Prompt), and which Simon Willison has been saying in plainer language ever since (Delimiters won't save you). It's an architectural property of how these systems read text, not a prompting problem waiting on a better prompt.
Carry that into your next architecture review. When the boundary between what your app told the model and what some random webpage told the model lives in a sentence of English, you don't have a boundary, you have a preference. A delimiter is a polite request, and hostile text talks the model out of polite requests for a living. Keep it if you like, since it costs nothing and it does shave a few points. Just don't put it on the control list and tell your board the gap is closed.
Detection got better, and it's still the layer attackers aim at
Detection means bolting a second, usually cheaper model onto the front door and asking it to flag hostile text before anything downstream reads it (SIC). The whole category has a reputation for being flimsy, and some of that reputation has aged badly.
The common belief was that an off-the-shelf model can't be prompted into defending against injection. The PromptArmor team argues that belief rests on two weak foundations, since earlier studies used older models with weaker instruction-following and their prompting strategies weren't carefully designed (PromptArmor). Write the prompt properly and the numbers move hard. With GPT-4o, GPT-4.1, or o4-mini wearing the guardrail hat, they got both error rates under one percent on AgentDojo, false alarms and misses alike, and once the flagged text was stripped out the success rate for attackers fell under one percent as well (PromptArmor).
One detail in that result is worth more than the headline. The guardrail model stays vulnerable itself. Attacks reach a 55% combined success rate against an agent running GPT-4.1 as its backend with no defense, where combined means the attempt counts as a win if any one of four attack templates lands (PromptArmor). Point that same family of model at the text as a judge rather than as the thing doing the work, and it spots the hostile lines anyway. Judging is a far smaller job than acting safely, which is why something you can trick into behaving badly can still be trusted to say "that looks wrong."
Now the other side, and this is the part I'd want in front of anyone about to buy a guardrail. The SIC authors went after detect-then-rewrite defenses directly and named PromptArmor as the target. Their StubbornRewriting attack bypassed the unchunked classifier in 99% of synthetic cases, and chunked classification only pulled that down to 25% (SIC). Sub-one-percent against the four templates a benchmark ships with, and near-total failure against an attacker who iterates on your classifier, are both true at once. Which number you get depends entirely on whether anyone is actually trying.
Figure 2: The same five defenses, measured twice. PromptGuard under an adaptive attacker lands exactly where running nothing lands, and ProtectAI ends up worse than nothing. The two conditions are separate evaluations inside the same paper (SIC, Tables 1 and 2), so read the gap as a direction rather than a controlled delta.
Iterating the sanitizer raises the bar and publishes its own ceiling
Most scrubbers get one look. They scan, they strip or reject, they hand off. You can see the hole from here, since anything that one look misses sails straight into the agent.
SIC runs the look again and again. Each round it hunts for anything phrased as a command aimed at the agent, then rephrases it, blanks it out, or deletes it, and goes back around for another sweep. The loop runs until the input is clean or it hits a maximum iteration count, and if instruction-like content still remains the agent halts instead of proceeding (SIC). The design assumes any individual rewrite can fail and uses repetition to catch what earlier passes missed. On the standard AgentDojo attacks it drives attack success to zero.
I keep citing this one in reviews because the authors publish their own ceiling. They say flatly that the method is not provably robust, and under a genetic-algorithm adaptive attack with full white-box knowledge of the system, a strong adversary still reaches 15% attack success by embedding non-imperative workflows rather than direct commands (SIC).
Read that 15% against the rest of the table before you decide how to feel about it. Under the same attack, no defense at all gives 75%, MELON gives 71%, PromptGuard gives 75%, PIGuard gives 49%, and one commercial detector came in at 81%, worse than running nothing (SIC). That 15% is the best result anyone posted, by a factor of three over the runner-up, and it's still one in seven. Treat every sanitizer as a probabilistic filter with a published residual rather than a gate, and then go ask what catches the fraction that gets through.
System-level defenses are the ones that hold their shape
The family with the strongest structural case is the one that stops asking the model to police itself. This family steals its ideas from systems engineering rather than from copywriting. Sandboxes pen the agent into a stripped-down environment where very little is reachable. Flow tracking follows where outside text is allowed to travel and refuses to let it arrive at a sink it has no business touching. Privilege limits cut the menu of operations down to what the job genuinely needs (SIC, PromptArmor).
I want to be careful here, because the strong version of this argument is wrong and I've seen people make it. System-level controls are not immune to adaptive attack, and the input-side controls above are not useless. SIC is an input-side defense and it posted the best worst-case number in its own comparison. The real difference is what each family's failure looks like. When a detector fails, the attacker's instruction reaches a model that will act on it. When a privilege control fails, the attacker still has to find a dangerous action that the control permits.
That's why the far end of the path matters more. A prompt injection that reaches the model still can't exfiltrate data if the agent has no privilege to reach the network, and it can't move money if the transfer tool sits behind a control that injected text can't satisfy. You've stopped asking the model to refuse a bad instruction and started making sure a bad instruction has no reachable dangerous action even when the model complies fully.
This is also where the standards framing earns its keep. Prompt injection is LLM01, the top entry in the OWASP Top 10 for LLM Applications (OWASP), and it sits there precisely because the model can't self-separate instruction from data. Any control that assumes it can is building on the vulnerability itself.
How to review a deployment
Walk that line and ask the same two things at every stop. Where does outside text get in, and who holds authority over the thing that happens at the far end.
When nothing stands between a hostile paragraph and a dangerous tool call except some nicely phrased English, you're running without protection in the only sense that matters, however good that English looks. Where a checker guards the front door, ask for its miss rate against somebody adapting, not the number on its product page, and assume whatever slips past lands in front of the model anyway. Where privilege limits wrap the tool calls, ask the blunter question: if the model swallows the bait whole, what is the single worst thing it is still permitted to do? Your answer to that is your exposure. Write it down before you ship.
The controls that reduce exposure are the ones placed where they don't depend on the model telling instruction from data. Everything upstream of that lowers volume, which is worth having, and none of it should be your last line. Build accordingly.