Void-Box logo Void-Box

Overview

VoidBox is a composable agent runtime with enforced isolation boundaries. Each agent stage runs inside its own micro-VM, bound to the capabilities it has been granted — nothing more. Isolation is provided by hardware virtualization (KVM on Linux, Virtualization.framework on macOS), not by advisory process controls.

The core mental model:

VoidBox = Agent(Skills) + Isolation

Skills are declared capabilities (files, MCP servers, CLI tools, OCI images). A capability only exists when bound to an isolated execution boundary — if the skill was not declared for this stage, it is simply not present in the guest.

Why not containers?

Containers share the host kernel. For general workloads that is usually fine, but AI agents execute tools, generated code, and external integrations, which turns every stage into a shared failure domain with its neighbours. VoidBox binds each stage to its own micro-VM with a separate kernel and memory space, so a compromise or crash in one stage cannot reach the host or another stage through the kernel.

See Architecture for the full execution model and Security Model for the defense-in-depth layers.

What you get

  • Isolated execution — Each stage runs in its own micro-VM boundary, not a shared-process container.
  • Policy-enforced runtime — Command allowlist, resource limits, session-authenticated vsock control channel, and CIDR-level network deny list.
  • Skill-native model — File, remote, MCP, CLI, and OCI skills mounted as declared capabilities.
  • Composable pipelines — Sequential .pipe() and parallel .fan_out(), each stage a fresh VM.
  • Vendor-neutral providers — Claude, Claude Personal (OAuth), Codex, Ollama, LM Studio, or any Anthropic-compatible endpoint. The llm.provider field selects the agent binary and auth; VoidBox handles the isolation, not the model choice.
  • OCI-native — Auto-pull guest images from GHCR, mount OCI images as the guest root filesystem or as read-only skill providers.
  • Sub-second VM restore — Snapshot/restore on both backends (base + diff on Linux/KVM; Apple’s native save/restore on macOS/VZ).
  • Observability by design — Structured run events, OTLP traces and metrics, guest-side CPU/memory telemetry.
  • Host mounts — Share host directories into the guest over 9p (Linux/KVM) or virtiofs (macOS/VZ).
  • No root required on Linux — Usermode SLIRP networking via smoltcp; no TAP devices, no bridges.

Platforms

  • Linux/KVM — any host with /dev/kvm (cloud instances, bare metal, most dev boxes).
  • macOS/VZ — Apple Silicon (M1 or later) via Virtualization.framework, native. No Docker or nested Linux VM required.

Feature parity is close but not identical — platform-specific caveats are called out inline in Architecture, Security Model, Snapshots, and Host Mounts.

Status

v0.1. Vendor-neutral agent runtime with hardware-isolated execution; APIs stabilizing.

Where to next

  • Installation — Homebrew, shell installer, .deb / .rpm, or cargo install void-box.
  • Getting Started — Define your first agent (Rust or YAML) and run it end-to-end.
  • Architecture — Host/guest execution model, wire protocol, and platform boundaries.