Blog · arXiv Analysis · Last reviewed June 25, 2026

The Decomposed Task Becomes the Safety Bypass

The June 2026 arXiv paper Hidden in Plain Sight: Benchmarking Agent Safety Against Decomposition Attacks with DECOMPBENCH, by Vikhyath Kothamasu, Virginia Smith, and Chhavi Yadav, studies a hard case for tool-using agent safety: a harmful job split into harmless-looking subtasks. Safety has to read the work as a whole.

For this essay, a decomposition attack is a misuse strategy in which the adversary distributes harmful intent across subtasks, sessions, accounts, tools, or intermediate artifacts so that each local request appears permissible while the composed job crosses a prohibited boundary.

The governance lesson is concrete: an agent that can operate tools needs a composed-task ledger, not only per-turn refusal checks. The evidence must connect purpose, artifacts, tools, credentials, state changes, and later consumption of partial work.

The Harmful Goal Is Split Apart

Kothamasu, Smith, and Yadav's paper, arXiv:2606.13994 [cs.CR], was submitted on June 12, 2026. The arXiv HTML lists Vikhyath Kothamasu and Virginia Smith at Carnegie Mellon University, and Chhavi Yadav at Carnegie Mellon University and the Simons Institute, UC Berkeley. The paper introduces DeCompBench, a benchmark for decomposition attacks against LLM-based agents that can use tools.

A decomposition attack is not simply a long bad prompt. It is a harmful objective distributed across smaller requests that look ordinary when inspected one by one. The paper's core warning is that a safety system can refuse the visible whole and still comply after the intent has been broken into benign-looking pieces.

This angle is distinct from the site's pages on command denylists, unsafe shortcuts, cold-start safety, and intent-governed tool authorization. This paper asks whether safety can survive when dangerous meaning is distributed across the job.

Current Context

As of June 25, 2026, decomposition risk sits inside a broader shift from chatbot safety to agent security. The relevant systems do not merely answer. They browse, query databases, edit files, call APIs, message people, create records, and sometimes act through long-lived credentials. NIST's AI Agent Standards Initiative frames agents capable of autonomous actions as a standards problem involving protocols, agent authentication, identity infrastructure, and security evaluations. OWASP's Top 10 for Agentic Applications for 2026 similarly treats agent risk as workflow risk across planning, tools, identity, memory, inter-agent communication, and cascading failures.

The same pattern appears in operational guidance. The April 2026 allied guidance Careful Adoption of Agentic AI Services from ASD's ACSC, CISA, NSA, the Canadian Centre for Cyber Security, NCSC-NZ, and NCSC-UK warns that agentic AI introduces privilege, design, behavior, structural, and accountability risks; it recommends least privilege, careful scoping, visibility, monitoring, human oversight, reversibility, and risk containment. The Model Context Protocol's 2025-06-18 tools specification describes tools as model-controlled and says clients should show exposed tools, request confirmation for sensitive operations, validate tool results, and log tool usage for audit purposes.

Decomposition is therefore not only a prompt trick. It is a systems failure mode. A local model guardrail may inspect the current text; a runtime policy may inspect one tool call; a security monitor may inspect one account. The adversary's advantage is composition: intent can move through environment state, copied artifacts, separate sessions, different users, or different models before the harmful state becomes visible.

Anthropic's November 2025 threat report described a disrupted cyber-espionage campaign in which attackers allegedly broke cyber operations into smaller apparently innocent tasks while presenting the activity as defensive testing. That report is a vendor threat-intelligence source, not an independent public adjudication of all facts. It is still relevant as a concrete example of why the decomposition pattern has moved from academic safety papers into operational security vocabulary.

DeCompBench as a Composite Test

DeCompBench is built around a decomposition-by-design method. The authors describe four criteria for valid tasks: the original task must be harmful, it must naturally require multiple dependent steps, each subtask must appear benign in isolation, and the monolithic task must be hard enough that a weak unaligned model cannot simply complete it without decomposition.

The dataset construction begins with 335 role-tagged capabilities and 101 manually curated seed tasks across eight attack categories. The final dataset contains 250 harmful tasks grounded in tool-rich settings such as version control platforms, databases, messaging systems, and cloud storage services. The paper names categories including data theft and exfiltration, financial crime, social engineering, and audit and evidence tampering. Its Hugging Face dataset page identifies DeCompBench under a CC-BY-4.0 license and requires users to accept access conditions before viewing files.

The result is useful because it does not treat refusal as a full safety proof. It compares monolithic presentation with decomposed presentation, and it preserves the difference between asking an agent to say something unsafe and asking it to operate tools until a harmful state is reached. The authors evaluate each task against checkpoints describing concrete environment changes, then separate full success, partial success, no success, refusal, and capability failure.

That evaluation shape is the important part. A benchmark for agents has to ask whether the external state changed, not only whether the model produced a forbidden sentence. A decomposed job can leave no single toxic utterance and still assemble the materials, messages, edits, exports, or records needed for harm.

Attack Anatomy

A decomposition attack has five separable pieces.

The safety system can fail at any of those points. It may never infer the parent objective. It may approve subtasks because each looks harmless. It may lose continuity when conversation history is cleared. It may allow a tool call because the immediate arguments look normal. It may log the pieces without preserving the link that makes them one job.

Why Local Checks Miss the Job

The arXiv abstract reports that state-of-the-art agents showed high refusal rates for monolithic harmful tasks but much lower refusal rates for decomposed variants. In the results section, the authors report sharp refusal-rate drops for the tested agents after decomposition: Qwen3-Coder from 21 percent to 0 percent, Claude Haiku from 90 percent to 2.5 percent, and GPT-5-mini to 6 percent after refusing most monolithic tasks. The important governance point is not the leaderboard. It is the shape of the failure.

The same results section reports that attack success increased under decomposition: Qwen3-Coder from 17 percent to 36 percent, Claude Haiku from 0 percent to 70 percent, and GPT-5-mini from 0 percent to 70 percent. The authors also report higher checkpoint-pass rates under decomposition. Those figures should be read as paper-reported controlled experiments, not as stable rankings of vendors or models. Their force is comparative: the same harmful objective becomes easier to execute when it is split into plausible work.

A local guardrail sees one turn, one command, one API call, one file operation, or one tool result. A decomposed job uses that locality against the system. It places safety-relevant meaning in the relation among steps rather than in the apparent content of each step. The harm becomes visible only when the partial outputs are composed.

This is why agent safety needs a cumulative ledger. Each delegated job should carry a durable intent record, intermediate artifacts, source and destination labels, tool receipts, and a running interpretation of what the sequence is making possible.

Capability and Refusal Are Entangled

The paper's results also avoid a measurement trap. A failed decomposed attack is not always a safety success. The HTML table of contents names a specific finding: failures to complete decomposed attacks can arise from execution errors rather than safety refusals. In Appendix B, the authors compare GPT-5-mini on malicious OpenAgentSafety tasks and DeCompBench monolithic tasks, reporting 58.6 percent full compliance on the OpenAgentSafety subset, but 0.0 percent full success and 90.7 percent refusal on DeCompBench monolithic tasks.

For governance, that distinction is essential. If an agent avoids harm because it cannot operate the environment, that is a capability ceiling, not a safety mechanism. The ceiling may rise with better tools, clearer scaffolds, more robust retry loops, or lower-friction credentials.

The sober reading is that decomposition attacks sit between behavior policy and systems engineering. A model may be trained to refuse the obvious request, but the deployed agent is also a workflow executor. It has memory, tools, credentials, retry logic, and logs. The safety object is the whole harness, not only the sentence that began the task.

The Composed-Task Ledger

The defensive artifact is a composed-task ledger: a record that binds subtasks into a reviewable job. It should not expose private chain-of-thought or store every draft forever. It should preserve the operational facts needed to reconstruct whether a series of benign-looking steps formed a prohibited outcome.

A useful ledger should include the parent task claim, user or workflow principal, agent identity, session or account boundary, tool manifest, permission class, source artifacts, generated artifacts, external destinations, database rows or files touched, prior related actions, denied actions, approvals, stop rules, state changes, and the policy version applied. The ledger should also record when continuity is deliberately broken: new account, new session, new model, new tool server, or cleared context.

This is stricter than ordinary logging. A log may say that a file was exported, a message drafted, and a repository updated. A composed-task ledger asks whether those actions were part of one dangerous construction. It belongs beside agent receipts, runtime governance, agent observability, and agent audit and incident review.

Failure Modes

The first failure mode is subtask laundering. A harmful objective is converted into neutral work tickets, and each ticket passes because no individual ticket names the harm.

The second is environment-memory blindness. The system clears chat history but preserves state in files, databases, queues, repositories, or cloud storage, so the next subtask continues the attack through the world rather than through the transcript.

The third is capability-as-safety confusion. A failed attack is counted as a safe refusal even though the model attempted the work and failed only because the tool call, environment, or scaffold broke.

The fourth is account-boundary evasion. A monitor tracks one user, session, or agent instance while the adversary splits subtasks across identities, tenants, models, or tools.

The fifth is artifact-flow opacity. Partial outputs are copied into documents, tickets, messages, branches, caches, or memory stores without labels showing their source and intended downstream use.

The sixth is permission accumulation. No single step needs broad authority, but the combined sequence reads sensitive data, transforms it, stages it, and sends it through permissions that were reviewed one at a time.

The seventh is benchmark optimism. A model refuses monolithic harmful prompts in a red-team suite, and the organization treats that as evidence that tool-mediated workflows are safe.

The eighth is remedy gap. A later reviewer can identify the harmful composed task but cannot roll back, notify, delete, quarantine, or repair the state changes because the ledger did not connect the pieces in time.

Governance Standard

Any production agent with meaningful tool authority should be evaluated against decomposition-aware misuse, not only against direct forbidden prompts. The evaluation should include whole-job safety cases, cross-turn and cross-tool aggregation, budgeted attack attempts, benign-subtask isolation tests, artifact-flow review, and separate accounting for refusal, technical failure, and completed harmful outcome.

First, test composition explicitly. A release gate should include tasks where the harmful meaning exists only across steps, artifacts, sessions, or tools.

Second, score outcome state. For agents, safety evidence should inspect final environment state, not only model text. The question is whether the unauthorized export, send, deletion, edit, upload, permission change, or staged artifact occurred.

Third, keep refusal separate from failure. Reports should distinguish safety refusal, policy escalation, partial compliance, technical failure, and completed harmful outcome. A broken tool is not a safety control.

Fourth, bind subtasks to authority. Tool calls should carry purpose, principal, permission class, destination, and parent-job metadata where feasible. If a subtask cannot be tied to a legitimate parent purpose, it should receive narrower authority.

Fifth, monitor artifact flows. Files, database records, messages, commits, cloud objects, and memory writes created by the agent should retain provenance labels that survive later use.

Sixth, treat identity and session changes as risk signals. A decomposed attack may use different accounts, agents, or contexts. Security review should look for converging artifact flows, not only repeated prompts from one actor.

Seventh, combine prompt, tool, and runtime controls. Local refusal, tool allowlists, least privilege, human confirmation, data-loss prevention, rate limits, sandboxing, audit logs, and rollback should be evaluated as one defense system.

Eighth, run regression after capability changes. Better tool calling, retries, planning, memory, connectors, or credentials can turn yesterday's capability failure into tomorrow's successful attack.

Ninth, preserve review without overcollection. The composed-task ledger should contain enough evidence for incident review and appeal without retaining unrelated private text, secrets, or hidden reasoning.

Tenth, require an exit path. If a composed task starts crossing a prohibited boundary, the system should be able to pause, narrow, escalate, quarantine artifacts, revoke credentials, and roll back reversible changes.

What This Changes

The decomposed task is the policy problem in miniature.

Institutions often govern by local category. This prompt is allowed. This command is allowed. This file read is allowed. This message draft is allowed. This export is allowed. Decomposition attacks show the weakness of that view. The risk may not live in any one tile. It lives in the mosaic.

That is why agent governance has to become sequence-aware. A tool-using model is not only a speaker. It is a worker moving through state. The safety question is not only what it said, but what its partial work made possible.

The rule is simple: if an agent can execute a delegated job in pieces, the pieces cannot be governed one at a time. The safety boundary is the composed task.

Source Discipline

This article treats Kothamasu, Smith, and Yadav's paper as a June 2026 arXiv preprint and identifies quantitative results as paper-reported controlled experiments. The arXiv abstract, HTML, and PDF support the submission date, authorship, DeCompBench construction, task count, tool-rich settings, refusal-rate drops, attack-success increases, and capability-failure distinction. The Hugging Face page supports dataset availability and access-gated conditions; it should not be treated as a safety certification.

Related research should be read by scope. Adversaries Can Misuse Combinations of Safe Models studies composition across models and subtasks, while Monitoring Decomposition Attacks in LLMs with Lightweight Sequential Monitors studies sequential monitoring as a proposed defense. OpenAgentSafety is useful as a broader agent-safety benchmark with real tools and adversarial or ambiguous tasks, but DeCompBench's claim is narrower: decomposition-by-design against tool-using agents.

Security and standards sources also have boundaries. NIST's AI Agent Standards Initiative is a standards program, not a deployment approval. OWASP's Top 10 for Agentic Applications is community security guidance, not law. MCP specifications define protocol behavior and security recommendations for tool use, not a complete governance regime. The allied Careful Adoption guidance is operational cybersecurity guidance. Anthropic's espionage report is a vendor threat-intelligence report; it supports the existence of claimed real-world decomposition tactics but should not be flattened into an independent public finding about every detail of the incident.

Sources

Return to Blog