AskpertPrompt Injection: Your Agent's Tool List Is the Attack Surface
Indirect prompt injection succeeds based on what an agent can reach, not which model it runs. The same model scored 92% attack success in one suite and 0% in another. Here is the containment checklist.
On this page
Terms, definedthe jargon, decoded
- Prompt injection
- An attack that places instructions in a model's input to make it act against the user's intent.
- Indirect prompt injection
- Instructions hidden inside data an agent reads, such as an email, a web page, or a tool output.
- Targeted attack success rate
- The share of security tests in which the attacker's specific stated goal is achieved.
- Benign utility
- How well the agent does its actual job when nobody is attacking it. Defenses that lower this are paying for security with usefulness.
- Tool filter
- A defense that restricts the agent to only the tools the current task needs, decided before untrusted data enters the context.
Most writing treats prompt injection as a model flaw, as though a better-aligned model would make it go away. The measured results say otherwise. Exposure changes by orders of magnitude depending on what an agent can reach, which makes this an architecture problem rather than an alignment one.
AgentDojo is the clearest evidence. It runs agents through "97 realistic tasks (e.g., managing an email client, navigating an e-banking website, or making travel bookings), 629 security test cases, and various attack and defense paradigms from the literature."
What is indirect prompt injection?
It is an attack where the instructions hide inside data the agent reads rather than in the user's own message. An email, a web page, a document, or a tool output carries text the model treats as a command, so the agent acts on instructions no authorized party wrote.
Direct injection is different: the attacker types the instruction into the prompt, so screening user input helps. Indirect injection arrives inside retrieved data, so the defense is controlling what data reaches the model and which tools remain reachable afterward.
The root cause is that instructions and data are the same token stream to a language model. A page the agent reads can tell it to ignore earlier directions, and the model complies, because following text is what it does.
Is prompt injection a model problem or a tools problem?
A tools problem, and AgentDojo's numbers make the case bluntly. Running the same GPT-4o across its environments, the paper reports a 92% attack success rate in the Slack suite, where the agent browses attacker-controlled web pages, and 0% on one travel-suite task that required two unrelated malicious actions.
One model. A 92-point swing. The variable is reach.
The Slack result has a straightforward explanation: the attacker controls a large share of what the agent reads there, because the agent browses the web and posts to channels. Where the attacker owns the data, the attack lands almost every time. The travel task that scored zero asked for two unrelated actions in sequence, and the agent rarely completed both.
That is the whole thesis. Your security posture is set by which tools you connect and which data you let reach them.
So how exposed is a typical agent?
Neither helpless nor safe by default. AgentDojo reports that attacks succeed against the best-performing agents in less than 25% of cases overall, which refutes both extremes at once. For GPT-4o specifically, the paper reports a targeted attack success rate of roughly 45.8% under its "Important message" attack.
Read those two numbers as answering different questions. The sub-25% figure is a summary across the benchmark's strongest agents. The ~46% figure is one model under one attack with its normal tools available. Quoting either alone produces panic or complacency.
Which defenses actually reduce attack success?
Containment, by a wide margin. A tool filter that restricts the agent to only the tools the current task needs cut targeted attack success to 7.5%, down from roughly 46% undefended.
The contrast with detection is the useful part. AgentDojo also tested a prompt-injection detector, and the paper's own assessment is that it produces "too many false positives" and "significantly degrades utility." It reduces attacks, but it pays for that by making the agent worse at its real job.
| Approach | What it does | AgentDojo result |
|---|---|---|
| Undefended | Normal tools, no restriction | ~45.8% targeted attack success (GPT-4o, "Important message") |
| Tool filter | Restrict to the tools this task needs | 7.5% attack success |
| Injection detector | Classify input as malicious before acting | Reduces attacks, but too many false positives and significantly degraded utility |
The paper also notes that models typically lose 10% to 25% of absolute utility when under attack, so some cost is unavoidable. The point is that detection fights the attacker's text, while containment removes the ground the attacker stands on. Only one of those gets cheaper as attacks get cleverer.
What does a prompt injection detection tool actually check?
A tool that only classifies incoming text is the weakest row in the table below. In AgentDojo's Table 5 the detector cut attack success nearly as far as the tool filter, but at a large cost in benign utility while the filter paid none: changing what the agent can reach beats reading the input harder. Use the table to ask a vendor which checks its product enforces, what each catches and misses, and what it costs in benign utility, with a figure wherever a primary source prints one.
| What a tool checks | What it inspects | What it catches | What it misses | Utility cost |
|---|---|---|---|---|
| Input classification (injection detector) | Each message, page, or tool output, scored as malicious or benign before the agent acts | Injections that resemble its training examples, such as a literal "ignore previous instructions" | Novel phrasings; every false negative leaves the full tool set reachable | High: AgentDojo found the detector it tested "has too many false positives" and "significantly degrades utility" (paper, Section 4.3) |
| Tool-scope allow-listing (tool filter) | Which tools the task needs, fixed before any untrusted data enters the context | Any injection that needs a tool the task was never granted, whatever its wording; in AgentDojo the filter lowered GPT-4o's attack success rate to 7.5% (the undefended rows are in the defenses table above) | Attacks that only need the tools the task legitimately has, such as a send-mail injection inside a send-mail task | Low when the task's tool set is chosen correctly; a wrong guess fails the task, not the attacker |
| Action gating (confirmation before writes and side effects) | The action about to run (send, pay, post, delete) and who asked for it | The final step of an attack, even after the model has been fooled | Read-only exfiltration that never trips a gate, and approvals given on autopilot | Medium: every gate costs a human decision, so gate the irreversible actions, not everything |
| Data-flow and capability tracking (CaMeL-style) | The control and data flow extracted from the trusted user query, so untrusted data can never change what runs | Injections that redirect the program or move private data where policy forbids | Attacks that stay inside the allowed flow, such as changing a value the plan legitimately reads | Measurable: the CaMeL paper reports solving 77% of AgentDojo tasks with provable security, against 84% for an undefended system |
| Spotlighting / delimiting untrusted content | The provenance of each input: untrusted text is marked, delimited, or transformed so the model can tell it from the user's instruction | Injections that depend on the model mistaking data for a command; with GPT-family models, the spotlighting paper reports the attack success rate falling from greater than 50% to below 2% in its experiments | Nothing about reach: a model that follows the marked text anyway still has every tool it had | Low by the same paper's account: minimal impact on task efficacy |
| Sandboxing and egress control | Where code and tool calls can reach: files, network destinations, credentials in scope | Exfiltration and lateral movement even when the model is fully compromised, because the data has nowhere to go | Damage inside the allowed surface, and anything the permitted destinations can do | Low at runtime; the cost is defining the allowed surface per task |
| Canary / honeytoken tripwires | Whether a planted secret, fake credential, or decoy record ever leaves the system or gets used | Exfiltration you would otherwise never see, and the tool or data source it came through | Everything that is not exfiltration; it fires after the fact, so it detects rather than prevents | Near zero: the tokens cost nothing to plant, only an alert path to maintain |
| Benchmark evaluation (AgentDojo-style) | The whole agent, tools included, run through realistic tasks with injections planted in the data it reads | Where reach actually leaks: which suite, which tool, which wording; AgentDojo reports attacks succeeding against the best-performing agents in less than 25% of cases, the bar a tool's claims should be measured against | Attacks nobody wrote a test case for, so a benchmark is a floor, not a ceiling | None at runtime; it is a build-time check |
The rows that change reach (tool scope, action gating, flow tracking, sandboxing) are the containment checklist in the next section seen from the tool's side; a product that offers only the first row has skipped all of them and kept the one check AgentDojo found paying for its attack reduction in benign utility.
What does a containment checklist look like?
Scope the tool list to the task, treat every tool output as untrusted, and never leave the full capability set reachable after a task finishes. Each item below is a reduction in reach, and reach is what set the measured success rate.
- Default-deny tools. The agent can call only what the task needs, fixed before untrusted data enters the context.
- Treat every tool output as hostile. Email bodies, web pages, and MCP responses are data, not authority.
- Separate read from write. Reading email should not leave send-mail reachable in the same context.
- Narrow each credential to the smallest surface that still works.
- Require human approval on irreversible actions: sending, forwarding, publishing, posting, paying.
- Reset context between unrelated tasks, so an injection cannot sit and wait for a later task that has the tools it wanted.
- Log tool calls, not just answers: what the agent invoked, and on whose behalf.
Notice that most of these are the same discipline as keeping the tool catalog small for accuracy reasons. A shorter tool list is both easier to route correctly and harder to abuse, which is a rare case where the reliability fix and the security fix are the same fix.
The questions apply the same way regardless of runtime: what can this agent reach, and what data reaches it? Whether it runs inside a framework, your own loop, or a marketplace such as Askpert where experts are called over REST or MCP, scoping the answer is what moves the number.
One thing this is not: the risk of installing an untrusted skill is a different attack path entirely. That is supply-chain and install-time risk, where the malicious code arrives in something you chose to install. This is untrusted data reaching an agent you already trust. Both are real, and they need different defenses.
How does indirect prompt injection work?
It is an attack where instructions hide inside data an agent reads rather than in the user's own message. An email, web page, or tool output carries text the model treats as a command, so the agent follows instructions no authorized party wrote. It works because instructions and data are the same token stream to a language model.
Can a stronger model stop prompt injection?
No. The model is doing what it was built to do, which is follow instructions. AgentDojo showed the same GPT-4o scoring 92% attack success in one application suite and 0% in another, so reach rather than model choice set the outcome. Changing what the agent can touch moves the number; better alignment does not.
What actually reduces prompt injection risk?
Containment. In AgentDojo, restricting the agent to only the tools its current task needs cut targeted attack success to 7.5%, from roughly 46% undefended. Grant tools default-deny, scope credentials narrowly, separate read from write, and require human approval on irreversible actions such as sending or publishing.
Are injection detectors worth using?
They reduce attacks but at a real cost. AgentDojo's assessment of a prompt-injection detector was that it produces too many false positives and significantly degrades utility, meaning the agent gets worse at its actual job. Detection can supplement containment, but it is a poor substitute for simply not leaving dangerous tools reachable.
What should a prompt injection detection tool check for?
More than the text of the input. Classifying incoming messages as malicious is the weakest check: it misses novel phrasings, and in AgentDojo the detector tested cut attacks but produced too many false positives while significantly degrading utility. The checks worth paying for change what the agent can reach: which tools the task is allowed, a confirmation step before irreversible actions, and tracking of which data may flow where; in AgentDojo, restricting tools cut attacks as far as the detector at no cost in benign utility. Marking untrusted content so the model can tell it from the user's instruction helps the model resist, but changes nothing about what it can reach. Ask a tool which of those it enforces, then benchmark it with injections planted in the data the agent actually reads.
Is prompt injection a solved problem?
No. Attacks still succeed against the best agents in up to 25% of cases in AgentDojo, and every measured defense trades something away. Containment is the most effective measure so far, not a complete fix, and the checklist has to be reapplied every time you connect a new tool or data source.