A sandboxed agent is not a secured agent

There is a specific kind of trust a team extends the moment it lets an AI agent read a repository, touch a filesystem, or run commands on a machine. The vendor calls it a sandbox, an isolated session, or a promise that your code stays local. Engineers read those words as a security boundary. Too often, in 2026, they turn out to be closer to a description of intent than a description of the shipped product.

Two disclosures in the same month made that gap visible in two unrelated tools. Neither company set out to mislead anyone. Both shipped agent tooling faster than they verified what it actually did with the access it was given.

What "sandboxed" promised, and what it delivered

Claude Cowork, Anthropic's local coding-agent product, runs an agent inside a Linux virtual machine on the user's Mac. The pitch is containment: the agent works inside the VM, the host stays out of reach. On July 23, security researchers at Accomplish AI disclosed SharedRoot, an attack chain that broke that containment. The VM's root daemon mounts the folder a user attaches to Cowork into the guest as a shared, writable filesystem. Chained with CVE-2026-46331, a Linux kernel bug in the packet-editing subsystem act_pedit that had already been public for weeks, an unprivileged process inside the VM could reach guest-root and, from there, read and write across the shared mount — SSH keys and cloud credentials included. Researchers reported that a single short message to a fresh session was enough to trigger it, with no permission prompt at any point.

Anthropic's response, per the reporting, closed the disclosure as "informative" rather than shipping a dedicated fix for the local path. The newest release of Cowork now defaults to cloud execution, which takes the local VM out of the equation for most new sessions — a real mitigation, but one that moves the trust boundary rather than closing it. Anyone still running Cowork locally, and anyone who ran it before the default changed, was exposed to a known kernel bug through a filesystem share that made no distinction between "the folder you attached" and "the rest of your machine."

What "local" promised, and what it delivered

The second case is a different failure mode entirely. xAI's Grok Build CLI markets itself, like most coding agents, on the premise that it acts on your behalf inside your environment. Independent researcher @cereblab ran version 0.2.93 through a network proxy and found the tool uploading far more than any task required. In one test, a 12 GB repository generated roughly 5.1 GB of traffic to a Google Cloud Storage bucket named grok-code-session-traces — against 192 KB on the actual model channel. That ratio, documented in a wire-level analysis, is not consistent with selectively reading the files a task needed. It is consistent with uploading the repository itself, commit history included, along with any secret ever committed and later removed from a tracked file.

xAI disabled the server-side upload flag once the analysis became public, but researchers noted that the code path enabling it remains in the shipped binary, gated only by a flag xAI can flip again without a new release. Anyone who ran the CLI against a git repository before the disclosure has to treat every credential ever committed there — current or historical — as potentially in xAI's hands.

The pattern is not the bug. It is the gap.

Neither company built this to fail. Isolating an agent inside a VM is a reasonable design; uploading session context for debugging or product improvement is an ordinary thing for a cloud product to do. What both cases share is a mismatch between the claim a reasonable engineer would infer — "isolated," "your code stays with you" — and the actual, verifiable behavior of the shipped product. Neither gap was found by the vendor. Both were found by outside researchers running the tool and watching what it actually did.

That is the operational lesson, and it has little to do with picking a different vendor. The next agent tool will make a similar claim, and some of those claims will turn out to be aspirational rather than architectural too. Adoption of this category of tooling has been running well ahead of the verification discipline teams normally apply before granting broad filesystem or network access to anything else.

Treat agent tooling like a new vendor, not a new setting

Most engineering organizations already have a process for onboarding a new SaaS vendor that will touch sensitive data: a data-flow review, a question about where data lives, a decision about what it is allowed to see. Agent CLIs and coding assistants routinely skip that process. They get installed the way a linter gets installed — one command, and moments later the tool has filesystem access, shell access, and often network access, inside a repository that also holds months of accumulated secrets.

A short, concrete list is more useful here than a general call for caution:

• Verify the isolation claim, don't just read it. "Sandboxed," "VM-isolated," and "runs locally" describe different architectures with different real guarantees. Ask what the boundary actually is — a container, a VM, a namespace — and treat the vendor's disclosure history as part of the answer, not a footnote.
• Watch the network, not just the permissions dialog. A proxy or egress log on any machine running agent tooling will show, in an afternoon, whether the tool sends what it claims to send. That is exactly how both disclosures above were made — not through a vendor audit, but through an outside party watching the wire.
• Assume committed history is not private, even if the working tree looks clean. Any secret ever committed to a repository an agent has touched should be treated as exposed and rotated, whether or not it is still present in the current files.
• Read "closed as informative" as a scope statement, not a clean bill of health. A vendor deciding a report misses its bug-bounty bar is a business decision about severity thresholds. It is not evidence that the exposure stopped existing for people who kept the old configuration.
• Re-review after every default change. When a vendor quietly shifts the default from local to cloud execution, that changes what data leaves the machine and where it goes — a new decision to evaluate, not a patch to celebrate and forget.

The lesson survives the vendor

Both companies will likely fix these specific issues, if they haven't already. That is not really the point. The point is that "AI agent with broad local access" is now a standing category of tooling inside most engineering organizations, adopted faster than most organizations built the muscle to evaluate it. Two vendors got caught inside a single month not because they are unusually careless, but because outside researchers finally looked.

A sandbox is a claim about architecture. Whether it holds is an empirical question, and until an engineering organization has actually checked, granting an agent access is not a security decision — it is a bet that the marketing copy and the shipped code agree with each other.