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.
# 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 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()?; hn_researcher agent — live HN analysis with Ollama + Claude Code skills, running inside a KVM micro-VM
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.
Code, tools, and prompts enter the runtime as untrusted execution.
Capabilities, isolation, observability
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.
Interactive shell inside a Void-Box microVM
Claude Code running in an isolated execution boundary with terminal access, mounted tools, and observable runtime state.
Structured evidence, not black-box runs
Per-stage traces, metrics, and logs emitted through OpenTelemetry.
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.
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.