AgentDojo: A Runnable Testbed for Prompt Injection in Tool-Using LLM Agents

The Evaluation Gap AgentDojo Fills

Prompt injection research has a measurement problem. A paper proposes a defense, another paper proposes an attack, and the two are rarely run against the same agent, the same tools, or the same tasks. AgentDojo addresses that by fixing the environment: a Python package that ships task suites, a set of attacks, and a set of defenses, all executed through one benchmark entry point. The audience is narrow and specific. It is for researchers who need a reproducible number for a defense, and for engineers who want to know whether a tool-calling agent survives an injected instruction before they ship it. It is not aimed at teams looking for a drop-in filter for a production agent. The README describes it as a dynamic environment to evaluate attacks and defenses, and the citation points to the NeurIPS Datasets and Benchmarks Track, which tells you the intended consumer is someone producing a comparison, not someone operating a service.

Suites, Tasks, Attacks and Defenses as Separate Axes

The architecture visible in the README is a three-axis matrix. One axis is the suite, a named collection of tools and user tasks. The README example uses workspace, and the command form shows that suites are selected with a -s flag while individual user tasks are selected with -ut and an identifier such as user_task_0. The second axis is the attack, selected with --attack; the documented example is tool_knowledge, an attack that assumes knowledge of the available tools. The third axis is the defense, selected with --defense; the documented example is tool_filter. The model is a fourth axis, passed with --model and given as gpt-4o-2024-05-13 in the README. This separation is the design decision that matters. Because attack and defense are independent flags rather than baked-in variants, you can hold the suite and model constant and swap one component at a time, which is what makes a comparison table meaningful. The package also exposes a prompt injection detector behind an optional dependency, installed with pip install "agentdojo[transformers]", which implies the detector is transformer-based and not part of the base install.

Running the Benchmark Script

Installation is a single pip command, pip install agentdojo. The README carries an explicit warning attached to it: the API of the package is still under development and might change in the future. The benchmark is invoked as a module, not as a console script, so the command is python -m agentdojo.scripts.benchmark followed by flags. The README gives two runnable examples. The narrow one runs the workspace suite on two tasks with a specific model, the tool filter defense, and the tool knowledge attack:

python -m agentdojo.scripts.benchmark -s workspace -ut user_task_0 -ut user_task_1 --model gpt-4o-2024-05-13 --defense tool_filter --attack tool_knowledge

The broad one drops the suite and task selectors and runs every suite and every task with the same model, defense, and attack:

python -m agentdojo.scripts.benchmark --model gpt-4o-2024-05-13 --defense tool_filter --attack tool_knowledge

Note that -ut is repeatable, so task selection is additive rather than a range or a list. The README points to the --help flag of the script for the full flag surface, and that is where you should look for anything not shown here, including how to enumerate the available suites, attacks, and defenses. The repository layout places the script at src/agentdojo/scripts/benchmark.py, and the README links a separate development set-up page for contributing to the package itself.

Where the Benchmark Stops Being Useful

The most concrete limitation is stated by the maintainers: the API is under development and may change. That is not boilerplate caution. It means a script you write against one release can break on the next, and the release cadence shown in the supplied material (v0.1.33 in May 2025, v0.1.34 in June 2025, v0.1.35 in October 2025) is frequent enough that an unpinned dependency is a real risk. The second limitation is scope. The suites are fixed collections of tools and tasks defined inside the project. If your agent talks to an internal ticketing system, a proprietary database, or a tool schema the benchmark does not model, the results tell you about the benchmark's tool surface, not yours. Third, the documented attack example, tool_knowledge, is one that assumes the attacker knows the tool set. That is a strong assumption, and an agent that looks safe under it may not be safe against an attacker who probes blindly. The documentation excerpt supplied here does not enumerate the full attack and defense catalogs, so treat coverage as something to verify against the docs rather than assume. Finally, a benchmark score is a measurement, not a mitigation. Running the tool filter defense in the harness tells you how that filter performs on these tasks; it does not install a filter in your agent.

AgentDojo Against Agent Security Benchmarks and Hand-Rolled Suites

The obvious alternative is to build your own harness: write a handful of injection strings, point them at your agent, and count successes. That gives you your exact tool surface and your exact prompts, which AgentDojo cannot. The cost is that your numbers are not comparable to anyone else's, and you carry the maintenance of the attack set yourself. The other alternative is a broader agent security benchmark that spans more threat categories than prompt injection, such as data exfiltration or unsafe code execution. The difference in approach is focus versus breadth. AgentDojo is narrow by construction: the package name and the paper title both scope it to prompt injection attacks and defenses for LLM agents, and the flags reflect that, with one attack selector and one defense selector per run. A broader benchmark will give you a wider threat taxonomy but a coarser read on injection specifically. If injection is the question you are asking, the narrower harness is the better instrument, and the shared task definitions are what let you put your result next to someone else's. The README also notes that AgentDojo results are listed in the Invariant Benchmark Registry, which matters if you want an external place to point readers at.

Maintenance, Versioning and the MIT Licence

The licence is MIT, which is permissive and places few constraints on reuse in commercial or academic settings. This is not legal advice; read the LICENSE file in the repository if the terms matter to your organisation. The practical maintenance cost sits in two places. First, model identifiers. The README examples hardcode gpt-4o-2024-05-13, a dated snapshot. Model names go stale, and the benchmark script's accepted identifiers are whatever the installed version supports, so a run that worked last quarter may need the flag changed. Second, the optional transformers extra. Installing it pulls a transformer stack for the prompt injection detector, which adds dependency weight and a second upgrade path alongside the core package. The mitigation for both is the same and it is mechanical: pin the agentdojo version in your environment and re-run the benchmark when you bump it, rather than tracking the latest release. Given the stated API instability, pinning is not optional hygiene here, it is the difference between a reproducible result and a broken script.

Reading Results Without Overreading Them

The README points to a dedicated results page at agentdojo.spylab.ai/results/ and to the Invariant Benchmark Registry. Use those before you run anything yourself. If a defense you are considering is already covered on the published results, you can read the number instead of paying for the API calls, and you can compare your eventual run against a known configuration. What you should not do is treat a low attack success rate on the workspace suite as evidence that your agent is hardened. The suite defines the tools, the tasks, and the injection points. Your agent defines none of those things in the same way. The honest use of this project is as a controlled instrument: pick a suite that resembles your tool surface, fix the model and the defense, vary the attack, and report the delta. That is a claim the harness can support. A claim about your production system is not.

Editorial conclusion

Adopt AgentDojo if you are writing a paper or an internal report on prompt injection and need a shared, scriptable task set with published results to compare against. Do not adopt it as a production defense layer: the defenses here are benchmark subjects, and the README states the API is still under development, so pinning a version matters. Before you commit, verify that the suites you need exist for your tool surface, check which model identifiers the benchmark script accepts, and read the results page at agentdojo.spylab.ai/results/ to see whether the attacks and defenses you care about are already covered.

Official sources

1. ethz-spylab/agentdojo on GitHub
2. License: MIT
3. Project website
4. README
5. Releases