Sandboxes have become a key security control for AI coding agents, but new research suggests they may not provide the isolation many organizations assume.
Pillar Security has disclosed a series of vulnerabilities showing how agents in tools such as Cursor, Codex, Gemini CLI, and Antigravity can indirectly cross security boundaries without technically escaping their sandboxes.
“In almost every case, the agent did not need to break the sandbox directly,” the researchers said in a blog post. “It only had to write something that a trusted component outside the sandbox would later run, load, scan, or treat as safe.”
The findings outlined four specific and repeatable failure modes in AI sandboxes. These included denylist sandboxes failing growing OS complexity, workspace configurations turning out to be executable code, command allowlists trusting command names instead of invocations, and privileged local daemons that sit outside the sandbox entirely.
“CISOs and security buyers need to realize that it’s not enough for an agentic IDE or CLI to have a sandbox,” the researchers said, adding that it is important to know where the sandbox’s actual boundary is.
Escaping sandboxes without breaking them
Pillar challenged the basic understanding of sandboxing in AI-assisted development. Rather than escaping through kernel exploits or container breakouts, the demonstrated attacks relied on an indirect mechanism.
In all shown attack paths, the agent remains confined while producing files that trusted host-side applications subsequently consume.
Those files may include workspace configuration, automation scripts, IDE settings, and virtual environment contents that naturally participate in a developer’s workflow. When external tools later execute or interpret those files outside the sandbox, code originating from within the isolated environment effectively crosses the security boundary without violating the sandbox’s rules.
Different sandbox escapes for different agents
Pillar demonstrated the pattern across multiple AI coding tools using different techniques. In Antigravity, the researchers exploited weaknesses in the denylist-style macOS Seabelt profile and abused VS Code task configurations that were later executed outside the sandbox. Cursor, meanwhile, was shown to trust agent-created Python virtual environments, alternate Git directories, and workspace hook configurations that ultimately ran with host privileges.
The researchers also found a common escape path affecting Cursor, Codex CLI, and Gemini CLI through Docker Desktop’s privileged daemon, allowing sandboxed agents to execute commands outside their restricted environments.
In another Codex CLI finding, a supposedly safe Git allowlist could be manipulated to modify repository configuration and trigger code execution at a later stage.
Agentic development demands a different security model
Pilar argued that enterprises need a new security model for agentic software. The existing endpoint protections typically focus on whether a process can escape its execution environment. But autonomous agents challenge this by continuously generating content that other trusted systems consume.
The researchers recommended treating workspace configurations that can trigger execution as sensitive assets, requiring explicit approval before agents create or modify host-side automation, ensuring that helper processes operate under the same security policy as direct agent execution, and preserving provenance that distinguishes user-created files from repository- or agent-generated content.
Organizations were also advised to model security policies around command side effects rather than simply process invocation, limit access to privileged local services, and monitor trust handoffs throughout the development workflow.
No Responses