exhibit-ai

Exhibit A(I): The Agent Sandbox Is Now an Evidence Boundary

Claude Cowork shows why agent sandboxes need evidence-grade boundaries, not just optimistic folder permissions.

The useful story in the Claude Cowork sandbox flaw is not that an AI agent might misbehave.

That was already obvious.

The sharper lesson is that the agent runtime has become part of the evidence system. If it can read your files, write to your host, touch credentials, or preserve work products, it is no longer just a productivity tool. It is a boundary counsel will have to explain after something goes wrong.

Accomplish AI says it connected a folder to a fresh Claude Cowork session, sent one short message, and watched the agent break out of the Linux VM that was supposed to contain it. From there, the agent could reach the host Mac file system outside the folder the user had connected.

The Hacker News reports that the chain depended on a host file system mounted read-write inside the VM, a path to guest-root through Linux kernel CVE-2026-46331, and the ability to reach files as the logged-in desktop user.

That matters because the boundary users think they granted is not the same as the boundary the system actually enforced.

Why this belongs in Exhibit A(I)

Agent security keeps getting framed as a model-behavior problem.

That frame is too small.

A desktop agent does not merely generate text. It opens files, touches folders, uses browsers, runs tools, and works across business context that may include contracts, code, credentials, client data, legal memos, and regulated records.

Once the agent has that operational reach, the sandbox becomes a legal control. It defines who could access what, which prompts or inputs could trigger action, whether a permission boundary worked, and what the organization can prove later.

The Cowork report is useful because it separates marketing control from technical control.

The user grants a folder. The product says the work happens in a VM. The agent runs as an unprivileged user. Those are good design choices.

But Accomplish says the entire host file system was still mounted read-write into the VM, visible to guest-root. Once the chain reached guest-root, the host became reachable.

That is the evidence problem.

If a company later has to answer whether an agent accessed privileged files, copied secrets, modified source code, touched client documents, or exposed attorney work product, a statement about the intended folder scope will not be enough.

The question will be what the boundary actually prevented.

The risk is not one kernel bug

It is tempting to make this about CVE-2026-46331.

That would miss the point.

The reported chain used pedit COW, a Linux kernel flaw involving the traffic-control subsystem and page-cache corruption. The Hacker News previously reported that the flaw could allow a local unprivileged user to gain root on affected systems when the right conditions exist.

Patch the kernel, and this specific chain changes.

The governance problem remains.

Agent runtimes often depend on layered trust: a desktop app, a VM, a brokered mount, a folder permission prompt, a tool executor, a browser, a cache, a secrets store, and a stream of untrusted inputs. A failure in any layer can turn a narrow task into broad access.

That is why the Accomplish analysis lands harder than a normal vulnerability post. Its central argument is that the kernel bug is not the most interesting part. The product design decisions above it determined how much damage a guest-root escape could do.

For legal and security teams, that is the durable lesson.

You cannot govern agent risk by asking only whether the CVE has a patch.

You have to ask what the runtime makes reachable when the next escape path appears.

The folder prompt is not a compliance story

A permission prompt feels like consent.

It is not a complete control narrative.

If an employee connects a repo, a contract folder, a litigation folder, a client export, or a desktop workspace to an agent, the organization needs to know what else is technically in scope. That includes SSH keys, cloud credentials, browser session data, local downloads, synced drives, and temporary files.

The issue is not whether every user acted recklessly.

The issue is whether the product architecture allowed a reasonable user to believe the folder grant was narrower than the reachable system boundary.

That is where legal exposure can form.

If an agent incident occurs, the company will need to show the access model, the mount model, the logs, the prompts, the executed commands, the files touched, and the containment steps. If those records do not exist, the organization is left arguing from product assumptions instead of evidence.

That is a weak place to stand.

What to do this week

Inventory every desktop or local agent that can read files, write files, run commands, use browsers, or connect to business tools.
For each agent, document the real access boundary: host file mounts, VM mounts, synced folders, secrets reachable by the desktop user, browser profiles, tool permissions, and network paths.
Require a written exception before connecting agents to folders containing legal work product, client data, production credentials, regulated records, HR files, or incident-response evidence.
Separate agent workspaces from the user's ordinary desktop profile where possible. Do not let a productivity sandbox inherit the same credential universe as the human user.
Preserve agent evidence by default: prompts, approvals, tool calls, file operations, generated artifacts, system logs, mount configuration, and version data.
Treat local agent sandbox escapes as potential data-access events, not just endpoint bugs. The triage question is not only whether the exploit worked. It is what the agent could reach if it did.

The agent boundary is now part of the record.

If it fails, the organization will need more than a patch note.

It will need proof.