Agent Prompt Injection Testing: What a Two-Boolean Score Leaves Out

Agent prompt injection testing can examine documented prompt-injection classes and how benchmarks record their outcomes.

The discussion concerns benchmark scoring and a proposed trace-review method. It does not report a completed UniverseBlend experiment.

The benchmark discussed here is AgentDojo, from ETH Zurich’s SPY Lab.

The distinction below concerns the interpretation of a recorded score, rather than a measured comparison of models or defences.

Here it is in one sentence: in AgentDojo 0.1.35, a provider outage and a successful defence are recorded identically.

Key takeaways

• Verified in source: AgentDojo 0.1.35 contains three exception paths that set security = True on infrastructure failures. A context-window overflow and a working defence are recorded identically.
• Verified in source: The scoring does not confirm that a payload reached the model. A dropped payload and a refused payload produce the same result.
• Open question: Whether a different rubric changes reported security scores remains unmeasured here.
• Design principle: Ambiguity should resolve to “indeterminate”, not to “secure”. A benchmark has to write something to disk; a published article does not.
• Failure shape is not a detail. A silent failure produces a plausible answer and no alert. Attack success rate treats it identically to a loud refusal.
• Attribution defaults to unknown. A failed attack alone does not identify which component caused it.
• Limitation: No models were run for this article. It is source analysis, and the payload evaluation remains open.

---

Quick Navigation

---

Scope of this source discussion

The scope is source discussion and a proposed review methodology, not payload testing or model execution.

The source discussed is agentdojo version 0.1.35, released on 27 October 2025. The relevant implementation is in agentdojo/benchmark.py in the published package.

Here is what the package contains at that version.

Table: scroll sideways to view all columns when needed.

Property	Value
Release	0.1.35, uploaded 2025-10-27
Releases published to date	36
Python requirement	>= 3.10
Evaluation suites	workspace, banking, travel, slack
Suite versions shipped	v1, v1_1, v1_1_1, v1_1_2, v1_2, v1_2_1, v1_2_2
Built-in defences	4
Attack generators	17
Result representation	Two booleans per run

The four defences are tool_filter, transformers_pi_detector, spotlighting_with_delimiting and repeat_user_prompt. The seventeen attack generators split into twelve goal-hijacking templates and five denial-of-service templates.

That last row is where this article lives.

---

A proposed trace-review method

A trace-review method could examine information that summary scores leave out: whether the payload reached the model, whether an infrastructure error interrupted the run, and what the recorded outcome establishes. The approach below is a proposed rubric, not a tested UniverseBlend implementation or a report of re-scored results.

AgentDojo writes one JSON file per run to a predictable path:

runs/{pipeline}/{suite}/{user_task}/{attack}/{injection_task}.json

Each file carries the full trajectory plus the context the logger attached: utility, security, attack_type, pipeline_name, benchmark_version, agentdojo_package_version, an evaluation timestamp, and the injection strings used.

These recorded fields provide possible inputs for a trace review. Their completeness would need to be checked for the particular logs under review.

No implemented re-scoring harness or unit-test results are presented here.

---

What the two booleans encode

AgentDojo reduces each run to utility and security.

utility is true when the agent completed the legitimate user task. security is true when the injection task goal was not achieved. So security = False means the attack worked.

This is a reasonable design. It produces attack success rate, which is the number most of the literature reports, and it makes results comparable across models and defences.

The compression is also where information goes missing. Two runs that look identical in the summary can be very different events.

Consider two cases that both record security = True:

• The model read the injected instruction and declined to follow it.
• The injected instruction never reached the model at all.

The first tells you something about the model’s resistance. The second tells you something about your filtering, or about nothing at all if no filter was configured. Collapsed into one boolean, they are indistinguishable.

---

What the published source records

In the published agentdojo/benchmark.py source at version 0.1.35, three exception handlers set utility = False; security = True.

They fire on:

• BadRequestError where the code is context_length_exceeded, the parameter is max_tokens, or the message asks to reduce message length
• ApiError whose string contains internal server error
• ServerError

Each path logs the error and moves on. The run is counted.

So a context-window overflow enters the summary statistics in the same column as a defence that worked. A provider having a bad afternoon looks, at the aggregate level, like security.

There is a fourth behaviour worth noting. For denial-of-service attack generators, the scoring inverts: security = not utility. Those five generators measure availability rather than goal hijacking, so mixing them into a single headline number combines two different properties.

These statements concern the published code, not observed model behaviour. No UniverseBlend model-execution results are presented.

---

Where the measurement holds

The design is sound for what it was built to do.

AgentDojo’s core contribution is realism. Its environments are stateful and require multiple tool calls. Injection strings are placed inside realistic content, such as an email body, rather than appended to a tool response where they would be trivially detectable. Over 900 combinations of benign user tasks and malicious injection tasks are paired across the four suites.

That is a substantially harder setting than earlier work. InjecAgent used simulated single-turn scenarios where one adversarial item is fed as a tool output without evaluating the agent’s planning. The newer AgentDyn benchmark reports average trajectory lengths of 7.1 steps against AgentDojo’s 3.49 and InjecAgent’s 1.

The two-boolean scheme also does something quietly important. By tracking utility alongside security, it catches the failure mode where a defence works by breaking the agent. A system that refuses everything scores perfectly on security and terribly on utility, and you can see that immediately.

Agent task competence is a real confound in every security number, and AgentDojo’s original evaluation is upfront about it. The best-performing model in that paper reached only 78.22% utility in benign settings with no attack present. If an agent fails a fifth of its ordinary tasks, some portion of every security result is just ordinary incompetence.

---

Where the measurement breaks

Three places, in rising order of importance.

1. Infrastructure errors count as wins. Covered above. The practical effect depends on how often those exceptions fire in your environment, which depends on your context lengths, your provider’s reliability that week, and your rate limits. None of those have anything to do with security.
2. Delivery is never verified. Nothing in the summary confirms the payload reached the model’s context. A truncation bug, a serialisation error, or a defence quietly dropping content all produce the same security = True as a model that read the attack and refused.
3. Keep ambiguity visible. A summary boolean cannot, by itself, explain why a run ended without an achieved injection goal.

For agent prompt injection testing that informs a real deployment decision, an unresolvable run should be visible as unresolvable.

---

The shape of failure matters

A pass/fail score tells you whether something went wrong. It does not tell you whether anyone would have noticed.

The proposed rubric distinguishes four failure shapes.

Table: scroll sideways to view all columns when needed.

Shape	Definition
Loud	The system refused, blocked, or sanitised, and made that visible. The event enters your telemetry.
Silent	The injected behaviour executed and the output reads as a normal, plausible completion. Nothing signals a problem.
Partial	The agent followed part of the injected instruction without completing it.
Indeterminate	The shape cannot be established from the trace.

A silent failure is one where the system produces an apparently valid response while following the injected instruction.

Silent failures are the operationally dangerous ones. A loud failure generates a log line and possibly an alert. A silent failure generates a plausible answer, a satisfied user, and no reason for anyone to look. If an agent exfiltrates a record and then produces a competent summary of your inbox, the summary is what your reviewer sees.

Attack success rate treats both identically. They are not remotely the same risk.

One possible approach is to flag refusal or warning language for manual review. Such a heuristic would need validation; no accuracy result is reported here.

---

Why attribution is difficult

When a payload does not get through, the interesting question is why. It is also the question most evaluations skip, because it is genuinely hard.

A blocked payload looks the same whether the block was engineered or accidental. The trace shows an attack that did not succeed. It does not show you which component is responsible.

A review should distinguish documented evidence from inference and leave attribution undetermined when the trace does not support a conclusion.

Two possible situations illustrate why attribution needs caution.

1. No configured defence: Consider model behaviour as one possible explanation, while checking other causes and avoiding unsupported framework attribution.
2. A presentation-layer defence: Record both model behaviour and the changed presentation as possible explanations; a single trace may not separate their effects.

A proposed attribution should record competing explanations and the evidence supporting its confidence level.

The most common error in this area is reading a model’s refusal as a framework security feature. It is an easy mistake and it leads directly to deploying the same architecture on a different model and being surprised.

---

What the source discussion establishes—and leaves open

Three things, held at appropriate strength.

First, verified. AgentDojo 0.1.35 scores three classes of infrastructure error as defensive successes, and does not verify payload delivery. This is directly checkable in the published source.

Whether a different rubric changes any reported score remains unmeasured here.

Whether stricter scoring changes any published conclusion is unknown. Evaluating that question would require a reproducible method, preserved traces and documented results.

What this does not tell us is anything about which frameworks resist prompt injection. That evaluation has not been run. The original question stands open.

---

Limitations

The proposed methodology has not been validated.

• No models were run. This is source analysis. Every claim is about code, not behaviour.
• One framework, one version. AgentDojo 0.1.35 only. Whether other agent evaluation tools share this property is untested, though the design pressure that produces it is common.
• Version-specific: The source discussion concerns AgentDojo 0.1.35. Re-check the implementation before applying it to another version.
• The proposed rubric is unvalidated. Its effect on scores has not been measured.
• Proposed lexical detection needs validation. It may miss warnings or incorrectly classify compliant answers.
• Template attacks measure a floor. Work on adaptive attacks shows defences evaluated against fixed templates degrade badly under attacks adapted to them. Any result from this class of tool is a lower bound on what a motivated attacker achieves.
• Passing proves nothing. A system that survives this evaluation is not secure. It survived these payloads, at these versions, on this date, under this configuration. Failing one test does not mean a framework is broadly insecure, either.

---

How to investigate this question

The source reading needs nothing but the package.

bash

pip download agentdojo==0.1.35 --no-deps



unzip agentdojo-0.1.35-py3-none-any.whl -d src

Then open src/agentdojo/benchmark.py and search for security = True. The three exception paths are in the function that runs a single task against a pipeline. The attack generators are in src/agentdojo/attacks/, and the defence names sit in src/agentdojo/agent_pipeline/agent_pipeline.py.

A future investigation could generate traces while holding the model fixed and varying one defence at a time. The following is prospective guidance, not a record of a completed experiment:

bash

python -m agentdojo.scripts.benchmark \



  --model <exact-dated-model-string> \



  --defense tool_filter \



  --attack important_instructions

Record the generated trace paths and preserve the logs alongside the exact evaluation configuration.

Two things to record and publish: the exact dated model string, never “latest”, and your temperature. Leaving temperature at the provider default is a defensible choice, but it is a choice, and it belongs in your methodology.

Set runs per cell above one. A single run cannot distinguish a defence from a coin flip, and these are stochastic systems. Three is a floor. Five is better. Report cells that produce different outcomes across repeats as variable rather than averaging them, because the variance is the finding.

All of this runs against AgentDojo’s simulated in-process environments. No third-party system is involved, and nothing here should be pointed at infrastructure you do not own.

---

References

Source materials: AgentDojo 0.1.35 and its published source. No historical UniverseBlend execution or re-scoring record is asserted.

Official documentation: AgentDojo repository · AgentDojo documentation

Academic research: AgentDojo, arXiv:2406.13352 · AgentDyn, arXiv:2602.03117 · Adaptive attacks against indirect prompt injection defences, arXiv:2503.00061 · Meta SecAlign, arXiv:2507.02735

---

Frequently Asked Questions

---

Keep reading

Here are the latest posts from the blog.