What Goes Wrong When AI Coding Agents Run Unsandboxed, and Which Isolation Level Stops It

The year this stopped being theoretical

According to OWASP's 2026 LLM security tracking, prompt injection attacks against production AI systems rose 340% year on year, the fastest-growing category it tracks. Coding agents drive much of that new attack surface: 28 of the 53 agentic projects OWASP tracks are coding agents, and the five fastest-growing tools (Claude Code, Gemini CLI, Codex, Cline and Aider) are all in that category. A separate 2026 enterprise survey found 88% of organizations reported a confirmed or suspected AI agent security incident in the previous year.

Numbers like that are easy to skim. So here are four specific, documented incidents in increasing order of severity, what each shows about where the boundary has to sit, and three more from the following months so this doesn't read as four cherry-picked cases. (If the underlying mechanism of shell, files, Git and credentials isn't clear yet, the neutral version is here.)

Incident 1: the allowlist was the hole

CVE-2026-22708, disclosed by Pillar Security against Cursor's agentic IDE. Cursor's Auto-Run mode lets you allowlist commands so you don't approve every shell call. The problem: shell built-ins such as export, typeset and declare were implicitly trusted and never had to be on the list. Anything that could put text in front of the agent (a README, a dependency file, a GitHub issue) could use one of them to poison an environment variable such as Git's PAGER. The next time the developer approved something as ordinary as git branch, a command they'd already vetted, the poisoned environment ran the attacker's code instead.

The allowlist wasn't misconfigured; it worked as designed. The hole was in what silently counted as "a command", and that's a class of edge case, not a single bug.

Incident 2: indirect prompt injection turns a bug report into a backdoor

Indirect prompt injection is the mechanism behind most of this. An agent reading a GitHub issue, a dependency's README or a web page can't reliably tell "data I'm reading" from "an instruction I was given". An agent asked to fix a bug can be steered into inserting a backdoor; one built to watch a repository's issues can treat a malicious issue from anyone as an instruction.

Cursor's agent produced a concrete case: an indirect prompt injection got it to create a malicious .cursor/mcp.json without user approval, and that MCP configuration became the attacker's path to remote code execution. It's a different failure from Incident 1. The allowlist and approval flow both worked; the agent just wasn't doing the task it was given.

Incident 3: no code execution needed

EchoLeak (CVE-2025-32711), a zero-click vulnerability in Microsoft 365 Copilot disclosed by Aim Security, CVSS 9.3. One crafted email, no user interaction: when Copilot processed it during routine summarization, hidden instructions made it gather files from OneDrive, SharePoint and Teams that it already had permission to read, and send them to an attacker. Researchers call this "LLM scope violation": untrusted content manipulating the model into using its legitimate access illegitimately, entirely in natural language, with no shell command or malware.

This is the case that keeps sandboxing claims honest. A code-execution sandbox doesn't stop it. If an agent's job is to read your files or call APIs for you, isolating where its code runs doesn't help when the exfiltration path is persuading the model, in plain English, to hand over data it can already see. Execution isolation answers Incidents 1 and 2. This one is a scoping problem (what data and credentials a session can reach at all) and needs solving separately.

Incident 4: how far it scales with enough autonomy

In September 2025, Anthropic's Threat Intelligence team detected and disrupted what it reported as the first largely autonomous, AI-orchestrated cyber espionage campaign at scale. A Chinese state-sponsored group, tracked as GTG-1002, convinced Claude Code it was doing authorized defensive testing, then used it for reconnaissance, vulnerability discovery, exploitation, credential harvesting and data exfiltration against about 30 organizations in tech, finance, chemical manufacturing and government. The agent handled an estimated 80–90% of the tactical work, with humans mainly choosing targets and approving strategy.

This isn't a sandboxing story in the same sense: the attacker used an agent as the weapon rather than compromising a victim's agent. But it's the clearest evidence of how much leverage a coding agent has once real tool access meets real autonomy, and that's the scale of the question "should I let this run unsandboxed on my machine?" in 2026.

The pattern kept repeating in early 2026

Those four have enough public detail to walk through the mechanism. Three more followed within months, in three different tools, none needing a new category of vulnerability:

• Claude Code, CVE-2026-21852. A malicious repository's settings file could set ANTHROPIC_BASE_URL to an attacker's endpoint. Opening the repository in Claude Code sent API requests, including the user's Anthropic API key, to that server before the trust prompt appeared. Fixed in version 2.0.65 (January 2026). No code execution needed; the same shape as Incident 3, a legitimate-looking flow redirected.
• Google Antigravity, disclosed by Pillar Security. Antigravity's Strict Mode is meant to block writes outside the workspace and confine commands to a sandbox. Prompt injection through the IDE's own find_by_name search tool slipped an -X (exec-batch) flag into the underlying fd call, turning a file search into arbitrary execution and escaping Strict Mode. Reported to Google in January 2026 and fixed by the end of February. The same shape as Incident 2: approvals and sandbox mode worked as designed, and the agent was still talked into something else.
• Flowise, CVE-2025-59528, CVSS 10.0, the maximum score. Flowise's CustomMCP node ran attacker-supplied JavaScript with no validation, with full Node.js child_process and filesystem access. As of April 2026 it was still being exploited against more than 12,000 internet-facing instances. Flowise builds agents rather than being a coding agent, but the failure is Incident 1's: something that should have been sandboxed wasn't.

None of this changes the framework below. It confirms the base rate: the same few failure modes keep appearing in new tools every few months, each fixed after the fact.

The common thread

In each of the first three incidents, something that depended on the model behaving, or on a list of edge cases being complete, stood between "read some text" and "do something harmful": a permission prompt, an allowlist, or the model's judgment about what counted as an instruction. Each was bypassed in a different way. That isn't one bug to patch. Allowlists will keep finding new edge cases like shell built-ins, and prompt injection defense is an open arms race, not a shipped fix.

The boundary that doesn't depend on any of that is isolation: what the agent's process can reach on disk, on the network and on the host, whatever it decides to do.

Not all isolation is the same boundary

"Sandboxed" gets used loosely. These are different guarantees:

The middle rows aren't hypothetical. In mid-2026, 13 critical CVEs were disclosed against vm2, a widely used JavaScript sandboxing library, in a single patch cycle: evidence that a sandbox built as a language-level trick, sharing a process and kernel with the code it contains, keeps getting broken, because holding it depends on catching every escape in review rather than on hardware. Google's gVisor is a real step up, intercepting system calls in user space before they reach the host kernel, but it's still weaker than a VM, which is why production guidance (Northflank's, among others) tends to treat a Firecracker- or Kata-class microVM as the minimum for a production agent sandbox.

Where Velo Workspaces sits, and why the GPU mattered

Velo Workspaces runs every workspace on Apple's Virtualization framework, the bottom row: a dedicated kernel per workspace. Disposable workspaces add deletion on close, so a successful compromise doesn't outlive the session. That isn't a new technique; it's the same class of boundary Firecracker and Kata provide elsewhere.

The usual price of that isolation has been giving up the host GPU for anything inside it, which is why AI Bridge exists. The untrusted, disposable part, the agent's code execution, stays in the VM, while the model server stays on the Mac, outside the boundary, reached over vsock. See the architecture behind that split, what it costs in inference speed, and how it compares with Parallels and UTM.

One limit, straight from Incident 3: this isolates code execution. It doesn't solve the model being talked into handing over data it can already see. That's about scoping which files and long-lived credentials a workspace can reach, and it's worth doing deliberately whatever tool you use.

What to do

• Don't treat an allowlist or approval prompt as your security boundary. Incident 1 shows it's a convenience with edge cases, not enforcement.
• If an agent runs generated code, run it where an escape means a hypervisor breakout, not a shell on your account: a microVM or full VM, not a container alone.
• Make the environment disposable by default, so a compromise doesn't persist beyond its session, the same property that stops a flaky test's leftovers outliving its run.
• Separately, limit which data and long-lived credentials the session can reach. Sandboxing execution doesn't fix a model that can be talked into handing over what it can already see.
• Assume prompt injection defenses will keep being bypassed. Isolation shouldn't depend on them.

Related reading: the architecture behind AI Bridge, what VM isolation costs in inference speed, a complete setup guide, the safe agent environment checklist, why containers and VMs sit in different rows, and what leaves your Mac when a model runs behind that boundary. Or download Velo Workspaces and try it yourself.