What agent isolation really isolates: five boundaries from build jobs to live tool calls

An agent can run in a container, a WebAssembly interpreter, a microVM or a hosted tool executor. Those environments have different boundaries. A user may see only the assistant's interface while the real authority is held by a build worker, a host-language bridge, a shell process or an application API. Recent research provides enough concrete cases to separate those mechanisms without claiming that one isolation technology universally succeeds.

A Beta9 advisory describes tenant-supplied image steps executed through a privileged Buildah worker that relies on chroot in the reported path. That changes the process's filesystem root but does not itself create isolated mount, process or user namespaces. The exposure is a build-time boundary; it is not automatically a breakout from a running inference container. Advisory.

A Prefab UI advisory describes a different problem: guest Python executing in Pyodide can reach Deno host APIs through the JavaScript bridge. Here the crucial question is which objects and permissions the host exposes, not whether the guest syntax is Python or runs atop WebAssembly. A host process with filesystem and network authority can accidentally provide paths around the intended guest boundary. Advisory.

These are reports about specified versions and configurations. Neither source supplies a reliable production victim count or proves that all installations have the same effective privilege set.

DeepSeek's superagent prototype documents Tickets, admission rules and long-lived Executor Sessions. The sessions can issue shell commands without per-command approval as the operating-system user running the prototype. This is a deliberately documented capability, not a vulnerability disclosure. The threat question moves to how the task was admitted, what tools and filesystem locations are reachable, and what happens if an authorization rule changes after the worker starts. Execution design.

Tracekit Box takes a contrasting approach. Its authors place agent code inside a guest microVM without a conventional network interface and broker external destinations and secret use through a host-side vsock service. They report thirteen successful KVM checks in their test setup. This shifts enforcement out of the prompt and into a smaller host boundary, but it does not automatically prevent an approved destination from relaying sensitive information or prove every covert channel is closed. Prototype paper.

VELA examines forty-four known web application vulnerabilities across twelve selected applications. The paper reports that forty were realizable in a scripted baseline and that roughly 91 percent remained exploitable through its reference agent-mediated interface. An interface can remove a dangerous operation, but it can also leave the same backend vulnerability reachable through a legitimate-looking tool. The exact outcome depends on exposed operations, object permissions and the attack task. The benchmark does not establish prevalence of vulnerabilities in unrelated MCP deployments. Study.

A related Gemini CLI OAuth issue locates the possible network escape before normal tool invocation, during metadata fetching and registration. Destination controls need to be present on the actual network request, not only on the URLs checked in advance. The case is a reported potential flaw without a known production compromise. Issue.

The common engineering test is simple to state and difficult to fake: issue a harmless forbidden request, observe where the authoritative permission check happens, and reconcile the actual side effect with a receipt. A refusal generated by a model, an isolation label and a passed unit test are not interchangeable evidence of containment.