Tool Execution Sandbox 详解 - 工具执行沙箱

什么是 Tool Execution Sandbox？

生活类比

你让 Agent 帮你执行代码，Agent 返回了：rm -rf /

如果没有沙箱，你的服务器已经没了。如果有沙箱，Agent 只删除了沙箱里的虚拟文件系统，你的真实服务器毫发无损。

这就是 Tool Execution Sandbox——一个隔离的"爆炸试验场"，让 Agent 在里面随便折腾，外面的世界安然无恙。

正式定义：Tool Execution Sandbox 是一种安全隔离机制，用于限制 Agent 执行工具时的权限范围，防止恶意或意外操作影响宿主系统。它通过进程隔离、资源限制、权限控制等手段，创建一个受限的执行环境。

为什么需要沙箱？

真实案例：Agent 的"自杀式攻击"

2025年3月，某公司测试代码 Agent。Agent 收到任务"清理测试目录"，执行了 rm -rf ./tests/*。

问题：Agent 的当前目录不是 tests，而是根目录。

结果：删除了整个生产数据库。公司损失 $2.3M。

教训：没有沙箱的 Agent，就像没有刹车的跑车。

防止数据泄露

沙箱限制 Agent 只能访问特定文件，不能读取密码、密钥、用户数据。

防止系统破坏

隔离执行环境，Agent 删文件只删沙箱里的，删进程只杀沙箱里的。

防止资源滥用

限制 CPU、内存、网络，防止 Agent 挖矿、DDoS、占满带宽。

防止权限升级

沙箱内没有 root，没有 sudo，Agent 的野心止步于此。

沙箱技术实现

1. 容器沙箱（Container Sandbox）

// Docker 沙箱配置
docker run \
  --name agent-sandbox \
  --read-only \                  // 文件系统只读
  --cap-drop=ALL \               // 移除所有 Linux capabilities
  --network=none \               // 无网络访问
  --memory="256m" \              // 内存限制
  --cpus="0.5" \                 // CPU 限制
  --security-opt=no-new-privileges \
  --pids-limit=50 \              // 进程数限制
  agent-executor:latest

2. 进程沙箱（Process Sandbox）

// 使用 seccomp 限制系统调用
const seccompFilter = {
  defaultAction: 'SCMP_ACT_ERRNO',
  allowedSyscalls: [
    'read', 'write', 'exit', 'exit_group',
    'mmap', 'munmap', 'brk'
  ]
};

// 禁止的危险调用
const blockedSyscalls = [
  'execve',   // 不能执行新程序
  'fork',     // 不能创建子进程
  'socket',   // 不能创建网络连接
  'mount'     // 不能挂载文件系统
];

3. 文件系统沙箱

// 挂载隔离的文件系统
mkdir /tmp/sandbox-workspace
mount -t tmpfs -o size=100M,mode=1777 \
  tmpfs /tmp/sandbox-workspace

// Agent 只能看到这个目录
chroot /tmp/sandbox-workspace /bin/bash
// 现在 Agent 的 "/" 实际上是 /tmp/sandbox-workspace

4. WebAssembly 沙箱

// WASM 提供天然沙箱隔离
const wasmModule = await WebAssembly.compile(wasmCode);
const instance = await WebAssembly.instantiate(wasmModule, {
  // 只提供安全的 imports
  env: {
    log: console.log,
    random: Math.random
    // 没有 file IO, 没有 network, 没有 process
  }
});

// WASM 代码完全在沙箱内运行
instance.exports.execute();

沙箱层级对比

层级	隔离强度	性能损耗	适用场景
None	无隔离	0%	完全信任的内部 Agent
Process	系统调用限制	5-10%	轻度安全需求
Container	进程+网络+文件隔离	10-15%	标准安全需求
VM	完整操作系统隔离	20-30%	高安全需求
WASM	代码级隔离	5-10%	计算密集型任务

OpenClaw 沙箱实践

OpenClaw 提供多级沙箱配置，根据安全需求选择：

配置沙箱级别

// OpenClaw sandbox 配置
sandbox:
  default: container    // 默认使用容器沙箱
  
  levels:
    none:
      trusted: true
      networks: all
      
    light:
      allowedTools: ['read', 'search']
      memory: 512MB
      
    strict:
      allowedTools: ['read']
      networks: []
      timeout: 30s
      noShell: true
      
    paranoid:
      allowedTools: []
      networks: []
      memory: 64MB
      cpu: 0.1
      isolatedFilesystem: true

动态沙箱切换

// 根据任务类型选择沙箱级别
function selectSandbox(task) {
  if (task.type === 'search') {
    return 'light';    // 搜索任务轻度沙箱
  }
  if (task.type === 'exec') {
    return 'strict';   // 执行任务严格沙箱
  }
  if (task.type === 'shell') {
    return 'paranoid'; // Shell 任务 paranoid
  }
}

沙箱内执行

// OpenClaw exec 工具支持沙箱
await exec({
  command: 'python script.py',
  sandbox: 'strict',
  timeout: 30000
});

常见坑点

踩坑实录

坑1：沙箱太松，等于没沙箱

配置了沙箱但允许所有网络、挂载宿主目录...Agent 依然能搞破坏。沙箱必须"够紧"。

坑2：沙箱太紧，Agent 无法工作

禁止所有网络、禁止写入...Agent 要下载依赖、保存结果怎么办？要在安全和可用之间找平衡。

坑3：忘记沙箱逃逸检查

有些沙箱有已知逃逸漏洞（如 Docker 的某些 CVE）。定期更新，定期审计。

坑4：沙箱外有漏洞入口

沙箱隔离了执行，但 prompt 本身可能被注入恶意指令。沙箱只是防线之一，不是全部。

最佳实践

最小权限原则：只给 Agent 完成任务所需的最小权限
默认拒绝：默认禁止一切，按需放开
分级沙箱：不同任务用不同级别，平衡安全与性能
审计日志：记录沙箱内所有操作，事后追溯
定期更新：容器镜像、沙箱组件定期更新，修复 CVE
逃逸测试：定期用已知攻击测试沙箱强度
双重验证：沙箱内执行 + 结果验证，双重保障

Tool Execution Sandbox