GuardianAgentBench’s Best Agent Still Failed One in Four Scenarios — Runtime Guardrails Recovered 19.9%
A new agent-safety benchmark found that the strongest model-and-framework combination completed only 74.8% of its scenarios correctly—and that adding more safety language to the system prompt did little for the strongest models. Intercepting tool calls at runtime was materially more consistent: a proof-of-concept guardrail layer improved all six tested models, recovered 19.9% of one strong configuration’s original failures, and incorrectly blocked 0.5% of its originally successful cases.
GuardianAgentBench, posted to arXiv on July 23, contains 580 scenarios across customer service, email, calendar, business intelligence, financial, and internal-knowledge agents. The authors ran six models through LangChain, LlamaIndex, and Vectara using the same prompts, tools, and queries. Each scenario required both a correct response and a correct tool trace; passing one dimension alone did not count as overall success.
The work is most useful as evidence for where to place controls. Its guardrails sat immediately before tool execution, evaluated the proposed call against full interaction context, and returned one of three outcomes: pass, corrective feedback with a retry, or block with human escalation. That architecture is closer to a reference monitor than another instruction in the model’s context—and the result supports treating tool policy as code, not prose.
Production frameworks did not erase model-level failure patterns
The benchmark covered 81 distinct tools and 1,177 sequential turns. Of the 580 scenarios, 398 followed an ordinary execution path and 182 contained adversarial modifications. Those modifications included massive responses, tool errors, multiple plausible results, prompt injection inside natural-text fields, and partial data. The six evaluated models were Claude Opus 4.5, GPT-5.2 Pro, GPT-OSS-120B, Gemini-3-Pro, DeepSeek-V3.2, and Qwen3-Max.
Claude Opus 4.5 on Vectara produced the highest average overall score, 74.8. Calendar was the hardest domain: no tested configuration exceeded 62.0 overall. Scores for a given model generally moved by only two or three points across the three frameworks, leading the authors to attribute most of the observed difference to the underlying model rather than the orchestration library.
The failure profiles were not uniform. Stronger models frequently omitted required tool calls: the paper reports missing-call shares of 52–57% for several frontier configurations. Weaker performers were more likely to select the wrong tool or repeat calls, with incorrect-selection shares reaching 25% and repeated-call shares of 29–33%. Incorrect ordering was comparatively rare at 0.6–4.4%.
That distinction has direct engineering value. A blanket instruction to “be careful” cannot target both under-calling and over-calling well. A coverage check may help an agent that stops too early, while relevance, cost, and rate controls are better suited to an agent that acts aggressively. Model upgrades can change the type of failure without eliminating the need for an execution policy.
Longer action chains failed faster than larger toolboxes
For Claude Opus 4.5 averaged across the three frameworks, overall performance declined from 78.2 with one available tool to 62.3 with seven. Increasing the required sequential depth was more damaging: the score fell from 82.3 for one turn to 51.2 for seven turns. The 31.1-point depth decline was nearly twice the 15.9-point decline associated with tool-set growth.
This result argues against using a successful one- or two-step demonstration as evidence that a production workflow is safe. Multi-stage dependencies create opportunities to lose required state, skip prerequisite checks, carry forward poisoned output, or act after the original intent has become ambiguous. Safety testing should therefore scale action depth independently from the number of registered tools.
The guardrail was an active retry-and-block mechanism
The proof of concept implemented three checks in LlamaIndex: argument validation, required-tool coverage, and relevance/cost analysis. Each proposed call was reviewed with access to conversation history, available tools, and call arguments. Failed checks produced structured feedback and allowed up to two retries. Persistent violations blocked execution and raised a human-in-the-loop alert with the interaction history.
The checks themselves were powered by Claude Sonnet 4.5, so this was not a deterministic policy engine and should not be read as proof that one model can reliably secure another in every environment. It does demonstrate a useful control point: the supervisor was outside the acting agent’s immediate plan and could prevent a call from reaching the tool.
Across the six models, the runtime guardrails improved overall scores by 2.8 to 7.7 points. Additional system-prompt safety instructions ranged from a 5.5-point gain for DeepSeek-V3.2 to a 0.3-point regression for GPT-5.2 Pro; Claude Opus 4.5 and Gemini-3-Pro gained only 0.4 and 0.3 points respectively. The guardrails outperformed the prompt-only treatment for every model tested.
The paper’s most interpretable precision check used Claude Opus 4.5 on LlamaIndex. Of 151 scenarios the unguarded agent failed, the guardrail converted 30 to successes—a 19.9% recovery rate. Of 429 scenarios the unguarded agent passed, two were incorrectly blocked, yielding the reported 0.5% false-positive rate. Those figures belong to this benchmark and configuration; they are not universal deployment guarantees.
How defensive teams can use the result
- Interpose before side effects. Route every tool call through a policy layer that can inspect identity, arguments, resource scope, provenance, and prior actions before execution—not merely log the call afterward.
- Build separate checks for omission and commission. Verify required prerequisites and missing calls, but also reject redundant, irrelevant, repeated, or unexpectedly costly actions. Different models may need different policy emphasis.
- Use deterministic rules for hard boundaries. Model-based supervisors can help classify context, but tenant separation, write authorization, spend limits, secret access, and destructive operations should be enforced by code and infrastructure.
- Cap retries and escalate with context. Corrective feedback is useful only when loops are bounded. Preserve the proposed action, violated rule, relevant source data, and previous retries for a human reviewer.
- Test by sequential depth. Extend evaluations from single calls to realistic seven-step and longer workflows. Inject partial results, conflicting matches, prompt-injected tool output, and transient errors at different positions in the chain.
- Measure false blocks as well as catches. A guardrail that prevents unsafe actions by disabling useful automation is not a production success. Track recovery, false positives, retry count, latency, and cost by model and workflow.
GuardianAgentBench does not establish that agent safety is solved by adding a second model at the tool boundary. Its scenarios use simulated tool responses, its automated judge was Claude Sonnet 4.5, and the guardrail experiment was implemented in one of the three frameworks. What it does provide is a timely comparative signal: safety prose inside the acting model’s prompt was inconsistent, while an external mechanism with the authority to correct or block tool calls improved every model tested. For high-impact agents, that is the right direction of travel.
Sources: