Linux (KVM) · macOS (Apple Silicon)
Run AI AgentsWithout Trusting Them
Each run gets its own disposable microVM with explicit capabilities. No shared kernel. No ambient access to the host.
Wrap existing CLI agents or run remote agents on the same isolated runtime.
curl -fsSL
https://raw.githubusercontent.com/the-void-ia/void-box/main/scripts/install.sh
| sh hn_researcher live run
hackernews_agent.yaml
# hackernews_agent.yaml
api_version: v1
kind: agent
name: hn_researcher
sandbox:
mode: auto
memory_mb: 1024
network: true
llm:
provider: ollama
model: qwen3-coder
agent:
prompt: "Analyze top HN stories for AI engineering trends"
skills:
- "file:skills/hackernews-api.md"
- "agent:claude-code"
timeout_secs: 600 $
voidbox run --file hackernews_agent.yaml rust
use void_box::agent_box::VoidBox;
use void_box::skill::Skill;
use void_box::llm::LlmProvider;
// Skills = declared capabilities
let hn_api = Skill::file("skills/hackernews-api.md")
.description("HN API via curl + jq");
let reasoning = Skill::agent("claude-code")
.description("Autonomous reasoning and code execution");
// VoidBox = Agent(Skills) + Isolation
let researcher = VoidBox::new("hn_researcher")
.skill(hn_api)
.skill(reasoning)
.llm(LlmProvider::ollama("qwen3-coder"))
.memory_mb(1024)
.network(true)
.prompt("Analyze top HN stories for AI engineering trends")
.build()?;Apache 2.0 · Open source · Run locally or remotely · OCI-compatible rootfs · Vendor-neutral by design
The problem is not generation. It is control.
Once an agent can execute code, call tools, and reach internal systems, the question is no longer whether it helps. It is what still contains it when it is wrong.
Agents act with real authority
They open shells, modify files, call APIs, and follow instructions from data they ingest. Treating that as trusted behavior is a category error.
Shared environments erase the boundary
Long-lived sandboxes, container-first setups, and implicit permissions make it harder to reason about what the agent can actually reach.
Prompt discipline is not isolation
Instructions can be redirected. Permissions need to be enforced by the runtime, not inferred from good intentions.
Containment has to survive failure
When a run goes off course, the result should be a contained incident with visible evidence, not ambient access to the host.
Where containers fail
Real attacks against container-based agents. How they work, and how each runtime holds up.
| Attack | How the attack works | Docker | Void-Box |
|---|---|---|---|
| Prompt injection | Agent follows attacker-injected instructions from untrusted input. | Secrets leaked | No ambient host secrets |
| Docker socket escape | Mounted Docker socket (/var/run/docker.sock) gives
full host access. | Full host control | No socket exists |
| Privileged container | --privileged container mounts host disk and devices. | Host filesystem access | No host devices by default |
| Cgroup escape | cgroups v1 release_agent executes a binary on the host. | Root execution on host | Guest kernel only |
| Metadata SSRF | Default networking reaches the cloud metadata service at
169.254.169.254. | IAM credentials stolen | Metadata unreachable |
Docker can be hardened against most of these. Void-Box makes isolation the default — and the shared kernel still stands.
The runtime is the control point
An agent can decide what to do. Void-Box decides what it can touch, where it runs, and what you can inspect afterward.
- Capabilities are declared before execution.
- Each run enters its own microVM boundary.
- Logs, traces, and outputs remain observable.
Untrusted input Agent request
Code, tools, and prompts enter the runtime as untrusted execution.
Void-Box runtime boundary
Capabilities, isolation, observability
Capability gate Commands, files, network, and resource limits are explicit.
Reproducible rootfs OCI image, overlays, and snapshot/restore define the guest.
Host-guest telemetry Structured logs, traces, and metrics leave the run observable.
Mounted skills Allowed tools Controlled egress
Execution run Dedicated microVM
No shared kernel Guest kernel Hardware-isolated boundary for the run.
Agent process Runs with explicit mounted tools and declared capabilities.
Observable output Traces, logs, metrics
Controlled output Inspectable result
The run completes with contained blast radius and observable evidence.
What a run looks like
Real agent execution inside a microVM boundary.
- Runs inside an isolated VM. The agent starts in a disposable guest, not on the host or a shared sandbox.
- Only declared tools are available. Commands, files, and network access must be explicit before the run starts.
- Output stays contained. The VM exits with logs and artifacts preserved; nothing else is left behind.
claude-in-void-box
Claude Code running inside a Void-Box microVM with declared tools and an interactive shell.
Not a black box
Traces, metrics, and logs leave the run inspectable after the VM exits.
- Traces tied to the run, not a shared sandbox.
- Artifacts preserved: outputs, logs, structured events.
- Boundary events from host-guest activity, not guessed after the fact.
- otlp.traces
- Per-stage spans with run and stage correlation
- otlp.metrics
- Tokens, cost, duration, per-stage
- events
- box.started, box.completed, stage.error
- procfs
- CPU and memory telemetry via vsock
Operator layer
Void-Control, once a single run is contained
Containment is per run. Real work is many runs. Void-Control is the operator layer for spawning Void-Box runs, coordinating them across stages, and inspecting what each one touched.
Spawn and coordinate runs Launch agents and follow execution across single runs or
multi-stage pipelines.
Terminal-first operator UI Drive runs from the terminal, then drill into any stage without
leaving context.
Execution-graph visibility See stage relationships and execution paths across the whole run.
Multi-stage pipeline run with execution-graph inspection.
Run agents without trusting them
Start the runtime locally, or read the source to see how the boundary is enforced.