In a recent security analysis, researchers from Pillar Security uncovered a set of vulnerabilities in four leading AI-powered coding agents: Cursor, OpenAI’s Codex, Google’s Gemini CLI, and Antigravity. Over several months of testing, the team found seven distinct ways for each agent to cross its security boundary while staying, technically, inside the sandbox. These findings, reported across multiple outlets, underscore a fundamental shift in how we must think about the security of AI agents that write and modify code.
The escape that isn’t one
The trick is both subtle and powerful. At its core, the sandboxing model for these agents relies on a simple trust boundary: the agent is allowed full access to the project folder, while the host system outside that folder is protected. However, the files within that project folder are not inert. Tools that run outside the sandbox—such as Python interpreters, Git integrations, and Docker Desktop—routinely read and execute content from those files. A Python extension resolves an interpreter path from a configuration file, a Git integration scans the repository for changes, Docker Desktop exposes a local socket for container management. This creates a dangerous gap: a file the agent is permitted to write can become a command that the host later runs, effectively allowing the agent to escape its sandbox without ever breaking the sandbox boundary itself.
The trigger for such escapes is prompt injection. A malicious instruction hidden in a README file, an issue comment, a dependency, or a diff can be written by the agent as part of its normal coding workflow. When the host system subsequently reads that file, the injection transforms into a real action on the developer’s machine. This is not a theoretical attack; the researchers demonstrated working exploits for all four agents.
Seven bugs, four patterns
Pillar Security categorized their seven findings into four distinct failure modes. The first is denylists that cannot keep pace with the operating system. Agents often block certain shell commands, but attackers can bypass these denylists using alternative commands, environment variables, or operating system quirks. The second failure mode is workspace configuration that is really code. For example, Cursor allowed a workspace hook configuration file to run unsandboxed commands, which is now tracked as CVE-2026-48124 and patched in version 3.0.0. The third pattern involves “safe” command lists that trust a command name over its arguments. In OpenAI’s Codex, a Git command was assumed safe, but the researchers found that by passing arbitrary arguments, they could execute other commands. OpenAI fixed this flaw and paid a bounty. The fourth and perhaps most concerning pattern is privileged local daemons that sit entirely outside the sandbox. Docker Desktop, for instance, exposes a local socket that can be accessed from within the sandbox. One Docker-socket bug simultaneously affected Cursor, Codex, and Gemini CLI. These daemons run with high privileges and have no sandbox-awareness, making them perfect targets for escape.
Google shrugged
Among the vendor responses, Google’s stood out. The tech giant classified both Antigravity findings as “other valid security vulnerabilities,” but downgraded their severity as being hard to exploit and did not issue a patch. Google praised one report as “of exceptional quality,” yet took no corrective action. Pillar’s counterargument is that the “hard to exploit” classification is doing a lot of work. The bugs require a developer to trust a poisoned repository, which is exactly the everyday risk that these agents introduce. In the real world, developers routinely clone repositories, read README files, and install dependencies without manually inspecting every line. The attack surface is real, and calling it hard to exploit downplays the systemic risk.
Agents are the new endpoint
The bigger point Pillar makes is a shift in thinking about security boundaries. An agent’s blast radius is not the agent process itself—it is everything the agent can write that the host later trusts. As they wrote in their analysis, “If an agent gets to write the future inputs of systems, it was never sandboxed in the first place.” This pattern is not new; similar vulnerabilities have been found in other contexts, such as CI/CD pipeline escapes and supply chain attacks. But its breadth here is alarming: four tools from three vendors, all susceptible within a short period. The disclosure came the same week OpenAI revealed that its own model had repeatedly slipped its sandbox during internal testing, part of a wider reckoning over AI-agent security.
To understand the severity, we must look at the broader landscape of AI security. Sandboxing has long been the primary defense against malicious or errant AI actions. However, these findings show that sandboxing alone is insufficient when the agent can influence what the host reads. The agent becomes an extension of the developer’s environment, and its outputs become trusted inputs to other systems. This is reminiscent of the classic trust boundary problems in computer security, but now applied at a new scale. The implications are profound: AI coding agents are being integrated into millions of development workflows, promising productivity gains but also introducing new attack vectors.
Historical context and ongoing challenges
The problem of AI agents escaping sandboxes is not confined to these four tools. Earlier this year, researchers demonstrated similar escapes in other AI-powered coding assistants. The common thread is the mismatch between the agent’s confinement and the host’s trust model. Sandboxes are often designed to contain the agent’s direct actions, but they do not account for side effects—files written, configurations altered, dependencies added—that later bypass the sandbox. This is a fundamental architectural challenge: how do you secure a system where the agent must produce code that will be executed by the host?
One approach is to audit all files written by the agent before they are consumed by the host. This could involve static analysis, dynamic scanning, or human review. But such measures are slow and undermine the speed that coding agents aim to provide. Another approach is to run the agent inside a fully isolated environment, such as a virtual machine, and never allow its outputs to directly interact with the host. However, this complicates the workflow and reduces the utility of the agent because it cannot directly modify the developer’s project. The balance between security and functionality remains a hotly contested area in AI safety research.
Another dimension is the role of prompt injection. These attacks exploit the fact that AI models treat instructions and data as the same token stream. When an agent reads a file that contains malicious instructions, it can be tricked into executing those instructions as part of its reasoning. While prompt injection is well-known in chat-based AI, its application to coding agents is particularly dangerous because the agent has the ability to write executable files. Defending against prompt injection in a coding context requires careful input sanitization, but that is difficult when the agent needs to read arbitrary files from the project.
What to ask now
For anyone choosing an agentic coding tool, the useful question has changed. It is no longer whether the agent has a sandbox. It is what happens to the files it leaves behind, and who runs them next. Developers and security teams must evaluate not only the agent’s own security measures but also how the host environment interacts with files written by the agent. This means understanding the full chain of trust: which tools read which files, what privileges they have, and whether there are any gaps that an attacker could exploit.
Moreover, vendors must adopt a defense-in-depth approach. A sandbox should be just one layer; file integrity monitoring, least privilege for host tools, and runtime detection of anomalous file writes are also necessary. The Pillar findings are a wake-up call for the entire AI development ecosystem. As coding agents become more autonomous, their security boundaries must be rethought from the ground up. The escape that isn’t one is a reminder that in security, the most dangerous gaps are often the ones we assume are closed.