Agent Command-Approval Bypass: Shell Rewriting and Git Hooks Against AI Coding-Agent Guardrails

Agent command-approval bypass is SSA descriptive wording for a security-relevant gap between the command an AI coding agent's own guardrail inspects before granting unattended execution and the command the underlying shell or version-control tool actually runs. The defining mechanism is a mismatch in what two layers model as "the same action": an approval check that reads a command as a static string, and an interpreter, bash or git, that rewrites, expands, or auto-triggers on that string according to rules the check never applied. Three documented 2026 sources show this mismatch defeating the guardrail three different ways, in a text-pattern denylist tested against ten open-source agents and in two separate approval mechanisms inside one commercial IDE.

What it is

The defining object is the approval-decision state an agentic coding tool consults before running a shell command or a version-control operation without asking a human first: an allowlist of pre-approved commands, a denylist of blocked patterns, or a sandbox boundary that is supposed to contain whatever the agent runs. The defining cause is that this decision is made against a representation of the action, usually the literal command string the model drafted, that does not match what actually executes once a real interpreter gets hold of it. The defining consequence is that an attacker, or an agent manipulated by prompt injection, does not need to defeat the guardrail's logic at all; the guardrail approves exactly what it was designed to approve, and something else entirely runs underneath it.

Two mechanisms produce this gap. The first is textual: bash performs quote removal, variable and command substitution, and word splitting on a command string after a guard has already inspected the pre-transformation text, so a string that reads as safe to the checker can execute as something else once the shell is done rewriting it. The second is structural: a tool like git has its own trusted, automatic execution paths, hooks fired on routine operations such as checkout or commit, that a sandbox's write protection may not cover, so a write the sandbox was supposed to contain becomes code the sandbox never gets a chance to stop.

What it is not

Sandbox configuration escape, where an already-compromised session writes to host-side configuration, a session hook, or a CI cache entry that a later launch or pipeline run reloads with elevated trust. That entry path requires a later reload across a session or workflow boundary. This entry's defining failure happens inside one approval decision, for one action, with no later reload required: the guardrail is simply wrong about what the single command it is approving will do.
MCP tool poisoning, where the attack targets what a tool's description or result claims. This entry targets what a command-approval mechanism believes a shell string or git operation will do, independent of any tool description.
A denylist that is merely incomplete because a vendor has not yet added a known-bad pattern. The sources below describe a structural mismatch between string inspection and shell execution semantics, present even in a denylist tuned against every pattern its authors could think of.
Reproducible bypass payloads tuned to a specific agent's current guard implementation.

In scope

Guardrails, allowlists, and denylists that inspect a command as a static string before an interpreter transforms it.
Shell-level rewriting, quote removal, variable expansion ($IFS), command substitution, and output piped into an interpreter, that changes what a pre-approved-looking string executes.
Sandbox or isolation boundaries that fail to extend their write protection to a tool's own automatic, trusted execution paths, such as git hooks.
Auto-run or auto-approve modes that let an agent execute commands without per-action human confirmation, which is the precondition that makes any bypass in this class consequential.
Defensive controls for guard architecture, sandbox scope, and least-privilege execution.

Target state, trust boundary, and persistence

The target state is the approval decision itself: the boolean or policy outcome an agent's host application computes to decide whether a command runs unattended. The trust boundary that fails is the assumption that inspecting a command's text is equivalent to knowing what will execute, when in practice a real shell or a real git invocation sits between that inspection and the actual effect, and neither research source below treats that gap as a vendor-specific implementation slip; both treat it as a property of checking a string instead of the interpreter's own behavior.

Persistence varies by mechanism. A shell-rewriting bypass, the GuardFall class below, is single-turn: the mismatch exists for exactly the one command executed and leaves no standing artifact once that command finishes, though an attacker can trigger it again on the next unattended command the agent runs. A git-hook bypass is different: once a malicious hook is written into a repository's .git directory, it persists in that repository and can fire again on a future checkout, clone, or commit in a later session, which makes the git-specific variant cross-session by construction rather than confined to the single action that planted it.

What the research establishes

Adversa AI published GuardFall on 2026-06-30, authored by researcher Omer Ben Simon, after finding that a 30-pattern regex denylist in NousResearch's Hermes agent could be defeated through shell rewriting, a finding that produced a fix commit in that project. The research tested eleven popular open-source coding and computer-use agents and found ten exploitable through the same root cause: "a guard inspects raw text, while system shell (bash) expands, unquotes, and rewrites text before running it." Its worked example is r''m, two tokens to a pattern matcher but one token, rm, to bash once empty quotes are removed. Other documented bypass classes include $IFS substituted for a literal space, command substitution such as $(echo rm), base64-encoded output piped into sh, and destructive operations that avoid the string rm entirely, such as find -delete or dd. The affected agents split into tiers by guard design: Hermes, opencode, and Goose check a denylist against the raw string; Cline's opt-in mode and Roo-Code tokenize but still miss the bypass classes; Aider, Plandex, Open Interpreter's default mode, and Cline's default mode run with no static guard at all; and OpenHands and SWE-agent are sandboxed by default but not in their documented local mode. Only Continue, among the eleven, closed the bypass class the research tested, by tokenizing commands the way bash itself does, flagging variable expansion, recursively checking command substitutions, and inspecting pipe destinations, though the research also found that Continue's CLI --auto flag discards its own soft-block tier. Coverage of the research puts the combined GitHub star count of the ten affected projects at roughly 548,000, and quotes the report's own framing directly: "GuardFall is not a bug, but a dangerous convention and a class of problems" (Adversa AI, GuardFall: a universal shell injection vulnerability in open-source AI agents; Security Affairs, GuardFall Flaw Hits 10 of 11 Popular Open-Source AI Agents (2026-07-01)).

Two separate, fixed vulnerabilities in Cursor, a commercial AI code editor, show the same class of gap reached through different approval mechanisms entirely. CVE-2026-22708 affects Cursor versions before 2.3: when the Cursor Agent runs in Auto-Run Mode with Allowlist mode enabled, certain shell built-ins execute without matching the allowlist and without requiring approval, which lets direct or indirect prompt injection poison the shell environment by setting, modifying, or removing environment variables that influence how later, genuinely allowlisted commands behave. The flaw is classified under CWE-78 among other weaknesses, carries a CVSS 4.0 base score of 7.2, and was fixed in Cursor 2.3 (CVE Record, CVE-2026-22708; Lutra Security Fieldguide, CVE-2026-22708). CVE-2026-26268 affects Cursor versions before 2.5: the sandbox did not sufficiently restrict writes to .git configuration and hook files, so an agent manipulated by prompt injection, or acting on a malicious repository, could write a hook that fires the next time Cursor's agent runs an ordinary git operation such as a checkout, executing outside the sandbox with no further user interaction. Researcher Assaf Levkovich of Novee, who reported the issue, noted that "the underlying Git behavior allowing the attack path is well documented," meaning the flaw is not an obscure git internal but a documented feature the sandbox simply did not account for. The classification is CWE-862, Missing Authorization; the fix shipped in Cursor 2.5; and the severity rating itself became a documented point of disagreement, with NVD's own analysis scoring it 9.9 Critical against Cursor's assigned 8.1 (CVE Record, CVE-2026-26268; CSO Online, Critical Cursor bug could turn routine Git into RCE).

These three sources establish the same underlying claim from three angles: GuardFall shows the gap in open-source agents' own command guards, CVE-2026-22708 shows it in a commercial product's allowlist enforcement, and CVE-2026-26268 shows it in a sandbox's write-protection scope rather than in a command guard at all. None of the three required defeating the model; each defeated the layer sitting between the model's decision and the system's actual execution.

Detection: observable signs

An executed shell command's post-expansion form, what the interpreter actually ran, differs from the literal string an agent's approval log recorded as having been checked.
Environment variables an agent did not explicitly set through an approved action change value between one tool call and the next, especially variables that influence how a later, allowlisted command resolves or behaves.
A git operation, checkout, clone, or commit, triggers execution of a hook script the user did not author, particularly one sourced from a bare repository or a nested directory inside an otherwise ordinary-looking project.
An agent's command-approval log shows a pattern that matches a known-safe allowlist entry character-for-character while producing an effect, a file deletion, a credential read, a network call, inconsistent with that entry's documented purpose.
Auto-run, auto-approve, or --auto-style flags are enabled against a repository or session that processes untrusted content, such as a cloned repository, a fork pull request, or ingested issue text.

Defenses, containment, and recovery

The table below is SSA editorial guidance for defenders. It is neither a standard requirement nor a measured effectiveness ranking.

Control	Transition it interrupts	Applicability	Residual risk and verification
Prefer or require guard architectures that tokenize and canonicalize a command the way the target shell actually parses it, rather than matching patterns against the raw string	A guard approving text that the shell will rewrite into something else before running it	Any deployment selecting or configuring a coding agent's command-approval layer	Per the GuardFall research, this closed the tested bypass class in the one agent (Continue) that implemented it, but that agent's own `--auto` flag still discarded a softer protection tier; verify every execution mode, not only the default one.
Disable auto-run, auto-approve, or `--auto`-style flags whenever the agent will process untrusted content, including cloned repositories, fork pull requests, and ingested issues or documents	Untrusted content reaching an unattended command-approval decision at all	Any agent deployment that offers an unattended execution mode	Removes the precondition for this entire class rather than any single bypass; costs the automation the mode was added for.
Scope sandbox write protection explicitly to every path a wrapped tool treats as trusted executable configuration, including `.git/hooks` and `.git/config`, not only the files the sandbox's own settings live in	A sandboxed write landing in a tool's own automatic execution path instead of the sandbox's protected configuration files	Any coding agent wrapping git, a build tool, or another subprocess with its own hook or plugin-execution mechanism	CVE-2026-26268 shows this gap persisting even in a product that already sandboxes most writes; re-audit after every new tool integration, since each one can introduce its own trusted-execution path.
Block agent-driven execution against fork pull requests and untrusted repositories at the CI or pipeline level, independent of the agent's own guard	Reliance on an agent's own in-process guard as the only control against untrusted repository content	CI and build pipelines that let an agent act on externally contributed code	A pipeline-level block does not help a local, interactive session where the same untrusted repository is opened directly; pair with sandboxed local execution.
Apply least privilege by task type, so code-review, testing, and build tasks each receive only the permissions and environment access that task needs, rather than one standing privilege level for every agent action	Blast radius once any single bypass in this class succeeds	Any deployment that currently grants an agent uniform privilege across unrelated task types	Limits consequence, not occurrence; a scoped-down agent can still be tricked into the action its narrower scope does permit.

Prevention should treat a command-approval guard that only pattern-matches raw text as insufficient by design, and should scope sandbox write protection to every trusted-execution path a wrapped tool exposes, git hooks included, not only to the agent's own settings files. Detection should compare the post-expansion command an interpreter actually ran against the pre-expansion string an approval log recorded, since the two sources above show the gap living exactly in that difference. Containment should disable auto-run modes and revoke credentials reachable from the session the moment a bypass is suspected, treating the agent's standing privilege as already compromised rather than confined to the one command that triggered the finding. Recovery should audit any repository the agent touched for planted git hooks or bare repositories, since a git-based bypass, unlike a single-turn shell bypass, leaves a standing artifact that can fire again in a future session.

Boundaries with similar concepts

This differs from sandbox configuration escape in where the failure happens and what has to happen next. That entry's defining pattern is a write that outlives the sandbox and is reloaded with elevated trust at a later launch or pipeline run, the gap sitting between sessions. This entry's defining pattern is an approval decision that is simply wrong about the single action it is approving, the gap sitting inside one decision; no later reload is required for the GuardFall shell-rewriting class, though the git-hook variant does leave a persistent artifact behind in the way sandbox configuration escape does.

This also differs from MCP tool poisoning in the object under attack. That entry targets the metadata a tool presents about itself, its description or its returned result, and the trust an agent places in that metadata. This entry targets the fidelity of an approval mechanism's model of a command's own execution semantics, independent of any tool description or MCP server involvement at all.

Mapping to standards and research

Source	Source-owned term or item	Relationship to this article
Adversa AI (2026-06-30)	GuardFall	Primary-source research demonstrating the raw-string-versus-shell-semantics bypass class across ten of eleven tested open-source agents.
Cloud Security Alliance, Research Note (2026-07-01)	MAESTRO Layer 3 (Agent Frameworks) and Layer 4 (Deployment); AI Controls Matrix, Execution Control domain	Independent framework mapping of the GuardFall finding, with vendor-neutral mitigation guidance this article's defenses table draws on.
CVE Program / NVD	CVE-2026-22708; CWE-78	Primary-source evidence of a fixed allowlist-bypass defect in Cursor's Auto-Run Mode.
CVE Program / NVD	CVE-2026-26268; CWE-862	Primary-source evidence of a fixed sandbox write-protection gap in Cursor reaching git's own hook-execution path.
OWASP GenAI Security Project	Top 10 for Agentic Applications 2026, `ASI05:2026 Unexpected Code Execution (RCE)`	SSA-selected OWASP category for untrusted content or state becoming executed code through an agent's own tool-invocation path.
MITRE ATLAS	`AML.T0053 AI Agent Tool Invocation`; `AML.T0050 Command and Scripting Interpreter`	SSA-selected ATLAS techniques for the tool-invocation step a bypassed guardrail fails to constrain, and the interpreter-level execution it reaches.
Agent State Attack	Agent command-approval bypass	SSA descriptive framing bundling the GuardFall research and the two Cursor CVEs under one Tool & Environment State entry.

Related terms

Agent state attack: the umbrella definition, including Tool & Environment State among the listed target states.
Sandbox configuration escape: the adjacent Tool & Environment State entry for writes that outlive a sandbox and are reloaded with elevated trust at a later launch, contrasted above by persistence and trigger condition.
MCP tool poisoning: a related Tool & Environment State pattern concerning what a tool's description or result claims, rather than what a command-approval mechanism believes a shell string or git operation will do.
Agent checkpoint poisoning: another Tool & Environment State entry where the failure sits in a framework's own persistence layer rather than in a command-approval decision.

FAQ

Does adding more patterns to a denylist fix this?

Not durably, according to the GuardFall research. Its core finding is that a guard checking raw text cannot keep up with a shell's own rewriting rules, quote removal, expansion, substitution, because each new denylist pattern only blocks the specific strings its author thought of, while the underlying interpreter's transformation behavior stays unchanged and available for the next unconsidered string.

Is this the same as classic shell metacharacter injection?

It shares the underlying interpreter behavior, but the entry path differs. Classic command injection targets an application passing unsanitized external input to a shell. This pattern targets an AI agent's own command-approval layer, a guard specifically built to let the agent run shell or git operations unattended, so the bypass defeats a security control that was added because of agentic autonomy, not a missing one.

Sources

Verification and change history

Standards and versions referenced: OWASP Top 10 for Agentic Applications, Version 2026 (December 2025); MITRE ATLAS, data release v2026.06 (2026-06-30); CWE-78; CWE-862.

Last verified: 2026-10-09. The GuardFall research post, the Security Affairs and Cloud Security Alliance coverage, the CVE Program records for CVE-2026-22708 and CVE-2026-26268, the Lutra Security Fieldguide entry, and the CSO Online article were read from the sources' own pages on this date. The OWASP and MITRE identifiers were selected against this site's previously verified crosswalk entries.

Change history: 2026-10-09, first version.

Working-term label: Mixed provenance. "GuardFall" is an Adversa AI research term. CVE-2026-22708, CVE-2026-26268, CWE-78, and CWE-862 are Standard Terms owned by the CVE Program and MITRE respectively. "MAESTRO" and its layer identifiers are Cloud Security Alliance terms. ASI05:2026 is an OWASP Standard Term. AML.T0053 and AML.T0050 are MITRE ATLAS Standard Terms. "Agent command-approval bypass" as the umbrella title for this entry is SSA descriptive wording, not a term attributed to any single source above.