How to test agent-security benchmarks for tool-name sensitivity

Before using an agent-security benchmark to compare defenses, rerun matched cases with controlled changes to agent-visible tool names. Keep the task, attack objective, policy, environment, and grader fixed; measure both attack success and legitimate-task completion. If the outcome changes materially, the single-name score is narrower evidence than a release decision may require.

What the controlled comparison found

The authors call this threat-preserving representation sensitivity: the difference in measured attack success after a representation change that leaves the underlying security problem and evaluation criteria intact. Across 28,904 agent runs on Agent Security Bench (ASB), MCPTox, and AgentDojo, the direction and size of the change differed by benchmark and model.

On ASB, replacing threat-related tool names with neutral names increased committed attack success by 11.67 percentage points for GPT-5-mini and 13.21 points for Claude Haiku 4.5. On MCPTox, adding threat-related names reduced attack success by 11.00 and 4.11 points respectively. These are differences between the paper's matched benchmark arms, not predictions for other agents.

On AgentDojo, adding threat-related wording changed attack success by only 0.50 points for GPT-4o-mini, but benign utility fell by 5.36 points on tasks that required the renamed tool. The lesson is not that a suspicious name is a useful defense: it may also suppress authorized work. The authors' MCPTox control found a token-count-, length-, and casing-matched neutral name reproduced much of one shift, so threat vocabulary alone does not explain the result.

Build a matched-variant test

Start with the name a deployed agent actually sees. Add a small, predeclared set of plausible aliases: one neutral, one more explicit, and an orthographic control when appropriate. Do not quietly edit descriptions, tool permissions, payloads, or grading rules at the same time. Pin the full tool schema and benchmark revision so the comparison can be reproduced. Count execution failures separately from committed harmful actions; otherwise a broken run can look like a security success.

Run paired cases at the same model settings and report counts, uncertainty, and per-tool outcomes. Include benign cases requiring the renamed tool. If a defense ranking changes across variants, show the range and investigate the representation dependency before promotion. If it stays stable, that supports only the variants and conditions tested; it does not establish immunity to other wrappers or deployment contexts.

Use the result in a release decision

Keep tool-name sensitivity separate from instruction-hierarchy behavior and runtime-monitor evasion. A benchmark variant measures whether the evaluation score is robust to presentation choices; it does not replace policy enforcement or authorization of consequential actions. Record the variant set alongside the release threshold, and ask for additional evidence when the winner depends on one name.

Evidence limits

The paper varies selected tool names within three benchmark families and selected models. The transformations are not exhaustive, and the observed score movement is not fully attributed to a single mechanism. It does not establish real-world attack prevalence, a universal magnitude, or the stability of every defense ranking.