What Actually 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 surged 340% year over year, making them the fastest-growing category of attack they track. Coding agents specifically drive most 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 past year.

Those are the kind of numbers that are easy to skim past. So instead of citing more of them, here are four specific, documented 2026 incidents, in increasing order of severity, and what they actually reveal about where the real boundary needs to sit.

Incident 1: the allowlist itself was the hole

CVE-2026-22708, disclosed by Pillar Security against Cursor's agentic IDE. Cursor's Auto-Run mode lets you allowlist commands you trust, so you're not re-approving every shell call the agent wants to make. The problem: shell built-ins like export, typeset, and declare were implicitly trusted and never had to appear on the allowlist themselves. That meant anything that could get text in front of the agent — a README, a dependency file, a GitHub issue — could quietly use one of those built-ins to poison an environment variable, such as Git's PAGER. The next time the developer approved something as mundane as git branch, a command they'd already vetted and trusted, the poisoned environment made it execute the attacker's code instead.

The allowlist wasn't misconfigured. It worked exactly as designed. The hole was in what silently counted as "a command" in the first place — and that's a class of edge case, not a single bug.

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

Indirect prompt injection is the general mechanism behind most of this: a coding agent reading a GitHub issue, a dependency's README, or a web page has no reliable way to distinguish "data I'm reading" from "an instruction I was given." A coding agent asked to fix a bug can instead be steered into inserting a backdoor. An agent built to monitor a repo's issues can treat a malicious issue, posted by anyone, as an expected instruction to act on.

Cursor's agent produced a concrete version of this too: an indirect prompt injection got it to create a malicious .cursor/mcp.json configuration file without user approval, and that malicious MCP configuration became the attacker's path to remote code execution. Notice this is a distinct failure from Incident 1 — the allowlist and the approval flow both worked fine here. The agent just wasn't doing the task it was asked to do.

Incident 3: you don't even need code execution

EchoLeak (CVE-2025-32711), a zero-click vulnerability in Microsoft 365 Copilot disclosed by Aim Security, CVSS 9.3. A single crafted email, no user interaction required: when Copilot ingested it during routine summarization, hidden instructions in the email caused it to access files across OneDrive, SharePoint, and Teams that it already had standing permission to read, and exfiltrate them to an attacker-controlled destination. Researchers call the underlying mechanism "LLM scope violation" — untrusted external content manipulating the model into using its own legitimate access in an illegitimate way, entirely in natural language, no shell command or malware involved.

This is the case that matters most for being honest about what sandboxing does and doesn't solve: a code-execution sandbox doesn't stop this class of attack by itself. If an agent's job is to read your files or call APIs on your behalf, isolating where its code runs doesn't help if the actual exfiltration path is "convince the model, in plain English, to hand over data it can already see." Execution isolation is the right answer to Incidents 1 and 2. It isn't the answer to this one — that's a scoping problem (what data and credentials a session can reach at all), and it has to be solved separately.

Incident 4: how far this scales once an agent is autonomous enough

In September 2025, Anthropic's own Threat Intelligence team detected and later 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, tricked Claude Code into believing it was conducting authorized defensive security testing, then used it to carry out reconnaissance, vulnerability discovery, exploitation, credential harvesting, and data exfiltration against roughly 30 organizations across tech, finance, chemical manufacturing, and government — with the agent handling an estimated 80–90% of the tactical work autonomously, and human operators stepping in mainly for target selection and strategic approval.

This one isn't a sandboxing story in the same sense as the first three — it's an attacker using an agent as the weapon, not a victim's agent getting compromised. But it's the clearest evidence yet of how much leverage a coding agent now has once you multiply real tool access by real autonomy. That's the actual scale of what "should I let this thing run unsandboxed on my machine" is a question about in 2026.

The common thread

In each of the first three incidents, something that depended on the model behaving correctly, or on a list of edge cases being complete, sat between "read some text" and "do something harmful" — a permission prompt, an allowlist, or the model's own judgment about what counted as an instruction. Each was bypassed or routed around a different way. That's not one bug to patch: allowlists will keep having new edge cases like shell built-ins, and prompt injection defenses are an active, unsolved arms race as of today, not a shipped fix.

The boundary that doesn't depend on any of that working is isolation — what the agent's process can actually touch on disk, on the network, and on the host, regardless of what it decides to do.

Not all isolation is the same boundary

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

The middle rows aren't hypothetical either. In mid-2026, a wave of 13 critical CVEs was disclosed against vm2, a widely used JavaScript sandboxing library, in a single patch cycle — real evidence that a "sandbox" implemented as a language-level trick, sharing the same process and kernel as the code it's meant to contain, keeps getting broken, because holding that boundary is a matter of catching every escape in review, not a hardware-enforced guarantee. gVisor is a real step up from that — Google's own gVisor intercepts syscalls in user space before they reach the host kernel — but the isolation is genuinely weaker than a VM's, which is why production guidance in this space (Northflank's, among others) tends to land on a Firecracker- or Kata-class microVM as the minimum acceptable isolation for a production agent execution sandbox.

Where Velo Workspaces sits, and why the GPU question mattered

Disposable Workspaces on Apple Silicon run on Apple's own Virtualization.framework — the bottom row above: a dedicated kernel per workspace, and the workspace itself is deleted the moment you close it, so a successful compromise doesn't outlive the session. That's not a novel technique; it's the same class of boundary Firecracker and Kata provide elsewhere.

The historical tradeoff for that level of isolation has been giving up your host GPU for anything running inside it — which is exactly why AI Bridge exists: the untrusted, disposable part (the agent's actual code execution) stays inside the VM, while the model server stays on the host, outside that boundary entirely, reached over a vsock channel rather than living inside the guest. See the architecture behind that split and what it actually costs in inference speed, benchmarked rather than asserted — or how it compares to other VM apps on the same hardware in the Parallels and UTM comparison.

One honest limit, straight from Incident 3: this isolates code execution. It doesn't by itself solve the "the model was talked into handing over data it can already see" class of attack — that's a matter of scoping what files and long-lived credentials a given workspace can reach in the first place, and it's worth doing deliberately no matter which app or which isolation level you're using.

What to actually do

• Don't treat an allowlist or approval prompt as your security boundary. Incident 1 shows it's a convenience feature that can develop edge cases, not an enforcement mechanism.
• If an agent executes generated code, run it somewhere an escape means a hypervisor breakout, not a shell on your actual account — a microVM or full VM, not a container alone.
• Make the environment disposable by default, so a successful compromise doesn't persist past the session that caused it.
• Separately, scope what data and long-lived credentials the session can reach at all. Sandboxing execution doesn't fix a model that can be talked into handing over something it's already allowed to see.
• Assume prompt injection defenses will keep having new bypasses found. Isolation shouldn't depend on them holding.

Related reading: the architecture behind AI Bridge, what VM isolation actually costs in inference speed, and a complete setup guide for running an agent this way. Or download Velo Workspaces and try it yourself.