Prompt Injection: Your Agent's Tool List Is the Attack Surface

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.

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 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.