The Agent Never Broke the Sandbox. It Didn't Have To.
Four AI coding agents, one escape, and the reason hardening the sandbox is aiming at the wrong wall.
Four AI coding agents, one escape, and the reason hardening the sandbox is aiming at the wrong wall.
Date: 2026-08-21 | Classification: TLP:CLEAR
Why this matters. Stop auditing whether your agent's sandbox holds. Audit what runs the files the agent writes inside it, because that is the process with the real privileges, and it was never in the sandbox.
The Operator's Take
There is a comfortable mental model of AI coding agents that goes like this: the agent runs in a sandbox, the sandbox is the wall, and security is a question of how strong the wall is. Pillar Security spent a week taking that model apart, and the finding is not that the walls are weak. It is that the attacks do not go through the wall at all.
In four separate agents, Cursor, Codex, Gemini CLI and Google's Antigravity, the same move worked. The agent stays inside its sandbox the whole time and writes a perfectly ordinary file. Something outside the sandbox then reads that file and runs it, with privileges the sandbox never had. The escape is not an exploit against the sandbox. It is an abuse of the trust the rest of your machine places in whatever the sandbox produced.
That distinction is not academic. It decides where you spend the next audit, and most teams are spending it on the wrong wall.
What Actually Happened
An AI coding agent does not live alone. It sits inside a workspace, and around that workspace is a ring of trusted tooling that was built to act on files: the git client that reads repository metadata, the editor that runs task definitions, the shell that sources environment files, the interpreter that a virtual environment points at, the hook runner that executes configuration the moment a project loads. None of that tooling is inside the sandbox. All of it trusts the workspace, because the workspace is where your code lives.
The sandbox is supposed to stop the agent from doing anything dangerous. So the agent does something that is not dangerous. It writes a file.
Then a trusted process outside the sandbox opens that file and does exactly what the file says.
The specific files change per tool, and that is the tell that this is a class rather than a bug. Pillar's write-up names several. A .claude hook file that the host executes on load, which carried its own CVE and is now fixed. A modified virtual-environment interpreter, so the next time anything in that environment runs Python, it runs the attacker's Python instead. A Docker socket left reachable, which hands the agent the keys to the host container runtime. A VS Code tasks.json, which the editor will happily run. In every case the agent did the same thing: it produced a legitimate-looking artifact, and a component that was never sandboxed treated that artifact as authoritative.
| Agent | What the agent wrote | What ran it, outside the sandbox |
|---|---|---|
| Cursor | A .claude hook file (CVE-2026-48124, fixed) |
The host hook runner, on project load |
| Cursor | A modified virtualenv interpreter | The next Python invocation in that environment |
| Codex, Cursor, Gemini CLI | A reachable Docker socket | The host container runtime |
| Antigravity | Two artifact classes the vendor downgraded rather than fixed | Trusted editor tooling |
The Antigravity line is the one to sit with. Two of the issues were not fixed. They were reclassified as lower severity and left in place. That is a vendor looking at the same mechanism and deciding it is acceptable, which tells you the boundary is contested, not settled.
The part people will get wrong
The instinct on reading this is to harden the sandbox. Tighter isolation, fewer capabilities, a stricter jail. That instinct is aimed at the wall, and the wall was never breached.
The privilege that mattered belonged to the process outside the sandbox: the git client, the hook runner, the editor, the interpreter. You can make the sandbox perfect and change nothing, because the exploit never asked the sandbox for anything. It asked a trusted tool to read a file, and that tool said yes, the way it always has.
Hardening the sandbox is the control that feels like progress and buys none.
What It Means
The reason this matters beyond four coding tools is that it is the same shape as everything else happening in agentic security right now. An open-weight model gets its refusals stripped and the safety that was inside the model evaporates, so the control has to live outside it. A supply-chain worm this month wrote its persistence straight into Claude Code hook files, using the exact boundary Pillar is describing, because the agent's own configuration is a place trusted code will run. The labs are pouring effort into the model, watermarks, capability thresholds, refusal training, and the exploited seam is one layer down, in the code that trusts what the model produced.
So the audit question is not "is my agent sandboxed." Almost certainly it is. The question is: when my agent writes a file, what reads it, and with what privileges? Enumerate the trusted consumers. The git client that parses repository metadata. The editor that runs tasks. The shell that sources dotfiles. The interpreter a virtual environment resolves to. The hook system that fires on load. Every one of those is a process that will act on agent output and was never inside the box you were guarding.
The uncomfortable conclusion is that the more capable and autonomous these agents get, the more files they write, and the more surface this boundary has. You do not fix that by making the agent smarter or the sandbox tighter. You fix it by treating everything an agent writes as untrusted input to the tools that consume it, and validating at that boundary the way you would validate anything else that crossed from outside. The sandbox was the wrong wall. The consumers are the wall, and right now most of them are wide open by design.