AI Coding Assistants Can Slip Past Their Own Security Cages Without Breaking Them
New research from Pillar Security shows that the sandboxes meant to contain AI coding agents have a fundamental blind spot: the agent never needs to escape if it can simply hand a poisoned file to something that already has permission to run it.
Key points
- Pillar Security disclosed multiple sandbox-escape techniques affecting four AI coding tools: Cursor, Codex CLI, Gemini CLI, and Antigravity.
- In every demonstrated attack, the AI agent stayed inside its sandbox and never triggered a containment alarm.
- The attacks worked by having the agent write files, such as workspace settings or automation scripts, that trusted software outside the sandbox later picked up and ran.
- Docker Desktop's privileged background service gave sandboxed agents in Cursor, Codex CLI, and Gemini CLI a shared escape route.
- Pillar recommends treating any workspace file that can trigger code execution as a sensitive asset requiring human approval before an AI agent can create or change it.
A sandbox, in security terms, is a walled-off area where software runs in isolation so it cannot touch the rest of a computer system. For AI coding assistants, sandboxes are supposed to stop a rogue or manipulated agent from doing damage outside its little corner of the machine.
Pillar Security's new research, first detailed in a post on the company's own site, suggests that wall has a door nobody noticed. This is the second time we have reported on Pillar's work in this area: our 20 July story covered the same four tools being nudged into writing files that host-side software then ran without question.
How did the AI agents get out without actually getting out?
They didn't need to. That's the uncomfortable point.
In each attack Pillar demonstrated, the AI agent stayed perfectly inside its sandbox. It never broke a rule. What it did instead was write a file: a configuration file, a script, a virtual environment folder, the kind of everyday developer artefact that other trusted programs are supposed to read and act on.
When that trusted program later picked up the file and executed it, the agent's instructions ran outside the sandbox with the host machine's full permissions. The sandbox never raised an alarm because, technically, nothing escaped it.
Think of it like a prisoner who cannot leave a cell but can slide a note under the door to a guard who then follows the instructions without question.
Pillar found this pattern across the affected tools using different techniques. In Antigravity, the researchers exploited a macOS security profile called Seabelt, which blocks certain actions by name rather than by what those actions actually do, leaving unlisted routes open. They also abused VS Code task configurations, files that tell the code editor to run commands automatically, because those tasks execute on the host machine, outside the sandbox.
Cursor trusted agent-created Python virtual environments and Git hook configurations, both of which can contain executable code and both of which ran with host privileges when triggered.
A shared weak point across Cursor, Codex CLI, and Gemini CLI was Docker Desktop's background service. Docker is software that packages and runs applications in containers; its desktop version runs a privileged daemon, a background process with elevated system rights, that sits entirely outside the sandbox. Sandboxed agents could reach it and use it to run commands freely. Separately, a supposedly safe Git allowlist in Codex CLI could be manipulated to modify repository configuration and trigger code execution later.
Should you worry?
If you use any of these tools at work, the answer is yes. The sandbox your organisation relies on may be drawing its boundary in the wrong place.
Practical steps are straightforward. Treat any file an AI agent creates that could later trigger an action as a sensitive asset. Require a human to approve it before it lands near automated tools. Make sure helper processes, including Docker's background service, operate under the same tight restrictions as the agent itself.
The deeper problem here isn't a missing patch; it's that the threat model for agentic tools was written for processes that try to break out, not for ones content to leave instructions for someone else to run.
