A Poisoned README Can Turn Your AI Coding Agent Into a Shell for Attackers

The safety filter reads the command. Bash runs something else.

On June 30, 2026, the security research firm Adversa AI published findings on eleven of the most widely used open-source AI coding agents, the tools that let a developer hand off building, testing, and fixing code to an autonomous assistant. Ten of the eleven could be tricked into running destructive shell commands that their own safety checks were built to block. Only one, an agent called Continue, held.

The trick itself is old. It is a set of shell behaviors documented in security literature for decades, aimed at a target that did not exist until recently. Understanding why a decades-old trick works on a brand-new tool is the whole story here, because the weakness is not a bug in any single product. It is an assumption the whole category shares.

How the bypass works

Adversa named the weakness GuardFall. Every agent it tested ships a tool that runs shell commands on the developer's own machine, which it needs in order to compile code, install packages, and commit to git. Because that shell carries the full power of the user's account, with access to SSH keys, cloud credentials, and everything in the home directory, most agents put a guard in front of it: a filter that scans the command text and blocks anything that looks dangerous, such as rm -rf /. The flaw is a mismatch that shell programmers have known about for years. The guard checks what a command looks like as text, while Bash, the interpreter that actually runs it, executes what the command means after it expands and rewrites the string. Those two things are not the same.

A few examples make it concrete. Write the deletion command as r''m and a filter hunting for rm sees two harmless tokens, but Bash strips the empty quotes and runs rm. Swap the spaces for $IFS, the shell's internal field separator, and rm$IFS-rf$IFS/ reads as a single word to the filter while Bash splits it back into rm -rf /. Base64-encode the payload and pipe it through echo ... | base64 -d | sh, and every visible piece looks benign because the destructive part only exists after the shell decodes it. None of this needs the attacker to touch your machine. It needs the agent to read attacker-controlled text, which is where prompt injection comes in: the practice of hiding instructions inside content an AI assistant will process as if it were ordinary data.

• The instructions can ride in on a poisoned README or Makefile, a package description on npm or PyPI, a fetched web page, or a malicious MCP server (a connector that feeds an AI assistant external tool results).
• Blunt "delete everything" prompts are usually refused by the model. The bypass works because the commands arrive framed as routine build steps. Adversa's live tests ran on Anthropic's Claude Sonnet 4.6.
• The risk multiplies in CI (continuous integration, the automated pipeline that builds and tests code on every change), where teams switch on auto-approve flags like --auto-exec so the agent can run unattended, removing the person who would otherwise see the command.

Why it matters

The concrete result is a prompt-injected RCE (remote code execution, meaning an attacker runs commands of their choosing on your system) that leaves little trace. A guard that fires on rm -rf stays silent while a plain cp quietly copies ~/.aws/credentials or ~/.ssh/id_rsa somewhere the attacker can collect them. If your engineering team has wired an AI coding agent into its build pipeline with auto-approve turned on, then an untrusted pull request, or a dependency whose README the agent reads while researching a library, becomes a direct path to your cloud secrets and your source code. The broader shift is the harder pill. The defense most of the industry reached for, a denylist that pattern-matches command text, cannot do the job, because it is trying to predict the behavior of a language built specifically to rewrite its own input. Piling on more banned patterns closes none of the holes. Ten of eleven tools got this wrong not through carelessness but because the flawed mental model was the standard one.

What to do about it

1. Turn off auto-approve on any agent that can reach a real shell, live credentials, or production data. The instant a human stops confirming each command, prompt injection becomes silent code execution, so keep manual approval wherever the agent runs on a host that matters.
2. Run coding agents in a disposable sandbox rather than on your workstation. A throwaway container with no access to your real home directory or cloud keys means a destructive command wrecks nothing you cannot rebuild, which is the design Adversa found actually closes the attack.
3. Treat repository content as untrusted input, not documentation. A README, Makefile, or dependency description pulled into an agent's context can carry hidden instructions, so isolate agent runs on unfamiliar code the same way you would sandbox an unknown executable.

Bottom line

GuardFall is not the kind of vulnerability a patch closes on Tuesday. It is evidence that the safety layer many teams lean on, a filter that reads commands as text, was never equal to the task. The two approaches that survived Adversa's testing were a sandbox you can throw away and a guard that evaluates what the shell will genuinely do, and only one popular agent shipped the latter. The question worth putting on the table at your next security review is plain: if someone slipped a hostile instruction into a repository your build pipeline reads tomorrow, is there a human or a sandbox standing between that instruction and your credentials, or just a filter that has already been beaten?