The Week of Sandbox Escapes
Introducing SAIL 2.0 Framework: A Practical Guide to Secure AI Agents
Introducing SAIL 2.0 Framework: A Practical Guide to Secure AI Agents
Explore
Resources
Company
menu<br>Platform<br>Redgraph<br>Solutions
Resources
Company
Get a demo
Platform (5)<br>Platform overview<br>AI Discovery & PostureRed Teaming & Attack Surface ExposureRuntime GuardrailsGovernance & Compliance<br>Latest Announcement<br>Pillar Security Named as a 2026 Gartner® Cool Vendor in AI Software Security
Platform<br>Solutions (5)<br>Solutions
Use cases<br>Homegrown AIAgentic EndpointAI Gateway SecurityMCP & Tool SecurityAgentic AI SecurityEmbedded-AI<br>Industry
HealthcareFinancialTechnology
Resources (4)
Resources
BlogPillar ResearchSAIL 2.0 Framework
Latest Resource<br>Introducing SAIL 2.0 Framework: A Practical Guide to Secure AI Agents
Company (4)<br>Company
About UsNewsroomPartnersCareers
Get a demo
Get a demo
Blog<br>RESEARCH
min read
The Week of Sandbox Escapes
By<br>Eilon Cohen
and<br>Dan Lisichkin & Ariel Fogel
July 20, 2026
min read
Why agentic security needs its own threat model<br>Executive Summary<br>Over several months, Pillar Research found and reproduced sandbox escapes and boundary bypasses across Cursor, Codex, Gemini CLI, and Antigravity. In almost every case, the agent did not need to break the sandbox directly. It only had to write something that a trusted component outside the sandbox would later run, load, scan, or treat as safe. In aggregate, these vulnerabilities show that AI coding agents change the endpoint threat model, and that most sandbox designs have not caught up.<br>We are releasing the research as The Week of Sandbox Escapes : one deep-dive a day, each showing a different route across the boundary. The findings cluster into four repeatable failure modes:<br>Denylist sandboxes that cannot keep pace with OS complexity<br>Workspace configurations that are really executable code<br>"Safe" command allowlists that trust command names instead of invocations<br>Privileged local daemons that sit outside the sandbox entirely<br>The bottom line is that an agent's blast radius is not the agent process; it includes everything the agent can write that the host later trusts.<br>The productivity gains of agents are real, and developers are already using them. The problem is that these tools became infrastructure before most organizations governed them as infrastructure.<br>CISOs and security buyers need to realize that it's not enough for an agentic IDE or CLI to have a sandbox. It needs to prove where the sandbox boundary actually is, what the agent can write, which host components trust those writes, which local daemons it can reach, which commands skip approval, and what telemetry exists when a trusted helper executes something the agent influenced.<br>Agentic tools are becoming endpoint actors. They need to be assessed, monitored, and governed like endpoint actors.
Pillar’s Approach<br>At Pillar, we look at AI adoption through the lens of enterprise risk.<br>Agentic coding tools are a natural place to start because they concentrate endpoint risk in one workflow. They run where source code, SSH keys, cloud tokens, browser sessions, package-publishing rights, and production access often live close together. They process untrusted input as a matter of routine: READMEs, issues, docs, dependencies, code comments, diffs, logs, and web content. They are built to act, not just answer.<br>Put that together, and prompt injection stops being a chatbot problem. A malicious instruction can become a local action on a developer machine.<br>Most products address that risk with sandboxes, approval prompts, and safe-command policies, but those controls often focus on the agent process alone. The agent's power also includes the files it can write and the host components that later trust those files.<br>How Agents Escape Their Sandboxes<br>The general rule of thumb for sandboxes is that inside the workspace is allowed, and outside the workspace is protected.<br>In practice, sandbox boundaries have at least three layers:<br>Direct execution: what the agent process can run.<br>Workspace writes: what files the agent can create or change.<br>Host trust: what unsandboxed components later do with those files.<br>The third layer is where the most interesting failures live. Modern IDEs and CLIs are full of host-side automation:<br>Python extensions discover interpreters<br>Git integrations scan repositories<br>VSCode task runners load project tasks.<br>Hook engines fire lifecycle commands<br>Docker Desktop exposes a powerful local socket<br>A sandboxed agent can follow every rule it is given and still shape the inputs those components consume.<br>That is the imaginary or perceived boundary: believing "the agent can only write inside the project" is the same as "the agent cannot affect the host."
But that is an incorrect assumption. On developer endpoints, project files are often executable infrastructure.<br>The Series
Post<br>Platform<br>How the Boundary Failed<br>Status / Advisory<br>Link
Escaping Antigravity's allow-default...