Technical Deep Dive

Vitund-Sandbox

Isolated Linux environments where AI agents can write code, call APIs, and install packages — with full network controls, credential protection, and resource guardrails. Available as a managed service or self-hosted on your infrastructure.

Three Ways to Use It

Create sandboxes from the command line, let your LLM manage them via MCP, or build programmatic workflows with the Python API. A web dashboard rounds it out for visual management.

CLI — vtd-sandbox-ctl

cli-reference 
vtd-sandbox-ctl health
vtd-sandbox-ctl create <id> [options]
vtd-sandbox-ctl exec <id> -- <cmd>
vtd-sandbox-ctl stats <id>
vtd-sandbox-ctl list
vtd-sandbox-ctl destroy <id> [--wipe]

MCP Server — vtd-sandbox-mcp

claude_desktop_config.json 
{
  "mcpServers": {
    "vitund-sandbox": {
      "command": "/opt/vitund-sandbox/bin/vtd-sandbox-mcp",
      "args": ["--transport", "stdio"]
    }
  }
}

Python API

example.py 
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
)

28 MCP Tools

Sandbox lifecycle, file I/O, process management, overlays, agents, git repos, and system administration — exposed over streamable HTTP for remote access. Any MCP-compatible client can manage sandboxes over the network.

sandbox_createsandbox_execsandbox_destroysandbox_statssandbox_listfile_readfile_writefile_listprocess_runoverlay_createoverlay_listagent_createagent_listgit_clonegit_statussecret_setsecret_mapsystem_healthsandbox_healthsandbox_logsfile_uploadfile_downloadoverlay_deleteagent_deletegit_pullsecret_listsystem_statssandbox_config

How It Keeps Agents Contained

Six independent security layers between the agent and your host. Even if an agent finds a way past one, the others still hold.

Network Proxy

Domain filtering + DNS

Secret Injection

Proxy-layer credentials

Syscall Filtering

Seccomp BPF allowlist

Filesystem Isolation

Overlayfs + nosuid

Process Isolation

6 Linux namespaces

Resource Limits

cgroups v2

Linux Kernel (5.4+)

Agents Can't Crash Your Host

Resource Controls

An agent enters an infinite loop, spawns hundreds of processes, or tries to allocate all available memory. Without limits, your host goes down. With Vitund, each sandbox has hard ceilings on memory, CPU, and process count. Fork bombs are killed instantly. Memory hogs trigger the OOM killer. Your host stays healthy.

terminal 
# Create with resource limits
sudo vtd-sandbox-ctl create my-agent \
  --memory 512 \
  --cpu 100 \
  --pids 256

# Check live resource usage
sudo vtd-sandbox-ctl stats my-agent

Agents Can't See Each Other — or Your Host

Process Isolation

Each agent gets its own isolated Linux environment. It has its own process tree, its own filesystem, its own network stack, its own user identity. It can't see other sandboxes, can't access host files, and can't interact with anything outside its boundary. To the agent, it's alone on the machine.

terminal 
# Each sandbox is fully isolated:
#   ✓ Separate process tree
#   ✓ Private network stack
#   ✓ Independent filesystem
#   ✓ Isolated user context
#   ✓ Own hostname and IPC

sudo vtd-sandbox-ctl create secure-agent \
  --memory 512

Agents Pick Up Where They Left Off

Persistent Environments

Your agent installs packages, downloads data, writes output files. With Vitund, all of that survives sandbox restarts. Each sandbox has its own writable filesystem layered on a shared base image. Need a fresh start? Wipe on demand. Pre-built environments for Python, Node.js, and more are ready to go.

terminal 
# Pre-built environments
# From apt packages:
sudo vtd-sandbox-ctl create ml-agent \
  --overlay-type python-ml

# From OCI/Docker images:
sudo vtd-sandbox-ctl create node-agent \
  --overlay-type oci:node:20-slim

Agents Can Only Do Safe Things

Security Policies

What if an agent tries to debug another process, mount a filesystem, or load a kernel module? It can't. A strict allowlist at the OS level controls exactly which operations are permitted. Everything else is silently blocked. The allowlist is tuned for what agents actually need — file I/O, networking, running scripts — and nothing more.

security-policy 
# Default policy: deny everything,
# then allow only what agents need.
#
# Blocked by default:
#   ✗ Debugging other processes
#   ✗ Mounting filesystems
#   ✗ Loading kernel modules
#   ✗ Privilege escalation
#
# Allowed:
#   ✓ File I/O, networking, memory
#   ✓ Standard agent operations

Agents Only Reach Approved Domains

Network Filtering

Your agent needs to call the Anthropic API and download packages from PyPI. It shouldn't be able to reach your database, your admin panel, or exfiltrate data via DNS. Every request passes through a per-sandbox proxy — only approved domains are reachable, internal networks are blocked, DNS queries are filtered, and every connection is logged.

terminal 
# Create with network rules
sudo vtd-sandbox-ctl create my-agent \
  --memory 512 \
  --allow 'api.anthropic.com' \
  --allow '*.anthropic.com' \
  --allow 'pypi.org'

# All other domains are blocked
# Internal networks (RFC 1918) blocked
# DNS queries filtered by same rules
# Per-request audit logging enabled

Agents Call APIs Without Seeing Your Keys

Credential Security

Your agent needs to call the Anthropic API. Normally you'd pass an API key as an environment variable — and the agent could read it, log it, or send it somewhere. With Vitund, credentials are stored encrypted on the host and injected into outbound HTTPS requests by the proxy. The agent makes the API call, the proxy adds the key. The agent never sees it.

terminal 
# 1. Store secret on the host
vtd-sandbox-ctl secret set anthropic-key \
  --value "sk-ant-..."

# 2. Map secret to a domain
vtd-sandbox-ctl secret map anthropic-key \
  --domain "api.anthropic.com" \
  --header "Authorization: Bearer"

# 3. Agent code has NO credentials
#    Proxy injects them automatically
#    Agent cannot read or exfiltrate keys

Security Model

What's blocked, what's allowed. No ambiguity.

Blocked

  • ✕ Raw socket creation (seccomp BPF)
  • ✕ Direct network access — all traffic routed through proxy
  • ✕ Access to RFC 1918 internal networks and localhost
  • ✕ ptrace, mount, reboot, and other dangerous syscalls
  • ✕ Host filesystem access (mount namespace + overlayfs)
  • ✕ Privilege escalation — no host UID 0 capabilities
  • ✕ DNS exfiltration — filtering DNS forwarder enforces domain rules
  • ✕ Runaway processes (PID limits) and memory exhaustion (OOM killer)

Allowed

  • ✓ HTTP/HTTPS to approved domains (proxy-mediated)
  • ✓ Python, shell commands, pip installs
  • ✓ File I/O within the sandbox filesystem
  • ✓ Subprocess creation (within configured PID limits)
  • ✓ Persistent storage across restarts (overlayfs)
  • ✓ API calls with proxy-injected credentials
  • ✓ Git operations with per-agent credentials

Requirements

Minimal dependencies. The installer handles everything.

System Requirements

  • › Linux kernel 5.4+ with cgroups v2
  • › x86_64 (Intel/AMD) or ARM64 (Raspberry Pi 4/5, Graviton)
  • › Ubuntu 22.04+, Debian 12+, RHEL 9+
  • › WSL2 (Windows 11) or Lima/OrbStack VM (macOS)
  • › Root access for namespace setup

What make install Handles

  • ✓ All system dependencies
  • ✓ Standalone Python runtime
  • ✓ Base image creation
  • ✓ Background service and security profiles
  • ✓ Default configuration

Need multi-node orchestration, fleet management, or custom deployment?
to discuss your requirements.

Stay in the loop

Get product updates, security deep-dives, and early access — no spam, unsubscribe anytime.