AI agent sandboxing has moved to the top of infrastructure priorities as a new generation of autonomous agents moves beyond generating text to executing arbitrary code on host systems. This article walks through two sandboxing approaches for AI agent workloads: OpenSandbox, a purpose-built isolation tool, and Docker, the industry-standard container runtime repurposed for agent sandboxing.

Table of Contents

• The Rise of Code-Executing AI Agents
• What This Guide Covers
• Core Concepts: How Agent Sandboxing Works
• Setting Up Docker as an Agent Sandbox
• Setting Up OpenSandbox for Agent Isolation
• Head-to-Head Comparison: OpenSandbox vs. Docker
• Integrating Sandboxing into an Agent Workflow (React + Node.js)
• Implementation Checklist: Securing Your Agent Sandbox
• The Future of Agent Sandboxing

The Rise of Code-Executing AI Agents

AI agent sandboxing has moved to the top of infrastructure priorities as a new generation of autonomous agents moves beyond generating text to executing arbitrary code on host systems. Microsoft's Deer-Flow, Anthropic's Claude Code, and the open-source OpenHands project all share a common capability: they run shell commands, write files, install packages, and interact with operating system primitives on behalf of users. This autonomy enables multi-step data pipelines, automated deployments, and iterative debugging loops, but it also exposes host systems to direct compromise. A single hallucinated rm -rf /, a prompt injection that exfiltrates environment variables through curl, or an uncontrolled pip install of a malicious package can take down an entire machine. Without proper isolation, giving an AI agent a shell is functionally equivalent to giving an untrusted third party root access.

Without proper isolation, giving an AI agent a shell is functionally equivalent to giving an untrusted third party root access.

The risk scenarios are concrete: prompt injection leading to host compromise, accidental destructive commands wiping data, and data exfiltration through uncontrolled network egress. These are predictable consequences of running untrusted code without containment, not theoretical risks.

What This Guide Covers

This article walks through two sandboxing approaches for AI agent workloads: OpenSandbox, a purpose-built isolation tool, and Docker, the industry-standard container runtime repurposed for agent sandboxing. It includes working Node.js examples for both approaches, compares their security surfaces side by side, provides a minimal benchmark harness, and lists steps to secure agent execution environments. The tutorial assumes familiarity with Docker basics and requires a Linux host (x86_64 or ARM64) with Docker Engine 20.10+ and the Docker daemon accessible at /var/run/docker.sock, as well as Node.js 18 or later with npm or yarn.

Core Concepts: How Agent Sandboxing Works

Threat Model for AI Agents

The attack surface for a code-executing AI agent spans several dimensions:

• Arbitrary code execution: the agent can run any command the underlying shell supports.
• Filesystem access: read/write to the host filesystem unless restricted.
• Network egress: outbound connections to exfiltrate data or download malicious payloads.
• Resource exhaustion: CPU, memory, and disk consumption through fork bombs, infinite loops, or large file writes.

Sandboxing and guardrails solve different problems. Guardrails operate at the prompt level: they filter or refuse dangerous requests before the agent generates code. Sandboxing operates at the execution level: it isolates the runtime environment so that even if dangerous code runs, the blast radius stays contained. This guide focuses exclusively on sandboxing.

Sandboxing Primitives

Both Docker and OpenSandbox rely on the same foundational Linux kernel primitives, but they package them differently. Linux namespaces isolate process trees, network stacks, mount points, and user IDs. Cgroups cap CPU, memory, and I/O usage. Seccomp profiles filter system calls, blocking access to dangerous operations like mount, ptrace, and reboot. Filesystem overlays create layered, disposable filesystems that can be discarded after each execution.

Docker exposes these primitives through its container runtime, requiring manual configuration to achieve a hardened security posture. OpenSandbox packages them into an agent-oriented abstraction with restrictive defaults, ephemeral execution contexts, and a session-aware API designed for the create-execute-destroy lifecycle of agent workloads.

Setting Up Docker as an Agent Sandbox

Architecture Overview

The Docker-based sandboxing architecture follows a linear flow: a Node.js orchestrator calls the Docker Engine API to spin up an ephemeral container, executes the agent-generated command inside it, captures stdout and stderr, and then destroys the container. Every execution gets a fresh container with no state carried over from previous runs.

Warning: Access to /var/run/docker.sock is equivalent to root on the host. Restrict which processes can access the socket. Consider using Docker's rootless mode or a socket proxy such as tecnativa/docker-socket-proxy to limit the API surface exposed to the orchestrator.

Prerequisites

Before running the Docker examples, ensure the following:

• Docker Engine 20.10+ is installed and the daemon is running
• The node:18-slim image is pre-pulled: docker pull node:18-slim (without this, first-run latency includes the image download, which takes minutes rather than milliseconds)
• Install the required npm package with a pinned version: npm install dockerode@^3.3.5
• On macOS or Windows, the Docker socket path differs from the Linux default /var/run/docker.sock; adjust accordingly or use Docker Desktop's default socket location

Implementation with Node.js

The following example uses the dockerode library to create a hardened ephemeral container, execute a command, capture output, and tear down the environment. The runInDocker function returns an object with { stdout, stderr } for a consistent interface:

const Docker = require('dockerode');
const docker = new Docker({ socketPath: '/var/run/docker.sock' });

async function getContainerLogs(container) {
  const stream = await container.logs({
    follow: false,
    stdout: true,
    stderr: true,
  });

  return new Promise((resolve, reject) => {
    const stdoutChunks = [];
    const stderrChunks = [];

    docker.modem.demuxStream(
      stream,
      { write: (c) => stdoutChunks.push(c) },
      { write: (c) => stderrChunks.push(c) }
    );

    // 'end' is unreliable on modem streams in some dockerode versions; use 'close' as well
    let resolved = false;
    const finish = () => {
      if (resolved) return;
      resolved = true;
      clearTimeout(deadline);
      resolve({
        stdout: Buffer.concat(stdoutChunks).toString('utf8'),
        stderr: Buffer.concat(stderrChunks).toString('utf8'),
      });
    };

    stream.on('end', finish);
    stream.on('close', finish);
    stream.on('error', (err) => {
      if (!resolved) {
        resolved = true;
        clearTimeout(deadline);
        reject(err);
      }
    });

    // Hard deadline to prevent permanent hang
    const deadline = setTimeout(() => {
      if (!resolved) {
        resolved = true;
        reject(new Error('Log stream did not close within deadline'));
      }
    }, 5000);
  });
}

async function runInDocker(command, timeoutMs = 10000) {
  const container = await docker.createContainer({
    Image: 'node:18-slim',
    Cmd: ['/bin/sh', '-c', command],
    HostConfig: {
      Memory: 128 * 1024 * 1024,
      NanoCpus: 500_000_000, // 0.5 CPU; 1 CPU = 1,000,000,000 NanoCPUs
      NetworkMode: 'none',
      ReadonlyRootfs: true,
      CapDrop: ['ALL'],
      Tmpfs: { '/tmp': 'rw,noexec,nosuid,size=64m' },
      SecurityOpt: ['no-new-privileges:true'],
    },
    Tty: false,
  });

  await container.start();

  let timedOut = false;
  const timeout = setTimeout(async () => {
    timedOut = true;
    try { await container.kill(); } catch (e) {
      if (e.statusCode !== 404 && e.statusCode !== 409) {
        console.error('Unexpected error killing container on timeout:', e.message);
      }
    }
  }, timeoutMs);

  try {
    await container.wait();
    clearTimeout(timeout);
    if (timedOut) throw new Error(`Container timed out after ${timeoutMs}ms`);

    const { stdout, stderr } = await getContainerLogs(container);
    return { stdout, stderr };
  } finally {
    clearTimeout(timeout); // Idempotent — safe to call twice
    try { await container.remove({ force: true }); } catch (e) {
      if (e.statusCode !== 404) {
        console.error('Unexpected error removing container:', e.message);
      }
    }
  }
}

module.exports = { runInDocker };

// Usage: runInDocker('echo "Hello from sandbox"').then(console.log);

This script drops all Linux capabilities with CapDrop: ['ALL'], sets a read-only root filesystem, limits memory to 128 MB and CPU to 0.5 cores, disables networking entirely with NetworkMode: 'none', and uses explicit container removal in a finally block to ensure cleanup. The timeout is always cleared on both the normal and timeout paths to prevent dangling timers or race conditions with container removal. The writable /tmp directory is mounted as a tmpfs with noexec and a 64 MB size limit.

Note that container.logs() with Tty: false returns a multiplexed stream with an 8-byte header per chunk. The docker.modem.demuxStream call separates stdout from stderr correctly; using raw Buffer.concat on the stream without demultiplexing will produce corrupted output containing binary header bytes. The getContainerLogs helper listens for both 'end' and 'close' events and includes a hard deadline to prevent hanging if neither event fires.

Applying Security Hardening

A custom seccomp profile provides an additional layer of defense by explicitly blocking dangerous system calls. The allowlist below includes syscalls required by Node.js 18 on Linux 5.x+ with modern glibc:

{
  "defaultAction": "SCMP_ACT_ERRNO",
  "architectures": ["SCMP_ARCH_X86_64", "SCMP_ARCH_AARCH64"],
  "syscalls": [
    {
      "names": ["read", "write", "readv", "writev", "open", "openat",
                 "close", "stat", "fstat", "lstat", "newfstatat",
                 "poll", "lseek", "mmap", "mprotect", "munmap",
                 "madvise", "brk", "ioctl", "access", "pipe",
                 "pipe2", "select", "pselect6", "dup", "dup2",
                 "dup3", "clone", "execve", "exit", "wait4",
                 "kill", "getpid", "getppid", "fcntl", "getcwd",
                 "chdir", "readlink", "readlinkat", "getdents",
                 "getdents64", "pread64", "pwrite64",
                 "futex", "set_tid_address", "set_robust_list",
                 "exit_group", "arch_prctl", "clock_gettime",
                 "clock_getres", "gettimeofday",
                 "rt_sigaction", "rt_sigprocmask", "rt_sigreturn",
                 "sigaltstack", "epoll_create1", "epoll_ctl",
                 "epoll_wait", "epoll_pwait", "eventfd2",
                 "socket", "connect", "getsockname", "getpeername",
                 "sendto", "recvfrom", "setsockopt", "getsockopt",
                 "bind", "listen", "accept4",
                 "nanosleep", "clock_nanosleep",
                 "getrandom", "getuid", "getgid", "geteuid",
                 "getegid", "gettid", "sysinfo", "prctl",
                 "mlock", "munlock", "sched_getaffinity",
                 "sched_yield", "tgkill", "close_range"],
      "action": "SCMP_ACT_ALLOW"
    }
  ]
}

This profile targets x86_64 and ARM64 (aarch64) architectures. If you are running on an ARM64 host (AWS Graviton, Apple Silicon via Docker Desktop), both architecture entries are required; an x86_64-only profile may be silently ignored or block all syscalls on ARM64, depending on kernel behavior.

Note: The allowlist above is a starting point that covers common Node.js workloads. If your sandboxed commands require additional syscalls (e.g., for specific native modules), you may need to extend it. A practical alternative is to start from Docker's default seccomp profile and subtract dangerous calls rather than building an allowlist from scratch.

To load this profile through dockerode, use a file path reference in the SecurityOpt array in the container's HostConfig. Note that __dirname is only available in CommonJS modules. If your project uses ESM ("type": "module" in package.json or .mjs files), use import.meta.url instead:

// CommonJS
const path = require('path');

SecurityOpt: [
  'no-new-privileges:true',
  `seccomp=${path.resolve(__dirname, 'seccomp-profile.json')}`,
],

// ESM alternative:
// import { fileURLToPath } from 'url';
// const __dirname = fileURLToPath(new URL('.', import.meta.url));

This allowlist approach blocks mount, ptrace, reboot, swapon, and other syscalls that have no legitimate use in an agent sandbox context.

Limitations of the Docker Approach

Docker containers incur cold-start latency of roughly 500 ms to 2 seconds depending on the base image and the host system's I/O performance, assuming the image is already pulled and cached. The low end assumes a cached image on SSD-backed storage; the high end reflects HDD or memory-constrained hosts. A cold image pull adds minutes of latency on first run. Each sandbox invocation requires the Docker daemon to be running, adding an operational dependency. Docker has no built-in concept of sessions or agent-aware resource pooling, so managing state across multi-turn agent conversations requires manual orchestration through volumes, container naming, and lifecycle management code that the team must build and maintain.

Setting Up OpenSandbox for Agent Isolation

What Is OpenSandbox?

Availability disclaimer: Verify OpenSandbox's current documentation and API surface at the official project repository before following these instructions. The endpoints, configuration options, and installation steps below reflect the project's documented interface at the time of writing. Performance claims cited in this article (including cold-start latency figures) are drawn from vendor documentation and have not been independently verified. Treat them as starting points for your own benchmarking, not as confirmed measurements.

OpenSandbox is a purpose-built isolation runtime designed for LLM agent workloads. Its design philosophy centers on ephemeral execution contexts with built-in timeout and resource quota management, optional session persistence for multi-turn conversations, and an agent-oriented SDK for Python and JavaScript/TypeScript. OpenSandbox can use container-based isolation and exposes both REST and gRPC APIs for sandbox lifecycle management.

Installation and Configuration

The following commands install and start the OpenSandbox daemon, followed by a minimal configuration file:

# Download the installer from the official OpenSandbox release page.
# Verify the SHA-256 checksum against the published hash before executing.
# Example (replace URL and checksum with values from official documentation):
# curl -fsSL https://get.opensandbox.io -o opensandbox-install.sh
# echo "<expected_sha256>  opensandbox-install.sh" | sha256sum --check
# sh ./opensandbox-install.sh

opensandbox daemon start --config ./sandbox-config.yaml

Warning: Never pipe a downloaded script directly to sh without first inspecting its contents and verifying its checksum. Always download the installer, verify its integrity, and then execute it as separate steps.

# sandbox-config.yaml
runtime: container
resources:
  memory_mb: 128
  cpu_cores: 0.5
  disk_mb: 64
  timeout_seconds: 10
security:
  syscall_allowlist: minimal
  network_policy: deny_all
  read_only_root: true
sessions:
  ephemeral: true
  max_concurrent: 20

This configuration enforces a restrictive posture by default: a minimal syscall allowlist, no network access, a read-only root filesystem, and ephemeral sessions that are destroyed after use.

Implementation with Node.js

The following example uses the OpenSandbox REST API via fetch to create a sandbox session, execute a command, retrieve output, and destroy the session. The session cleanup is wrapped in a try/finally block to prevent session leaks when execution fails. The API endpoint and port shown below should be verified against official OpenSandbox documentation:

const SANDBOX_API = process.env.SANDBOX_API_URL ?? 'http://localhost:9111/api/v1';

async function runInOpenSandbox(command, timeoutMs = 10000) {
  const signal = AbortSignal.timeout(timeoutMs + 2000); // outer deadline for all fetch calls

  const sessionRes = await fetch(`${SANDBOX_API}/sessions`, {
    method: 'POST',
    signal,
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      runtime: 'container',
      resources: { memory_mb: 128, cpu_cores: 0.5, timeout_seconds: Math.ceil(timeoutMs / 1000) },
      security: { syscall_allowlist: 'minimal', network_policy: 'deny_all' },
    }),
  });

  if (!sessionRes.ok) {
    const body = await sessionRes.text();
    throw new Error(`Session creation failed: HTTP ${sessionRes.status} — ${body}`);
  }

  const { session_id } = await sessionRes.json();
  if (!session_id) throw new Error('Session creation returned no session_id');

  try {
    const execRes = await fetch(`${SANDBOX_API}/sessions/${session_id}/exec`, {
      method: 'POST',
      signal,
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ command }),
    });

    if (!execRes.ok) {
      const body = await execRes.text();
      throw new Error(`Exec failed: HTTP ${execRes.status} — ${body}`);
    }

    const { stdout, stderr, exit_code } = await execRes.json();
    return { stdout: stdout ?? '', stderr: stderr ?? '', exit_code };
  } finally {
    // Always attempt session cleanup, regardless of exec outcome
    try {
      await fetch(`${SANDBOX_API}/sessions/${session_id}`, {
        method: 'DELETE',
        signal: AbortSignal.timeout(5000),
      });
    } catch (e) {
      console.error(`Failed to delete session ${session_id}:`, e.message);
    }
  }
}

module.exports = { runInOpenSandbox };

// Usage: runInOpenSandbox('echo "Hello from OpenSandbox"').then(console.log);

The session-based lifecycle is explicit: create, execute, destroy. Resource constraints and security policies are declared per session, and the daemon enforces hard kills when timeouts expire. The try/finally block around the exec call ensures the session is always cleaned up, even if execution or response parsing fails.

Note that both runInDocker and runInOpenSandbox now return an object with { stdout, stderr } (and exit_code for OpenSandbox). This consistent interface simplifies switching backends in the end-to-end example below.

Limitations of the OpenSandbox Approach

OpenSandbox is a younger project with a smaller community and fewer battle-tested production deployments compared to Docker. The daemon represents a single point of failure unless operators deploy it with redundancy.

OpenSandbox lacks features where Docker's ecosystem is mature:

• GPU passthrough is limited.
• Custom image registry support is less developed.
• Tooling, monitoring, and debugging utilities are sparse by comparison.

Head-to-Head Comparison: OpenSandbox vs. Docker

Security Comparison Table

Performance Benchmarks

The following benchmark measures mean and p99 latency across 100 sequential executions of echo hello, timing the full lifecycle of sandbox creation, command execution, and teardown for each approach. This sequential benchmark measures steady-state latency with a warm image cache. For production sizing, run concurrent benchmarks reflecting actual agent concurrency and measure with a cold image cache for first-run scenarios. P99 from 100 sequential samples has low statistical confidence; increase the iteration count for more reliable tail-latency measurements.

const { performance } = require('perf_hooks'); // Required in CommonJS; global in Node.js 18+ ESM

async function benchmark(label, runFn, iterations = 100) {
  const times = [];
  for (let i = 0; i < iterations; i++) {
    const start = performance.now();
    try {
      await runFn('echo hello');
    } catch (e) {
      console.error(`Iteration ${i} failed:`, e.message);
    }
    times.push(performance.now() - start);
  }
  times.sort((a, b) => a - b);
  const mean = times.reduce((s, t) => s + t, 0) / times.length;
  const p99 = times[Math.min(Math.ceil(times.length * 0.99) - 1, times.length - 1)];
  console.log(`${label}: mean=${mean.toFixed(1)}ms, p99=${p99.toFixed(1)}ms`);
}

// benchmark('Docker', runInDocker);
// benchmark('OpenSandbox', runInOpenSandbox);

We have not run these benchmarks for this article. The harness above is a framework for your own testing. Run it on your own infrastructure and compare results directly. Host CPU, disk I/O, image caching, and daemon configuration all materially affect latency, so treat no published numbers as authoritative.

When to Choose Which

Docker is the stronger choice when teams already operate Docker infrastructure, need custom image registries, require GPU passthrough for agent workloads, or depend on established ecosystem tools like Prometheus cAdvisor metrics, Kubernetes orchestration, and docker exec debugging.

For greenfield agent projects where cold-start latency matters, OpenSandbox reduces boilerplate and ships with secure defaults. If independent benchmarks on your infrastructure confirm sub-300ms sandbox creation, it suits latency-sensitive multi-turn sessions. It also works well for rapid prototyping, where the agent-oriented SDK cuts setup time compared to wiring up Docker lifecycle management manually.

Integrating Sandboxing into an Agent Workflow (React + Node.js)

Architecture for a Chat-Based Agent UI

A typical architecture places a React frontend in communication with a Node.js API server. The server receives user messages, passes them to an LLM for code generation, executes the generated code inside a sandbox (Docker or OpenSandbox), and returns the result to the UI. The sandbox layer is abstracted behind a common interface so the backend is swappable.

Prerequisites

• Set the OPENAI_API_KEY environment variable: export OPENAI_API_KEY=your-key-here. Be aware that each API call incurs cost; monitor usage in the OpenAI dashboard.
• Install dependencies: npm install express
• Configure the React dev server proxy by adding "proxy": "http://localhost:3001" to package.json, or add CORS middleware (npm install cors) to the Express server. Without this, the browser will block requests from the React dev server to the Express API.

End-to-End Example

The Express.js route handler below receives a user prompt, generates code via an LLM API, and executes it in a sandbox:

Warning: Application-layer validation is essential. The example below passes LLM-generated commands directly to the sandbox for simplicity. In production, always validate or restrict LLM output before execution — for example, by checking the generated command against a permitted command allowlist or running it through static analysis. Relying solely on sandbox containment without application-layer validation defeats defense-in-depth.

const express = require('express');
const app = express();
app.use(express.json());

// Swap this import to switch sandbox backends.
// Both runInDocker and runInOpenSandbox return { stdout, stderr }.
const { runInDocker: runInSandbox } = require('./docker-sandbox');
// const { runInOpenSandbox: runInSandbox } = require('./opensandbox');

async function generateCode(prompt) {
  const res = await fetch('https://api.openai.com/v1/chat/completions', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      Authorization: `Bearer ${process.env.OPENAI_API_KEY}`,
    },
    body: JSON.stringify({
      model: 'gpt-4o',
      messages: [
        { role: 'system', content: 'Generate a shell command for the user request. Output only the command.' },
        { role: 'user', content: prompt },
      ],
    }),
    signal: AbortSignal.timeout(30000),
  });

  if (!res.ok) {
    const body = await res.text();
    throw new Error(`OpenAI API error: HTTP ${res.status} — ${body}`);
  }

  const data = await res.json();
  const content = data?.choices?.[0]?.message?.content;
  if (typeof content !== 'string' || content.trim().length === 0) {
    throw new Error('OpenAI returned no usable content');
  }
  return content.trim();
}

app.post('/api/execute', async (req, res) => {
  const prompt = req.body?.prompt;
  if (typeof prompt !== 'string' || prompt.trim().length === 0) {
    return res.status(400).json({ error: 'prompt must be a non-empty string' });
  }
  if (prompt.length > 2000) {
    return res.status(400).json({ error: 'prompt exceeds maximum length of 2000 characters' });
  }

  try {
    const code = await generateCode(prompt.trim());

    // TODO: In production, validate `code` against an allowlist or run static analysis
    // before passing it to the sandbox. Do not rely solely on sandbox isolation.

    const result = await runInSandbox(code, 10000);

    // Both backends return { stdout, stderr }; normalize safely
    const stdout = typeof result === 'string' ? result : (result.stdout ?? '');
    const stderr = typeof result === 'string' ? null : (result.stderr ?? null);
    const exit_code = typeof result === 'object' ? (result.exit_code ?? null) : null;

    res.json({ code, output: stdout, error: stderr, exit_code });
  } catch (err) {
    console.error('Execution error:', err);
    res.status(500).json({ error: err.message });
  }
});

app.listen(3001, '127.0.0.1', () => console.log('Agent API on 127.0.0.1:3001'));

module.exports = { app, generateCode };

The runInSandbox import is the only line that changes when switching between Docker and OpenSandbox. Both backends now return { stdout, stderr }, providing a consistent interface.

The minimal React frontend sends a prompt and renders the output:

import { useState } from 'react';

export default function AgentUI() {
  const [prompt, setPrompt] = useState('');
  const [result, setResult] = useState(null);
  const [loading, setLoading] = useState(false);

  const handleSubmit = async (e) => {
    e.preventDefault();
    setLoading(true);
    try {
      const res = await fetch('/api/execute', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({ prompt: prompt.slice(0, 2000) }),
      });
      try {
        setResult(await res.json());
      } catch (parseErr) {
        setResult({ error: `Response parse error: ${parseErr.message}` });
      }
    } catch (networkErr) {
      setResult({ error: `Network error: ${networkErr.message}` });
    } finally {
      setLoading(false);
    }
  };

  return (
    <form onSubmit={handleSubmit}>
      <input
        value={prompt}
        onChange={(e) => setPrompt(e.target.value)}
        placeholder="Ask the agent..."
        maxLength={2000}
      />
      <button type="submit" disabled={loading}>{loading ? 'Running...' : 'Execute'}</button>
      {result && <pre>{result.output || result.error}</pre>}
    </form>
  );
}

Implementation Checklist: Securing Your Agent Sandbox

Use this checklist to secure any agent sandbox deployment:

• Drop all Linux capabilities; add back only what is strictly required
• Enforce a read-only root filesystem
• Apply a restrictive seccomp profile or syscall allowlist (include both x86_64 and ARM64 architectures if deploying across platforms)
• Disable network access unless explicitly needed for the task
• Set memory, CPU, and disk quotas
• Enforce execution timeouts with a hard kill after N seconds
• Use ephemeral, disposable environments and never reuse a sandbox across users or sessions
• Log all commands and outputs for audit purposes
• Use Docker rootless mode (see official Docker rootless documentation) to run the daemon without root privileges. Note: rootless mode has limitations with certain cgroup v1 configurations
• Restrict Docker socket access — consider a socket proxy such as tecnativa/docker-socket-proxy to limit the API surface
• Validate or restrict LLM-generated commands at the application layer before sandbox execution
• Regularly update base images and sandbox runtime to patch CVEs
• Test with adversarial prompts including attempted breakouts, fork bombs, and resource exhaustion attacks

The Future of Agent Sandboxing

Docker provides ecosystem maturity and operational flexibility at the cost of manual hardening and higher cold-start latency, while OpenSandbox delivers secure defaults and agent-native abstractions but lacks the battle-tested depth of Docker's tooling. As AI agents become more autonomous, if projects like OpenSandbox mature and gain community adoption, purpose-built sandboxing tools are positioned to increasingly complement or displace generic container runtimes for agent workloads. The most practical next step is to implement both approaches using the provided code, benchmark them on representative hardware, and adopt the security checklist as a baseline for any agent execution environment.