AI Coding Agents Keep Escaping Sandboxes: Pillar Security's 'Week of Sandbox Escapes' Exposes Systemic Trust Problem

TL;DR

If you run AI coding agents locally or in CI/CD pipelines, your sandbox is probably not keeping you safe. Pillar Security just completed "The Week of Sandbox Escapes" — a 7-part research series demonstrating that all four major AI coding agents (Cursor, OpenAI Codex CLI, Google Gemini CLI, and Google Antigravity) can escape their sandboxes. The kicker: none of the escapes required breaking the sandbox directly. Instead, researchers exploited a systemic "trust handoff" flaw — AI agents write files that trusted host-side tools later execute without scrutiny. Three vendors have patched. Google downgraded both of its tools' severity.

What Happened

On July 20, 2026, Pillar Security began publishing a coordinated disclosure series titled "The Week of Sandbox Escapes" — one deep-dive per day, each demonstrating a different route across the sandbox boundary. The research spanned several months of work and covered four widely-used AI coding agents:

• Cursor (Anysphere) — AI-native IDE with agentic coding
• OpenAI Codex CLI — OpenAI's terminal-based coding agent
• Google Gemini CLI — Google's command-line AI coding tool
• Google Antigravity — Google's AI-powered filesystem operations agent

Multiple CVEs have been assigned, though specific CVE numbers were not uniformly disclosed across all findings at time of writing.

The Attack Mechanism: Trust Handoff, Not Sandbox Break

Here is the critical insight from Pillar's research: in almost every case, the AI agent did not need to break the sandbox directly. The attack exploited a "trust handoff" pattern:

1. The AI agent operates inside a sandbox that restricts what it can execute directly
2. But the agent can write files — configuration files, scripts, build artifacts
3. These files are later consumed by trusted host-side tools (package managers, build systems, CI/CD runners, shell initialization scripts)
4. Those trusted tools execute the file contents with host privileges — no questions asked

The researchers demonstrated concrete attack chains:

• Convincing the agent to write malicious shell configuration that gets sourced on the next terminal session
• Getting the agent to modify build scripts that run during the next npm install or pip install
• Planting code in project files that get picked up by automated CI/CD pipelines

This is not a sandbox implementation bug. It is a design-level trust boundary failure: the sandbox correctly prevents the agent from executing arbitrary commands, but nobody thought to check whether files written by the agent could be weaponized downstream.

Four Repeatable Failure Modes

Pillar Security's findings clustered into four repeatable failure modes across all four tools:

1. File-to-Execution Bridges — Agent-written files consumed by host tools (most common across all vendors)
2. Configuration Poisoning — Modifying project configs that automation tooling blindly trusts
3. Dependency Chain Injection — Planting code in dependency manifests resolved by package managers
4. Environment Variable Manipulation — Agents influencing host environment state through indirect writes

Vendor Responses

Google's decision to downgrade Antigravity's findings has drawn attention. While Google acknowledged both reported bypasses as valid security findings, the "Other valid security vulnerabilities" classification means they are not treated with the same urgency as actively exploitable CVEs. This is controversial — Antigravity is designed for filesystem operations, making the trust handoff attack surface particularly large.

Why This Matters for Developers

If you are using AI coding agents today, here is the uncomfortable reality: your sandbox is a speed bump, not a wall. The attack surface is not the sandbox boundary — it is every file the agent can write and every host-side tool that might later read those files.

Specific risk scenarios:

• Local development: Agent-written .bashrc/.zshrc modifications persist across sessions
• CI/CD pipelines: Agent-modified build scripts execute in automated pipelines with deployment credentials
• Team environments: One team member's agent writes malicious config that gets committed and executed by every other team member's automated tooling
• Open source contributions: Agents reviewing or modifying pull requests could inject payloads into project configs

What You Should Do Right Now

1. Never run AI coding agents with elevated privileges

This sounds obvious, but many developers run sudo pip install or npm install -g inside agent-augmented workflows. If the agent can modify package.json and your npm install runs as root, you have handed the agent an escalation path.

2. Audit what files your agent can write

Most sandboxes focus on restricting execution, not file writes. Check whether your agent can write to ~/.bashrc, ~/.gitconfig, ~/.npmrc, Makefile, pyproject.toml, or any file that gets auto-executed or auto-sourced.

3. Treat agent outputs as untrusted input

This is the fundamental mindset shift Pillar's research demands: files written by an AI agent are untrusted input, not trusted output. Your build system, your CI/CD pipeline, your shell — none of them should blindly consume agent-generated files. Add verification steps between agent output and host execution.

4. Isolate agent environments

Run AI coding agents in fully isolated environments (containers, VMs, or dedicated development machines) where the blast radius of a sandbox escape is contained. Do not run agents on the same machine that holds production credentials or deployment keys.

5. Monitor for emerging CVEs

If you use Cursor, Codex, Gemini CLI, or Antigravity, update to the latest version immediately. Monitor the specific CVEs as they are published for any additional mitigation steps.

My Take

Pillar Security's research is important not because it found bugs — it is important because it exposed a category error in how the industry thinks about AI agent security.

We have been treating AI coding agents like regular user-space applications: put them in a sandbox, restrict their syscalls, and call it done. But AI agents are qualitatively different. They are generative — they produce new content that flows into other systems. A regular application writes a config file because you told it to. An AI agent writes a config file because a language model decided to, possibly under the influence of prompt injection or training data bias.

The trust model that assumes "files written by tools on my machine are safe" breaks down completely when one of those tools is an LLM-powered agent with unpredictable outputs.

This is not a problem that will be solved by better sandboxes. It requires rethinking the entire trust architecture between AI agents and host systems. The agent should not be treated as a trusted writer that happens to be sandboxed — it should be treated as an untrusted input source whose outputs must be verified before consumption.

Until that architectural shift happens, every developer running AI coding agents is implicitly trusting a language model with their host system's integrity. Pillar Security just showed us why that trust is misplaced.