How to Set Up Agent Sandboxing on Vultr Cloud Compute

Agent sandboxing runs code an AI agent generates inside an isolated environment, so a bug, a prompt-injection attack, or malicious output cannot reach the host. Microsandbox is an open-source platform built for this, launching each sandbox as its own microVM on libkrun over the Kernel-based Virtual Machine (KVM), with a separate kernel from the host rather than the shared-kernel isolation a container provides.

This guide explains how to set up agent sandboxing on a Vultr VX1™ Cloud Compute instance using Microsandbox. It covers installing the msb CLI, running sandboxes with resource limits and network isolation, using the Python SDK, and connecting a coding agent through Microsandbox's Model Context Protocol (MCP) server so the agent creates and uses its own sandboxes on demand.

Prerequisites

Before you begin, you need to:

• Have access to a Vultr VX1™ Cloud Compute instance running Ubuntu 24.04 as a non-root user with sudo privileges.
• Have OpenCode or another AI coding agent installed.
• Have a Vultr Serverless Inference API key, required if using OpenCode as the coding agent.

Verify Host Virtualization Support

Microsandbox relies directly on KVM, so the host needs a CPU virtualization flag and a usable /dev/kvm device before the installer runs.

1. Add the current user to the kvm group.

   CONSOLE

   Copy

   $ sudo usermod -aG kvm $USER

   Explain Code

   Powered by Vultr AgentBeta

2. Apply the new group membership to the current shell.

   CONSOLE

   Copy

   $ newgrp kvm

   Explain Code

   Powered by Vultr AgentBeta

3. Confirm the new group membership is active.

   CONSOLE

   Copy

   $ id

   Explain Code

   Powered by Vultr AgentBeta

   Verify that kvm appears in the group list.

4. Verify the KVM device is present on the host.

   CONSOLE

   Copy

   $ ls -l /dev/kvm

   Explain Code

   Powered by Vultr AgentBeta

   Verify the output reports a character device that belongs to the kvm group.

Install Microsandbox

Microsandbox ships as a single binary with a bundled libkrunfw library. A shell script installs both, rather than a package manager.

1. Run the install script.

   CONSOLE

   Copy

   $ curl -fsSL https://install.microsandbox.dev | sh

   Explain Code

   Powered by Vultr AgentBeta

   The script downloads the msb binary, verifies its checksum, and installs it along with libkrunfw to ~/.microsandbox, then links msb and microsandbox into ~/.local/bin.

   Log out and log back in over SSH for the updated PATH to take effect.

2. Verify the installed version.

   CONSOLE

   Copy

   $ msb --version

   Explain Code

   Powered by Vultr AgentBeta

3. Run the built-in host check.

   CONSOLE

   Copy

   $ msb doctor

   Explain Code

   Powered by Vultr AgentBeta

   Verify the output reports checks for CPU virtualization, the KVM device, and KVM access, similar to the one below:

      ✓ msb          /home/linuxuser/.microsandbox/bin/msb
      ✓ libkrunfw    /home/linuxuser/.microsandbox/lib/libkrunfw.so.5.6.1
      ! Root clone   copy fallback — reflink unavailable
      ✓ CPU virt     svm
      ✓ KVM device   /dev/kvm
      ✓ KVM access   read/write
   done Host setup is ready.

   Note

   The reflink warning is informational. Ubuntu's default ext4 filesystem does not support reflink clones, so Microsandbox falls back to sparse copies for each sandbox root.

Run Sandboxes

A sandbox starts from a standard Open Container Initiative (OCI) image, the same format Docker and other container runtimes use, and runs as its own microVM rather than a container. A detached sandbox keeps running in the background so an agent can send it multiple commands over time, while explicit CPU and memory limits prevent a single sandbox from exhausting the host.

1. Boot a sandbox from the debian image and run a command inside it.

   CONSOLE

   Copy

   $ msb run debian -- echo "hello from microsandbox"

   Explain Code

   Powered by Vultr AgentBeta

   Verify the output reports the echoed text, then the sandbox exits.

2. Create a named, detached sandbox with explicit CPU and memory limits.

   CONSOLE

   Copy

   $ msb create --name sandbox01 --cpus 1 --memory 256M debian

   Explain Code

   Powered by Vultr AgentBeta

3. Confirm the limits are in effect.

   CONSOLE

   Copy

   $ msb status sandbox01

   Explain Code

   Powered by Vultr AgentBeta

   Verify the output reports the configured CPU and memory allocation, similar to the one below:

   NAME         IMAGE     COMMAND    CPUS     MEM                  STATUS     PORTS
   sandbox01    debian    "bash"     1 / 1    256 MiB / 256 MiB    running    -

4. Run a command inside the detached sandbox.

   CONSOLE

   Copy

   $ msb exec sandbox01 -- hostname

   Explain Code

   Powered by Vultr AgentBeta

   The output displays the sandbox's hostname.

5. Verify the sandbox has outbound internet access by default.

   CONSOLE

   Copy

   $ msb exec sandbox01 -- bash -c "timeout 5 bash -c '</dev/tcp/example.com/80' && echo REACHABLE || echo BLOCKED"

   Explain Code

   Powered by Vultr AgentBeta

   Verify the output reports REACHABLE.

Verify Sandbox Isolation

Microsandbox denies traffic between separate microVMs by default, which is the property that matters most when several untrusted agent sandboxes run on the same host.

1. Create a second detached sandbox.

   CONSOLE

   Copy

   $ msb create --name sandbox02 --cpus 1 --memory 256M debian

   Explain Code

   Powered by Vultr AgentBeta

2. List running sandboxes to confirm both are present.

   CONSOLE

   Copy

   $ msb list

   Explain Code

   Powered by Vultr AgentBeta

   Verify the output reports both sandbox01 and sandbox02 as running.

3. Note the first sandbox's IP address.

   CONSOLE

   Copy

   $ msb exec sandbox01 -- hostname -I

   Explain Code

   Powered by Vultr AgentBeta

4. Install netcat in the first sandbox.

   CONSOLE

   Copy

   $ msb exec sandbox01 -- bash -c "DEBIAN_FRONTEND=noninteractive apt-get update -qq && DEBIAN_FRONTEND=noninteractive apt-get install -y -qq netcat-openbsd"

   Explain Code

   Powered by Vultr AgentBeta

5. Start a listener in the background.

   CONSOLE

   Copy

   $ msb exec sandbox01 -- bash -c "(setsid nohup nc -lk -p 9000 > /tmp/nc.log 2>&1 < /dev/null &); sleep 0.3; echo launched"

   Explain Code

   Powered by Vultr AgentBeta

   Verify the output reports launched.

6. Confirm the listener is reachable from inside the same sandbox.

   CONSOLE

   Copy

   $ msb exec sandbox01 -- bash -c "(echo > /dev/tcp/127.0.0.1/9000) && echo LOCAL-OK || echo LOCAL-FAIL"

   Explain Code

   Powered by Vultr AgentBeta

   Verify the output reports LOCAL-OK before continuing.

7. Install netcat in the second sandbox.

   CONSOLE

   Copy

   $ msb exec sandbox02 -- bash -c "DEBIAN_FRONTEND=noninteractive apt-get update -qq && DEBIAN_FRONTEND=noninteractive apt-get install -y -qq netcat-openbsd"

   Explain Code

   Powered by Vultr AgentBeta

8. From the second sandbox, attempt to reach the first sandbox's listener. Replace SANDBOX_IP with the first sandbox's IP address from the earlier step.

   CONSOLE

   Copy

   $ msb exec sandbox02 -- bash -c "echo probe | timeout 3 nc -w2 SANDBOX_IP 9000 && echo REACHED || echo BLOCKED"

   Explain Code

   Powered by Vultr AgentBeta

   Verify the output reports BLOCKED. Each sandbox reaches the public internet, but not its siblings, and the host needs no firewall rules to enforce this.

Create Sandboxes Using the Python SDK

The Python SDK creates a sandbox, runs code inside it, and tears it down directly from a script, instead of the msb CLI from earlier sections.

1. Install the virtual environment module for the system Python.

   CONSOLE

   Copy

   $ sudo apt install -y python3-venv

   Explain Code

   Powered by Vultr AgentBeta

2. Create a project directory.

   CONSOLE

   Copy

   $ mkdir ~/msb-python && cd ~/msb-python

   Explain Code

   Powered by Vultr AgentBeta

3. Create a virtual environment inside the project directory.

   CONSOLE

   Copy

   $ python3 -m venv .venv

   Explain Code

   Powered by Vultr AgentBeta

4. Activate the virtual environment.

   CONSOLE

   Copy

   $ source .venv/bin/activate

   Explain Code

   Powered by Vultr AgentBeta

5. Install the microsandbox package.

   CONSOLE

   Copy

   $ pip install microsandbox

   Explain Code

   Powered by Vultr AgentBeta

6. Create a file named demo.py.

   CONSOLE

   Copy

   $ nano demo.py

   Explain Code

   Powered by Vultr AgentBeta

7. Add the following code to the file:

   PYTHON

   Copy

   import asyncio
   from microsandbox import Sandbox
   
   
   async def main():
       async with await Sandbox.create(
           "py-demo",
           image="python",
           cpus=1,
           memory=512,
           replace=True,
       ) as sandbox:
           output = await sandbox.exec(
               "python", ["-c", "print('hello from a Python-driven microVM')"]
           )
           print("stdout:", output.stdout_text)
           print("exit code:", output.exit_code)
   
           identity = await sandbox.exec("bash", ["-c", "hostname && uname -a"])
           print("sandbox identity:")
           print(identity.stdout_text)
   
   
   asyncio.run(main())

   Explain Code

   Powered by Vultr AgentBeta

   Save and close the file.

   This example demonstrates the core lifecycle:

   • Sandbox.create(...): Boots a new microVM sandbox with the given name, image, and resource limits.
   • async with: Stops and removes the sandbox automatically when the block exits.
   • replace=True: Replaces an existing sandbox with the same name.
   • sandbox.exec(...): Runs a command inside the sandbox and returns its output.
   • The hostname/uname -a call: Confirms the code runs inside the sandbox rather than on the host.

8. Run the script.

   CONSOLE

   Copy

   $ python demo.py

   Explain Code

   Powered by Vultr AgentBeta

   Verify the output reports the printed text, an exit code of 0, and a sandbox identity that differs from the host's own, similar to the one below:

   stdout: hello from a Python-driven microVM
   
   exit code: 0
   sandbox identity:
   py-demo
   Linux py-demo 6.12.99 #1 SMP ... x86_64 GNU/Linux

9. Deactivate the virtual environment.

   CONSOLE

   Copy

   $ deactivate

   Explain Code

   Powered by Vultr AgentBeta

Connect a Coding Agent to Microsandbox via MCP

Microsandbox ships an MCP server that exposes the sandbox lifecycle as tools an AI coding agent can call directly, instead of a human running msb commands.

1. Add the NodeSource repository for Node.js 22.

   CONSOLE

   Copy

   $ curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -

   Explain Code

   Powered by Vultr AgentBeta

2. Install Node.js from that repository.

   CONSOLE

   Copy

   $ sudo apt install -y nodejs

   Explain Code

   Powered by Vultr AgentBeta

3. Verify the version.

   CONSOLE

   Copy

   $ node --version

   Explain Code

   Powered by Vultr AgentBeta

   Verify the output reports v22 or later. Microsandbox's MCP server requires Node.js 22 or later, and other versions may not work.

4. Use Vultr Serverless Inference as OpenCode's model provider and register the Microsandbox MCP server by adding the following to opencode.json.

   JSON

   Copy

   {
     "provider": {
       "vultr": {
         "npm": "@ai-sdk/openai-compatible",
         "options": {
           "apiKey": "VULTR_INFERENCE_API_KEY",
           "baseURL": "https://api.vultrinference.com/v1"
         },
         "models": {
           "MODEL_ID": {
             "name": "MODEL_NAME"
           }
         }
       }
     },
     "model": "vultr/MODEL_ID",
     "mcp": {
       "microsandbox": {
         "type": "local",
         "command": ["npx", "-y", "microsandbox-mcp"],
         "enabled": true
       }
     }
   }

   Explain Code

   Powered by Vultr AgentBeta

   Replace VULTR_INFERENCE_API_KEY with a Serverless Inference API key, and MODEL_ID and MODEL_NAME with a model ID and display name listed on the VSI page.

5. Open OpenCode.

   CONSOLE

   Copy

   $ opencode

   Explain Code

   Powered by Vultr AgentBeta

6. Use the following prompt to test it.

   TEXT

   Copy

   Write and run a Python script that prints the first 10 Fibonacci numbers, and test it in an isolated sandbox.

   Explain Code

   Powered by Vultr AgentBeta

   Verify the agent calls the sandbox_run tool and reports output similar to the one below:

   [0, 1, 1, 2, 3, 5, 8, 13, 21, 34]

   Note

   To confirm the code runs inside a separate microVM, ask for hostname and uname -a too. Both differ from the host's own values.

Register Other Agents to MCP Server

For any other MCP-compatible agent, refer to that agent's own MCP documentation for its config file's location and exact format.

Restart any existing session of the agent after registering the server, since most agents load MCP configuration only at startup.

Manage Running Sandboxes

The msb CLI includes commands beyond running and inspecting a sandbox, for copying files in and out, reviewing accumulated output, checking resource usage, connecting over SSH, and refreshing an idle timeout. Replace SANDBOX_NAME with the name of the sandbox to target.

• Copy a file from the host into the sandbox.

  CONSOLE

  Copy

  $ echo "hello from host" > /tmp/hostfile.txt
  $ msb copy /tmp/hostfile.txt SANDBOX_NAME:/tmp/hostfile.txt

  Explain Code

  Powered by Vultr AgentBeta

  A SANDBOX:/absolute/path argument addresses a path inside the sandbox rather than the host.

• Copy a file back out of the sandbox.

  CONSOLE

  Copy

  $ msb exec SANDBOX_NAME -- bash -c "echo generated inside sandbox > /tmp/result.txt"
  $ msb copy SANDBOX_NAME:/tmp/result.txt /tmp/result-from-sandbox.txt

  Explain Code

  Powered by Vultr AgentBeta

• Review the sandbox's logs.

  CONSOLE

  Copy

  $ msb logs SANDBOX_NAME --tail 5

  Explain Code

  Powered by Vultr AgentBeta

  msb logs accumulates output from every msb exec call against the sandbox. Add -f to follow new output, or --since 10m to limit the window.

• Check live resource usage.

  CONSOLE

  Copy

  $ msb metrics SANDBOX_NAME

  Explain Code

  Powered by Vultr AgentBeta

  Verify the output reports CPU, memory, disk, and network throughput against the limits set at creation, similar to the one below:

  NAME            STATE      CPU          MEM                     DISK R/W /s      NET RX/TX /s    UPTIME
  SANDBOX_NAME    running    0.01 / 1c    17.4 MiB / 256.0 MiB    1.7 MiB / 0 B    0 B / 0 B       48.5s

• Connect to the sandbox over SSH.

  CONSOLE

  Copy

  $ msb ssh SANDBOX_NAME -- hostname

  Explain Code

  Powered by Vultr AgentBeta

  Microsandbox exposes SSH over the same vsock channel used for exec, so the guest image needs no SSH server installed.

• Reset the idle-timeout clock on a long-running sandbox without sending it any other traffic.

  CONSOLE

  Copy

  $ msb touch SANDBOX_NAME

  Explain Code

  Powered by Vultr AgentBeta

  Useful when a sandbox is waiting on something outside Microsandbox's view, such as a slow API call, so idle-timeout does not stop it early.

• Stop a sandbox.

  CONSOLE

  Copy

  $ msb stop SANDBOX_NAME

  Explain Code

  Powered by Vultr AgentBeta

  Fix: Permission denied (os error 13)

• Remove a stopped sandbox.

  CONSOLE

  Copy

  $ msb remove SANDBOX_NAME

  Explain Code

  Powered by Vultr AgentBeta

Conclusion

You have installed Microsandbox on a Vultr VX1™ Cloud Compute instance and used it, from the msb CLI, the Python SDK, and an MCP-connected coding agent, to run isolated microVM sandboxes with enforced CPU and memory limits and confirmed network isolation between them. The msb CLI manages the rest of a sandbox's lifecycle, from file transfer to logs, metrics, and SSH access. For image building and snapshotting, visit the official Microsandbox documentation.