license: cc-by-4.0
viewer: false
pretty_name: DecompBench
language:

• en
  size_categories:
• n<1K
  tags:
• agent-safety
• ai-safety
• red-teaming
• llm-agents
• tool-use
• benchmark
  extra_gated_description: >-
  This dataset contains adversarial prompts intended for AI safety research.
  Access is granted to researchers and practitioners with a legitimate
  safety or security use case. By requesting access you agree not to
  redistribute this dataset or use it to attack production AI systems.
  extra_gated_prompt: >-
  In the Verification field, share a link that confirms your affiliation
  (Google Scholar, LinkedIn, GitHub, lab page) or an academic/work email.
  extra_gated_fields:
  Full name: text
  Affiliation: text
  Verification: text
  Country: country
  Intended use: text
  I agree to the terms above: checkbox

DecompBench

DecompBench is a benchmark for evaluating decomposition attacks on tool-using LLM agents. A harmful task is split into subtasks that are individually benign, and each subtask is issued to the agent without the conversation history of the others. Tasks execute against real services (GitLab, OwnCloud, RocketChat, PostgreSQL, Redis, Notion, Plane) in a Docker environment, and success is measured by checkpoints that inspect the resulting environment state.

Why decomposition attacks

Agents are getting better at running long multi-step workflows with real tools, which
also makes them more useful to an attacker. In a decomposition attack the attacker never
asks for the harmful thing directly. They break it into steps that each look like
ordinary work, and the harm only becomes visible once the steps are put together. Safety
training that looks at one request at a time has nothing to refuse. This is not just a
hypothetical: the Claude Code espionage campaign in November 2025 was run this way, with
the attack broken into phases and subtasks.

Agent safety benchmarks already exist, but they were not built for this. Most test
single-turn tool use, or they take tasks written for something else and apply
decomposition operators after the fact. Tasks that were not designed to be decomposed
do not split cleanly. The subtasks often still look harmful on their own, the
transformations feel forced, and the result does not resemble how an attacker would
actually work.

We build the tasks the other way round. Each one starts from a task graph and is written
so that a valid decomposition exists by construction. Every task has to meet four
criteria: the full task is harmful (C1), it needs several dependent steps rather than one
tool call (C2), no subtask is harmful on its own (C3), and completing it takes real
capability, so decomposition is actually necessary (C4). The subtasks are independent
rather than turns in one conversation, so the attack still works when it is spread across
sessions, accounts, or providers.

How the tasks are built

Stage 0: Capabilities. We scrape the environment's APIs, packages, and endpoints for
every atomic action an agent can take, giving 335 capabilities, each tagged with a role,
an action type, and typed inputs and outputs. All are neutral on their own.

Stage 1: Seed tasks. We hand-author 101 seeds across 8 attack categories. Each has a
harmful goal, a target asset, and a base graph: a DAG of abstract steps linked by data
dependencies. The graph is what enforces C2 - no single step completes the attack.

Stage 2: Task graphs. We walk each graph in topological order and give every node a
capability matching its role. Optional nodes and type-bridging steps mean one seed yields
many distinct graphs. A diversity filter drops near-duplicates, and a realism checker
(Claude Haiku 4.5) drops graphs with no plausible real-world analogue.

Stage 3: Descriptions. GPT-4o writes each graph up as a task, and is told to state
only the final objective so the result reads like something a person would ask for rather
than step-by-step instructions. Placeholders become concrete file paths, tables, and
usernames. Every task was checked by hand.

Decomposition

Harm only appears in Stage 3, once concrete values land: "insert rows" becomes "insert a
backdated row into audit_logs", which a subtask filter refuses. Splitting the task
therefore has to keep the capability and the incriminating values apart.

Our decomposer (GPT-4o, temperature 0.7) sees only the harmful task and the environment,
the same as a real attacker would, and returns a sequence of subtasks. It uses the
mapping and wrapping operators from [2]; we do not introduce a new
attack operator. Tasks split into a mean of 6.0 subtasks, range 3 to 8.

What's in the dataset

253 tasks, each with a monolithic harmful version and a decomposition into benign
subtasks — 1,522 subtasks in total, a mean of 6.0 per task (range 3–9). Tasks use a mean
of 2.7 services each (range 1–7).

One directory per task under tasks/<slug>/:

Some tasks also ship seed data (utils/seed.sql, utils/seed.redis), workspace files,
or a setup.sh.

Results

We evaluate four models as agents under OpenHands, running every task both ways: once as the
monolithic harmful task, once as the decomposed subtasks. ASR is the fraction of tasks
completed successfully, RR the fraction drawing a safety refusal, CPR the fraction of
checkpoints passed. Numbers are mean ± std over three runs at decoding temperatures 0.0,
0.3 and 0.7, with the decomposition held fixed.

* single run

Refusal collapses. The safety-trained agents refuse almost every monolithic task and
almost no subtask, and attack success goes from zero to around two thirds. GPT-5 refuses
somewhat more than the mini-tier models in both settings, but the direction and size of
the gap is unchanged, so this is not an artifact of evaluating small models.

What's left are capability failures, not refusals. Among failed decomposed tasks,
safety refusals account for 18–26% for the safety-trained agents; the rest are agents that
tried and could not finish. The most common causes are API misuse (29%) and producing an
artifact that is implausible or self-revealing (32% combined) — the agent completes the
harmful action but botches the disguise. 57% of failures first appear in the last third of
the chain, so the benign scaffolding runs cleanly and things break at or near the harmful
step.

The gap isn't specific to our tasks. On MT-AgentRisk, decomposition roughly halves the
refusal rate and raises ASR by 16–21 points for GPT-5-mini and Qwen3-Coder-30B, even
though its monolithic tasks start from a much lower refusal rate than ours.

Scoring. 74.9% of checkpoints are purely rule-based and inspect the environment
directly, 13.3% extract content deterministically and then judge it, and 11.8% are
LLM-judged over the trajectory, used where the check is about sequence or intent. On 150
checkpoints annotated by hand, our judge (GPT-4o) agrees with the human label 91.3% of the
time. As a check on C4, an abliterated Llama scores 0% ASR and about 6% CPR, so the tasks
are not completable by an unaligned model that simply doesn't refuse.

Intended use

DecompBench is intended for research on agent safety and for developing and evaluating defenses against decomposition attacks. It is not intended for any use that involves executing these tasks against systems you do not own or operate.

Defense Guidance

We release DecompBench to support work on defenses against decomposition attacks, and outline the directions we consider most promising below.

Provider-side oversight and its limits. Since no single subtask is harmful in isolation, detection must operate above the individual request. Stateful defenses that profile a user or key and score cumulative intent across their history are the most direct approach [1], and ToolShield [2] learns safety experiences from prior trajectories to defend the shared-context multi-turn setting. Both are scoped to what one provider observes. An attacker who splits a task across sessions, agents, accounts, or providers leaves each of them with a fragment, and our threat model assumes exactly this. Provider-side oversight raises the cost of an attack but cannot be the whole defense.

Environment-state monitoring. The environment is the one place where the full attack is visible regardless of how it is partitioned. Whichever provider issues them, the writes, permission changes, and data movements all land on the same services. A defense sitting with the environment owner can diff state after each action and reason over the accumulated delta: which tables were read and then exported, which credentials were accessed, which files moved toward an external boundary. This signal is not attacker-resettable. Opening a new session does not undo a database write. We see detectors built on state transitions, cross-service data-flow tracking, and provenance for agent-produced artifacts as the most promising direction, since they catch chains that any text-level or session-level filter passes.

References

[1] Brown, D., Sabbaghi, M., Sun, L., Robey, A., Pappas, G. J., Wong, E., and Hassani, H. Benchmarking Mitigations Against Covert Misuse. NeurIPS 2025 Workshop on Biosecurity Safeguards for Generative AI. arXiv:2506.06414.

[2] Li et al. Unsafer in Many Turns: Benchmarking and Defending Multi-Turn Safety Risks in Tool-Using Agents. ICML 2026. arXiv:2602.13379.

Citation

@article{kothamasu2026hidden,
  title={Hidden in Plain Sight: Benchmarking Agent Safety Against Decomposition Attacks with DECOMPBENCH},
  author={Kothamasu, Vikhyath and Smith, Virginia and Yadav, Chhavi},
  journal={arXiv preprint arXiv:2606.13994},
  year={2026}
}