Run AI AgentsWithout Trusting Them

Hardware-isolated microVM runtime with capability boundaries and observability built in.
No shared kernel. No implicit trust.

Wrap existing CLI agents or run remote agents on the same isolated runtime.

VoidBox = Agent(Skills) + Isolation
hn_researcher live run
HN researcher agent running inside a Void-Box micro-VM

hn_researcher agent — live HN analysis with Ollama + Claude Code skills, running inside a KVM micro-VM

1 run = 1 microVM Dedicated boundary per execution
Interactive PTY shell Wrap CLI agents in an isolated terminal session
Sub-second restore Snapshot restore avoids repeating full VM boot
OTLP traces + metrics Built-in runtime observability

Security-conscious deployment

Run locally or remotely

Linux/KVM or Apple Silicon

Vendor-neutral by design

The Problem Is No Longer Generation.
It Is Control.

AI agents execute code, call tools, and access internal systems. Most teams still rely on Docker, partial sandboxing, or implicit trust. This creates risk.

Agents execute untrusted code

AI agents run shell commands, call APIs, and modify files. A prompt injection can redirect all of this to an attacker's goals.

Containers share a kernel

Docker containers share the host kernel. A mounted socket, privileged mode, or cgroup escape gives an agent full host access.

Prompt restrictions are not enough

System prompts can be overridden. The "confused deputy" problem means even well-intentioned agents can lose their safety context.

Teams need blast-radius control

When an agent goes wrong, the damage should be contained. Teams need observability and control, not just hope.

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

Policy Rootfs Telemetry
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.
Reproducible filesystem OCI rootfs with overlays and snapshot/restore support.
Observable output Traces, logs, metrics
Controlled output Inspectable result

The run completes with contained blast radius and observable evidence.

See the runtime under load

Real agent runs with visible isolation boundaries and runtime telemetry.

Primary run

Interactive shell inside a Void-Box microVM

Claude Code running in an isolated execution boundary with terminal access, mounted tools, and observable runtime state.

claude-in-void-box

Structured evidence, not black-box runs

Per-stage traces, metrics, and logs emitted through OpenTelemetry.

Void-Box metrics dashboard Void-Box distributed tracing Void-Box trace detail

How Void-Box works

Core runtime properties that make execution isolated, observable, and reproducible.

Hardware isolated

Each execution runs behind a microVM boundary instead of a shared host kernel.

Capability native

Skills, tools, network access, and commands are declared and mounted explicitly.

Observability built in

OpenTelemetry traces, metrics, logs, and host-guest messaging are emitted by design.

Reproducible rootfs

OCI images, read-only overlays, and snapshot/restore make runs inspectable and repeatable.

Vendor neutral

Bring your own model provider without coupling isolation to a single LLM stack.

Policy enforced

Resource limits, seccomp, command controls, and controlled egress apply at runtime.

Where Containers Fail

Hands-on labs covering prompt injection, container escape, cloud metadata SSRF, and mounted credential exfiltration.

# Lab What it demonstrates Docker result Void-Box result
01 Prompt Injection Agent follows attacker-injected instructions Secrets leaked Nothing to steal
02 Docker Socket Escape Mounted Docker socket gives full host access Full host control No socket exists
03 Privileged Container Escape --privileged container mounts host disk Host filesystem access No host devices
04 Cgroup Escape cgroups v1 release_agent executes on host Root code exec on host Guest kernel only
05 Cloud Metadata SSRF Default networking reaches cloud metadata service IAM credentials stolen Metadata unreachable
06 Sensitive Mount Exfil Mounted credential dirs expose host secrets Credentials readable No host mounts

Void-Control as the agent control plane

Void-Control is the operator layer for spawning agents, coordinating execution, and inspecting runtime state once the isolation boundary is in place.

Spawn and coordinate runs Launch agents and follow execution across single runs or swarms.
Operator workflow Terminal-first control plane with runtime drill-down and inspection.
Graph visibility Trace stage relationships and execution paths without losing context.
View Void-Control on GitHub
Void-Control execution graph demo

3-agent swarm execution with graph inspection and runtime drill-down.

Get Started with Void-Box

For engineers building agents that run code, call tools, or access internal systems.

Run it locally

Read the docs, try the runtime, and explore the codebase.

Evaluate for production

Evaluating Void-Box for your team? Get in touch.