Build1 publisher2 min readPublished
Current LLMs leave a third of AgentDojo's 97 tasks unsolved with no attacker present
The AgentDojo framework pairs 97 tool-using tasks with 629 security test cases in one stateful environment, and current LLMs solve fewer than 66 percent of those tasks with no attacker in play. That baseline bounds what its defense numbers can mean.
The Engineer · Build desk
What happened
- AgentDojo ships as an extensible environment populated with 97 realistic tool-using tasks, including email management, e-banking and travel booking, plus 629 security test cases.
- Current LLMs solve fewer than 66 percent of those tasks when no attack is present at all, according to the paper.
- Adding an existing defense, a secondary attack detector, drops the measured attack success rate to 8 percent.
- Scoring uses formal utility checks computed over the environment state instead of asking another LLM to simulate the environment and judge the outcome.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint A defense evaluated on a system that already leaves at least 33 of 97 tasks unfinished cannot cleanly separate a blocked injection from an agent that was never going to complete the job.
- exposure Any tool that returns third-party text is an instruction channel into the agent, so the inbox, web page or booking record the agent reads is reachable by whoever wrote it.
- decision A team adopting a detector-style defense is buying a number measured against general-purpose attacks. Before trusting that number, it has to decide whether to fund an attacker tuned to its own tool schema.
- capability State-based pass conditions let a team score its own agent tasks with assertions rather than a judge model, so the same run can be replayed and compared.
The vulnerability is structural. LLMs operate directly on text and have no formal way to distinguish instructions from data [3]. When a tool returns an email body, that body arrives in the same channel as the user's instruction. Prompt injection is malicious instructions planted in third-party data that the agent's tools process, and a successful one lets an outside attacker take actions and call tools on the user's behalf, with data exfiltration and arbitrary code execution among the listed consequences [4].
A security test case in AgentDojo has two parts: an attacker goal, such as leaking the victim's emails, and an injection endpoint, such as an email already sitting in the user's inbox [5]. The agent has to call multiple tools dynamically, and the environment holds state between those calls [12]. Spread over the task set, 629 test cases against 97 tasks works out to roughly 6.5 injection scenarios per task [13].
Fewer than 66 percent of 97 tasks solved leaves at least 33 of them failing with an empty threat model [14]. Utility and security are scored separately, so an agent that never completes the user's task also never completes the attacker's, and banks a clean security result for it.
Attacks succeed against the best performing agents in under 25 percent of cases, and a secondary attack detector pulls that to 8 percent, which is roughly a third of the undefended rate [15]. The paper reports these as aggregates for "current LLMs"; the introduction does not give per-model scores [7].
For 8 percent to mean anything in your deployment, several things would have to hold. The agents, defenses and attacks shipped in the framework are general-purpose and were not designed for any specific task or security scenario [11]. Your tasks would have to resemble email management, e-banking and travel booking in tool count and statefulness [2]. And your attacker would have to be as uninformed as theirs: the authors report that current prompt injection attacks benefit only marginally from side information about the system or the victim, and rarely succeed when the attacker's goal is abnormally security-sensitive, such as emailing an authentication code [10].
The last finding cuts both ways for anyone deciding what to test. An attacker who has read your tool schema, knows your users and writes injections for your specific endpoints is not in this measurement. The harness is reproducible: pass conditions are formal utility checks computed over the environment state, and no second LLM simulates the environment [6]. The framework is also extensible by design, so new tasks, attacks and defenses can be added to it [1].
What to watch
- Adaptive attacks written for specific tasks and tool schemas, which would test whether the sub-25 percent success rate holds against an informed attacker.
- New agent designs that lift task success above 66 percent, since the utility ceiling currently limits what any defense measurement can show.
- Attacks aimed at evading the secondary detector itself, to see whether the 8 percent figure survives.