Agent sandboxes can break: a Gemini CLI permission vulnerability

Coding agents like Claude Code, Codex and Gemini CLI have gained immense popularity in the past year. They are simple and powerful — harnessing agentic capabilities around frontier LLMs. They can be connected to virtually any digital service via MCP servers, Bash, custom “recipes” (“Skills”), plugins, and more. With great power comes great security risk. Put simply, the larger the circle of influence of tools, the larger the risk.

Ideally, a mitigation should be transparent, easy to set up, and reduce the approving human’s fatigue. A key mitigation to an agent’s blast radius is setting execution boundaries. For example, in order to prevent secrets from spilling, one can enforce a no-read policy on particular file signatures — such as **/.env, **/.aws, and **/.ssh — without significantly compromising the agent’s effectiveness for most user workflows.

Similarly, one can define a list of patterns that can be auto-approved, for example Bash(mkdir *), Read(**/docs), or Bash(curl https://my-company-dev-account.com *).

This is a useful pattern for mitigating “approval fatigue,” wherein the human-in-the-loop is overwhelmed by approval requests from the agent — to the point where they virtually auto-approve anything. With this pattern, human attention is limited to critical actions. The pattern is offered by major CLI agents like Claude Code and Gemini CLI.

At Mint Security, we were wondering — can we completely trust this permission perimeter? We have found that the answer is no — these permissions are powerful, but not necessarily hermetic. In what follows we describe an example of a vulnerability we discovered in Gemini CLI.

Case study: how Gemini CLI enforces permissions

Since Gemini CLI is an open source project, it serves as a useful example where we can analyze the code and showcase what happens at the permission perimeter.

Let’s assume we want to auto-approve mkdir, which is relatively benign. We will set:

You can already imagine that chaining:

should NOT work. Indeed it doesn’t. Gemini CLI employs an open-source parser, tree-sitter, that parses such composite commands and rejects them from auto-running.

The parsing mechanism of Gemini correctly classifies most commands. However, we found that it has a weak spot. If the agent runs:

i.e., a mkdir command with “redirection,” it reads as mkdir and runs via bash. It turns out that bash allows this reverse shell vulnerability as well, and a network connection opens between the agent and a third party — potentially an attacker.

This case was reported to Google, who confirmed and amended it.

Take-aways

The connective nature of agents makes them incredibly powerful but also difficult to secure reliably. For those that build agentic frameworks, the conclusion must be to continuously audit their security stack, as it might depend on incomprehensive third parties or misuse them. It was recently demonstrated in Anthropic’s preview of Claude Mythos [1], which escaped its sandbox during training. In our example above, for instance, one amending approach for macOS could have been to replace bash with zsh.

For users of agentic systems, the example above underscores the need for comprehensive defensive security around such systems:

• Monitor agents at runtime for suspicious and dangerous activities, including but not limited to network exfiltration.
• Consider implementing sandboxing at the OS level, which is offered by major frameworks including Claude Code and Gemini CLI. It allows, for example, granular definition of a network access envelope.

Disclosure

The vulnerability was reported to Google on Dec. 12, 2025. It was accepted and was awarded a bug bounty. The vulnerability was amended in Jan. 2026.

References

[1] Assessing Claude Mythos Preview’s cybersecurity capabilities. https://red.anthropic.com/2026/mythos-preview/