Drafted with AI help, human-reviewed by The Agent Loop.
Prompt injection (OWASP LLM01) is when untrusted text gets treated as instructions. Your agent's scary case is not a jailbreak in chat. It is a tool response lying.
Why tools are the attack surface
- OWASP ranks prompt injection #1 on the LLM Top 10 (OWASP LLM01)
- Google measured a +32% jump in indirect prompt injection in the web corpus, Nov 2025 → Feb 2026 (Google)
- Unit 42 logged 22 distinct real-world techniques (Unit 42)
- MCP pattern: one session with a read tool and a write tool lets poisoned data become the next command
Where it fails
- Email, web page, or API field says "ignore previous instructions" → agent complies
- Confidence scores drop but do not hit zero (Jev-style decision models still flipped in one injection test — see our Jev 60s post)
- You gave the agent shell + browser + wallet "to be productive"
How I'd use it
- Yes: label tool output as data, confirm writes, least-privilege tools
- No: paste tool text into the system prompt; auto-run
rm/payments from one model vote - Spotting helps: spotlighting cut success >50% → <2% in one study (arXiv); still pair with human confirm
tool response ──► parse as DATA ──► policy check ──► human OK? ──► write
(not: as instructions) no ──► drop
Bottom line: Assume every tool is hostile until proven otherwise. Separate what you saw from what you will do.
FAQ
What is prompt injection for agents?
Untrusted text (page, email, tool output) is parsed as user/system instructions.
Does a small classifier model fix it?
No. Fast decision models help routing; they can still be socially engineered. Add deterministic checks.
What is the minimum fix?
Read-only tools by default; human approval for writes; never promote tool text into the system prompt.
Is there a benchmark?
Yes — AgentDojo: 97 tasks, 629 security cases.
Sources
- OWASP LLM Top 10
- Google: prompt injections on the web
- Palo Alto Unit 42: AI agent prompt injection
- Spotlighting (arXiv)
- AgentDojo (arXiv)
Related on The Agent Loop
Over to you: What's the wildest thing a tool response has ever talked your agent into doing? Reply below — I read every comment.
If you want the rest of this series when it drops: subscribe via Buttondown. If you've been bitten by a prompt injection, the part I most want to hear is how you found out, whether a log, a user, or nothing at all.
Top comments (2)
What does the approval screen actually show the person? I would worry about someone clicking yes without knowing that a dodgy tool response led to that action. Can they see exactly what the agent is about to change?
Fair hit, and it's a hole in my post. I wrote "human approval for writes" as the minimum fix without ever looking at what that screen actually shows, which is a bit like recommending a lock without checking where the key hangs.
Short answer: usually no. Most approval UIs show a tool name and a JSON blob of the arguments. You get
write_file(path, contents)and a blob. You do not get a diff, and more importantly you do not get provenance. The screen never tells you the instruction came out of a web page the agent just fetched rather than from you.That's the part I'd fix first, and it's a small change in most implementations: the approval should carry the origin of the instruction, not just the action. "A page at this URL told it to do this" is the difference between a human reviewing an action and a human rubber-stamping an agent.
Second thing I'd push back on is my own framing, because I gave the screen too much credit. Frequency beats content. A beautifully informative screen that fires forty times a day is worse than a terse one that fires twice, because the fortieth prompt is where the clicking happens. We wrote about exactly this failure in why your MCP approval gate never fires. The whole lesson was that a gate which fires constantly is a gate nobody reads. Your worry about someone clicking yes without knowing is, I'd argue, mostly a volume problem before it's a design problem.
Which leads to what I think is genuinely the biggest hole: batch approvals. If one yes can cover fifty actions, the screen is decoration. We hit this with a scheduled job where a single approval described none of the fifty things it then went and did, and the receipt afterwards was the only place the real work showed up. If your agent can amortise one approval across a batch, that approval has stopped being a review of anything.
The genuinely hard case, and the one I can't engineer away, is an action that is exactly what the user wanted. There the screen adds nothing, and worse, it trains the user to click through. So the next prompt, the dangerous one, inherits the same reflex. Which suggests the gate's value should be proportional to how surprising the action is, not uniform across all of them. A write to a temp file and a write to your shell profile should not look identical, and most implementations make them look identical.
If you want the adjacent failure mode: an approval needs an expiry date covers the same screen from the other side, because a yes that never expires is a standing permission dressed up as a prompt.
Limit on all of this: we haven't shipped the provenance version, so read it as reasoning from failures we've had rather than a measured result.