Flagship Product
Vitund-Sandbox
A secure Linux sandbox runtime for AI agent execution. Container-grade isolation using raw Linux primitives — cgroups v2, namespaces, overlayfs, seccomp BPF, and a filtering network proxy — without Docker or any container runtime.
Three Ways to Use It
CLI for operations, MCP for LLM integration, Python API for programmatic control. Plus a web dashboard for visual management.
CLI — sj-sandbox-ctl
sj-sandbox-ctl health
sj-sandbox-ctl create <id> [options]
sj-sandbox-ctl exec <id> -- <cmd>
sj-sandbox-ctl stats <id>
sj-sandbox-ctl list
sj-sandbox-ctl destroy <id> [--wipe] MCP Server — sj-sandbox-mcp
{
"mcpServers": {
"vitund-sandbox": {
"command": "/opt/vitund-sandbox/bin/sj-sandbox-mcp",
"args": ["--transport", "stdio"]
}
}
} Python API
from supervisor.api import APIClient
client = APIClient()
await client.connect()
await client.create_sandbox(
"agent-007",
memory_mb=512,
allowed_domains=["api.anthropic.com"]
)
result = await client.exec(
"agent-007",
["python3", "-c", "print('Hello!')"],
timeout=30
) MCP Tools
The MCP server exposes these tools to any compatible LLM, enabling AI agents to manage their own sandbox environments:
sandbox_createsandbox_execsandbox_statssandbox_destroysandbox_listsandbox_health Layered Security Model
Five independent layers of isolation. Each reinforces the next. A compromise in one layer is contained by the others.
Network Proxy
Layer 1
Seccomp BPF
Layer 2
OverlayFS
Layer 3
Namespaces
Layer 4
cgroups v2
Layer 5
Linux Kernel
Resource Control
cgroups v2
Enforce hard limits on memory, CPU, PIDs, and I/O for every sandbox. Prevent runaway AI agents from consuming host resources. Unified cgroup hierarchy ensures clean resource accounting and fair scheduling across all active sandboxes.
# Create with resource limits
sudo sj-sandbox-ctl create my-agent \
--memory 512 \
--cpu 100 \
--pids 256
# Check live resource usage
sudo sj-sandbox-ctl stats my-agent Process Isolation
Linux Namespaces
Each sandbox gets its own view of the system — isolated PID tree, network stack, mount points, user mappings, hostname, and IPC. Agents cannot see or interact with processes outside their namespace. Full isolation without virtualization overhead.
# Namespace isolation flags
CLONE_NEWPID # Isolated process tree
CLONE_NEWNET # Private network stack
CLONE_NEWNS # Separate mount points
CLONE_NEWUSER # User ID remapping
CLONE_NEWUTS # Separate hostname
CLONE_NEWIPC # IPC isolation Filesystem Layers
OverlayFS
Copy-on-write filesystem layers give each sandbox a writable view of a shared base image. Unlike traditional containers, Vitund supports persistent upper layers — agent files survive sandbox restarts. Pre-built environments from apt packages or OCI/Docker images via overlay types.
# Overlay types — pre-built environments
# From apt packages:
sudo sj-sandbox-ctl create ml-agent \
--overlay-type python-ml
# From OCI/Docker images:
sudo sj-sandbox-ctl create node-agent \
--overlay-type oci:node:20-slim Syscall Filtering
Seccomp BPF
Allowlist-based Berkeley Packet Filter programs attached to each sandbox process. Only explicitly permitted system calls pass — everything else is killed. Blocks dangerous operations like ptrace, mount, and kernel module loading. Tuned specifically for AI agent workloads.
# Default seccomp profile (simplified)
{
"defaultAction": "SCMP_ACT_KILL",
"syscalls": [
{ "names": ["read", "write", "openat",
"close", "mmap", "brk"],
"action": "SCMP_ACT_ALLOW" }
]
} Filtered Connectivity
Network Proxy
All outbound traffic from sandboxed agents is routed through an HTTP/HTTPS filtering proxy. Define per-domain allow/blocklists, block internal networks (10.x, 172.16.x, 192.168.x, localhost), and log every connection attempt. No raw socket access — no ping, netcat, or SSH.
# Create with network rules
sudo sj-sandbox-ctl create my-agent \
--memory 512 \
--allow 'api.openai.com' \
--allow '*.anthropic.com' \
--allow 'pypi.org'
# All other domains are blocked
# Internal networks always blocked
# Full traffic logging enabled Security Model
What's blocked, what's allowed. No ambiguity.
Blocked
- ✕ Raw socket creation (no ping, netcat, SSH)
- ✕ Direct network access (all traffic through proxy)
- ✕ Internal networks (10.x, 172.16.x, 192.168.x, localhost)
- ✕ Privilege escalation (user namespace, nosuid/nodev mounts)
- ✕ Host filesystem access (isolated mount namespace)
- ✕ Dangerous syscalls (seccomp BPF allowlist)
- ✕ Fork bombs (PID limit) and memory exhaustion (hard cap)
Allowed
- ✓ HTTP/HTTPS to approved domains
- ✓ Python, shell commands, pip installs
- ✓ File I/O within the sandbox filesystem
- ✓ Subprocess creation (within PID limit)
- ✓ Persistent storage across restarts
How It Compares
Purpose-built for AI agent isolation. Lower overhead, faster startup, and built-in network filtering.
| Feature | Vitund-Sandbox | Docker | gVisor | Firecracker |
|---|---|---|---|---|
| Container runtime required | No | Yes | Yes | No |
| Daemon process | Supervisor | dockerd | runsc | jailer |
| Startup time | ~5ms | ~500ms | ~150ms | ~125ms |
| Memory overhead | ~2MB | ~50MB | ~30MB | ~20MB |
| Persistent storage | Built-in | Volumes | Volumes | External |
| Syscall filtering | Seccomp BPF | Optional | Kernel intercept | Seccomp |
| Network filtering | Built-in proxy | External | External | External |
| MCP integration | Native | No | No | No |
| Web dashboard | Built-in | External | No | No |
| Purpose-built for AI | Yes | No | No | No |
Requirements
Minimal dependencies. The installer handles everything.
System Requirements
- › Linux kernel 5.4+ with cgroups v2
- › Root access
- › Internet connectivity (for downloading base image)
What make install Handles
- ✓ System dependencies (debootstrap, iptables, iproute2, skopeo)
- ✓ Standalone Python runtime
- ✓ Base image creation
- ✓ Systemd service + seccomp profiles
- ✓ Default configuration
Need multi-node orchestration, fleet management, or commercial licensing?
Vitund-Sandbox Enterprise is coming soon.
Get in touch to learn more.