ArcBox Wants to Replace Docker Desktop and Secure Your AI Agents

ArcBox arrives at a convergence point in developer tooling. On one track, macOS users have spent years looking for an escape from Docker Desktop’s resource appetite and licensing entanglements; OrbStack proved that a nimble, native runtime could make container work on a Mac feel almost transparent, but it remains closed source. On a parallel track, the sudden proliferation of AI coding agents has turned the developer laptop into a contested security perimeter. Running an LLM-driven process with full host filesystem and network access now feels, as one security engineering team described it, like handing a shell prompt to a contractor you just met. The broader demand for microVM solutions tailored to agents is no longer niche. ArcBox’s founding bet is that these two anxieties—container runtime fatigue and agent isolation panic—can be solved by a single, open-source foundation written in Rust.

The project is a from-scratch runtime for macOS that unifies four distinct workloads under one daemon: containers, Linux virtual machines, disposable macOS guests, and microVM sandboxes. Rather than wrapping QEMU or leaning entirely on Apple’s Virtualization.framework, ArcBox implements its own virtual machine monitor on Hypervisor.framework, complete with manual vCPU execution and a full suite of custom VirtIO devices. The list includes network, block, filesystem, console, vsock, RNG, and a balloon driver. A second backend uses a Swift shim to tap Virtualization.framework when the situation demands it, notably for macOS guests that Apple legally restricts to its own hypervisor. Users can switch between the two backends, a flexibility that signals the project’s deeper ambition: to own the entire stack rather than delegate critical paths to third-party code.

That ownership extends to the network datapath, which is where ArcBox’s engineering effort becomes most visible. On macOS, the runtime implements a userspace TCP/IP stack that handles DHCP, DNS forwarding, NAT, and connection tracking without relying on the host’s pf or utun devices. Guest flows are spliced onto real host sockets through batched I/O. The team documents a single-stream throughput of 22.7 Gbps on their custom backend, roughly double Apple’s VirtIO-net in the same test, though multi-flow saturation currently tops out around 10–12 Gbps combined. They also target cold boots in under 1.5 seconds and an idle memory footprint below 150 MB, numbers chosen to meet or beat OrbStack’s established benchmarks. File sharing is handled through VirtioFS and FUSE, while container data is exported over NFSv4 through a vsock relay, making guest volumes browsable in the host Finder without file-copy gymnastics. Even x86 container images are supported on Apple Silicon through integration with the open-source FEX emulator, translated inside the guest. A privileged helper handles the few operations that require root, authenticating peers by code signature so the daemon itself can run unprivileged.

What distinguishes ArcBox from other Docker alternatives, however, is not merely performance or open-source licensing. It is the fourth tier in its workload taxonomy: sandboxes. These are disposable microVMs, booted by Firecracker nested inside the guest, designed specifically for AI agents and untrusted code. The runtime exposes this through a dedicated integration that launches Claude Code inside an isolated environment with permission prompts disabled—not because security is being ignored, but because the microVM itself is intended to serve as the isolation boundary. Nothing from the host is mounted inside; the agent starts with an empty workspace and clones what it needs. When the session ends, the entire machine is discarded. Snapshots allow near-instant restoration of a booted, idle sandbox, and a gRPC API with server reflection exposes lifecycle operations to external SDKs and automation.

This design directly engages a debate currently animating the AI infrastructure community. Containers share the host kernel, and recent vulnerabilities involving container runtimes, NVIDIA toolkit initialization hooks, and eBPF verifier bypasses have demonstrated how thin that boundary can be when an automated agent is generating or executing arbitrary code. The risk is not merely theoretical; security researchers have documented prompt-injection attacks that trick agents into reading SSH keys or exfiltrating credentials. In the face of these threats, the confused deputy problem becomes central: an LLM acting inside a trusted process inherits all ambient permissions of that process, so a malicious request simply asks the agent to use authority it already possesses. MicroVMs offer a separate kernel and hardware-enforced memory isolation, raising the exploitation bar from a kernel bug to a hypervisor escape. ArcBox’s local-first approach contrasts with cloud-native sandbox providers like E2B, which offer similar Firecracker-based isolation as a managed service. By embedding the same primitive into a desktop runtime that developers already use for daily container work, ArcBox attempts to turn the sandbox from a specialized cloud API into a local development habit.

The runtime’s broader workload model reveals a platform strategy that extends beyond the laptop. Containers are handled by proxying to a guest Docker engine through a Docker-compatible socket, so existing Compose files and build pipelines transfer over with minimal friction. Native Kubernetes support is handled by running a local k3s cluster managed by the daemon, with kubeconfig integration that avoids manual context switching. Linux machines offer persistent VMs with their own kernels and disks. macOS guests use copy-on-write clones of base images on APFS, booting in seconds under Apple’s two-guest-per-host licensing cap. The sandbox tier is the same primitive that ArcBox Platform, a cloud fleet service still in development, would run remotely—implying that code tested against a local sandbox could scale to a managed CI runner without changing the underlying abstraction. The platform vision even includes enrolling existing Mac and Linux hardware as on-demand runners, using fresh ephemeral macOS guests per job.

There are material constraints that keep the project grounded in reality. ArcBox is in public beta, macOS-only, and currently optimized for Apple Silicon; Intel support is described as in progress. The sandbox feature demands an M3 or newer processor and macOS 15 or later, because it relies on nested virtualization through Apple’s VZ backend. macOS guests are further constrained by Apple’s license to two per host. The cloud platform and sandbox SDKs remain future tense, and the project’s issue tracker is presumably where the gap between ambition and implementation is currently being negotiated. Migration tooling from Docker Desktop and OrbStack exists, but users should expect the rough edges typical of a public beta.

The desktop client, a separate SwiftUI application, reinforces the product narrative by making the runtime inspectable. It streams logs, monitors live resource usage per container, and provides a file browser for volume contents. This is not merely a GUI wrapper; it is a visibility layer into a system that otherwise operates largely below the user’s awareness. In a runtime that manages four different isolation tiers, observability becomes a feature in its own right.

Still, the technical premise is coherent and unusually comprehensive. ArcBox is not glue code assembling existing open-source components. It is a ground-up reimplementation of a virtualized runtime for a specific platform, betting that developers want both the convenience of a Docker drop-in and the safety of hardware-isolated agent sandboxes without paying a closed-source tax. Whether the team can hit its performance targets, broaden hardware support, and deliver its cloud platform before the AI sandbox market consolidates around incumbent providers is the open question. For now, it offers one of the more ambitious attempts to reimagine what a macOS runtime can be, not by adding another layer on top of existing tools, but by replacing the foundation entirely.