GuardFall: coding-agent command guards inspect text the shell rewrites

What is this?

On June 30, 2026, Adversa AI published GuardFall, a study of how open-source AI coding agents decide whether a shell command is safe to run. The firm tested eleven popular open-source coding and computer-use agents and found the same weakness in ten of them; only one, Continue, was built to resist it. Coverage followed from The Hacker News, SecurityWeek, and SC Media.

The finding is not a single product bug. Adversa frames it as “a dangerous convention and a class of problems” — which is why there is no single identifier to track or patch. The agents guard shell execution by matching each command against a blocklist of dangerous patterns as plain text. The shell then rewrites that same text — stripping quotes, expanding shortcuts — before it runs. The filter and the shell look at two different strings. This is the same inspection-versus-execution mismatch that has driven SQL injection and classic shell injection for decades, resurfacing in the agent runtime.

It is a close cousin of the Microsoft agent shell denylist bypass: a blocklist that reasons about the wrong representation of the command.

How it works

An agent that guards by pattern-matching raw text is checking a representation the operating system never actually executes. The gap is easiest to see with quote removal: a filter watching for a destructive delete command sees nothing wrong with a version where empty quotes are inserted between two letters, because to a text matcher those are different strings. Bash discards the empty quotes and runs the original command anyway.

Guard inspects:   r''m  -rf  <path>     -> no blocklist match ("rm" not present as text)
Bash executes:    rm    -rf  <path>     -> quotes removed, real command runs

No working payload is reproduced here — the point is structural, and the underlying shell quirks have been public knowledge for decades. The same idea generalizes: a command hidden in a base64 blob and piped into a shell, or an ordinary, allowlisted tool (a file finder, a disk utility) turned destructive with the right flag. Adding more blocklist entries fixes none of it, because the guard is reasoning about the wrong artifact.

Two conditions must line up, and neither is exotic:

• The model has to emit the command. A blunt request to delete everything is usually refused, but the same instruction tucked inside routine work — a build file, or a tool’s “documentation” reply the agent reads mid-task — gets emitted as an ordinary step. This is indirect prompt injection supplying the payload.
• The agent has to be running unattended, with an auto-execute flag on or the container sandbox switched off — both routine in automated pipelines. Adversa’s live tests used Claude Sonnet 4.6.

The ten tools that left the gap open were opencode, Goose, Cline, Roo-Code, Aider, Plandex, Open Interpreter, OpenHands, SWE-agent, and the Hermes project, where the issue first surfaced. Together the surveyed tools carried roughly 548,000 GitHub stars as of May 2026. Adversa demonstrated the full attack end-to-end against the production Plandex binary and saw the same shape work against eight others. It describes the work as lab research; no public exploitation has been reported.

Why it matters

These agents run shell commands with the developer’s full account privileges. Point one at a booby-trapped repository or dependency, and a hidden instruction can quietly run a command that wipes files or reaches whatever the account can — SSH keys, cloud credentials, anything in the home directory. The precondition is a daily developer habit: clone an unfamiliar project, let the agent work in it. That makes this a credible supply-chain path, in the same family as AutoJack and Agentjacking, where untrusted content becomes a command the agent runs with its owner’s rights. The common thread across all of them: untrusted text reaches a real shell before the guard understands what bash will actually do.

Defenses

The durable fix is architectural, and one tested tool already demonstrates it.

1. Guard the executed command, not the text. Continue held up because it reads the command the way bash will before deciding: it tokenizes and expands the string into the same pieces the shell would produce, checks what actually runs, and keeps a hard list of destructive commands blocked outright. Adversa calls the design portable and estimates re-implementation at about two engineer-days. Parse-then-check, never match-raw-text.

2. Prefer allowlists over blocklists. A denylist of “dangerous” patterns is a losing game against shell rewriting. Permit a small set of known-safe commands and refuse the rest, evaluated after expansion.

3. Neutralize the blast radius. Point $HOME at a throwaway directory so secrets like ~/.ssh and ~/.aws are out of reach, and keep the container sandbox on. If the command escapes the guard, it should still land nowhere useful.

4. Do not run unattended on untrusted input. Turn off auto-execute flags (--auto-exec, --auto-run, --auto-test, dangerously-skip-permissions) unless the job genuinely cannot pause for a human, and never run an agent against pull requests from forks — the shortest path from an attacker’s file to your secrets.

5. Treat repo-shipped config as untrusted code. A configuration file committed inside a repository (for example .aider.conf.yml) can steer the agent on the first accepted edit. Review it before the agent acts on it.

Status

Item	Reference	Date	Notes
GuardFall disclosure	Adversa AI	2026-06-30	Class-level convention; no single CVE assigned
Scope tested	Adversa AI	2026-06	11 open-source agents; 10 vulnerable, Continue resistant
End-to-end demo	Adversa AI	2026-06	Production Plandex binary; lab research, no public exploitation
Related bypasses	LLM Hacking	2026	Shell denylist bypass, AutoJack, Agentjacking — same inspection/execution gap

The honest framing is not “an AI tool has a bug” — it is that a guard which inspects command text cannot secure a shell that rewrites that text before running it. Until agents parse commands the way the shell does, the defense is yours to apply: check the executed command, prefer allowlists, sandbox the runtime, and keep a human in the loop on anything untrusted.