sandbox-runtime

开场：Agent 沙箱不是"装个 Docker 就完事"

2025 年下半年开始，AI Agent 的安全问题从理论变成了日常。只要 Agent 能执行 shell 命令，一次提示注入就可能让它把 ~/.ssh/id_rsa 上传到任意服务器。企业界的标准答案一开始是"每个 Agent 跑一个容器"——但容器太重：一个 Python 脚本也要拉 200MB 镜像，跨平台、跨文件系统路径、跨进程通信全都要重新适配。

Anthropic 在 2025 年 10 月给出了另一条路：用操作系统原语直接做沙箱，不需要容器。这个项目就是 @anthropic-ai/sandbox-runtime（命令名 srt），如今 6,822 颗星、38 位贡献者。

背景：它其实是 Claude Code 的一个零件被开源了

srt 的 README 第一句就写着 "A lightweight sandboxing tool for enforcing filesystem and network restrictions on arbitrary processes at the OS level, without requiring a container"，并且明确标注这是 Beta Research Preview——它是 Claude Code 沙箱功能背后那层 OS 隔离实现，被单独抽出来开源，让生态里的其他 Agent 框架（MCP Server、本地 Coding Agent）也能用上同一套边界。

架构上有三条清晰的原则：

1. 文件系统与网络隔离必须成对存在。 没有网络隔离，被攻陷的 Agent 可以外泄 SSH 密钥；没有文件系统隔离，它可以改系统文件再拿网络权限。官方在 Anthropic 工程博客里明确说"effective sandboxing requires both"。

2. 整个进程树都受约束。 限制不是只作用于 Agent 自身的直接调用，而是覆盖它 spawn 出的所有脚本和子进程——这正是提示注入最常利用的逃逸路径。

3. 默认拒绝，逐项放开。 写权限默认全禁，读取默认全开但可 denyRead 大范围再 allowRead 精确重开；网络默认全禁，必须显式列出 allowedDomains。

核心功能：三个平台的原生实现

macOS —— sandbox-exec 动态生成 Seatbelt profile。Seatbelt 能在内核层做域名级白名单，这是三平台中隔离强度最高的；还能接入系统沙箱违规日志做实时告警。

Linux —— bubblewrap 容器化 + network namespace 隔离。进程的网络 namespace 被整个移除，所有流量必须经 Unix domain socket 走宿主代理。代价是网络限制只发生在宿主代理层，不是内核边界——官方在源码注释里明确标注了这个 limitation。另外需要 socat 做 socket 中继、ripgrep 用于 deny 路径检测。

Windows（alpha） —— 以专用 srt-sandbox 本地账户运行，配合 Windows Filtering Platform 出站过滤网栏按账户 SID 生效，写权限用受限令牌加工作树显式 ACE 控制。

代理层本身也是重头戏。 src/sandbox/ 下有 http-proxy、mux-proxy、parent-proxy、mitm-ca、mitm-leaf（中间人 CA/叶子证书）、aws-sigv4（识别并拦截 AWS 签名请求）、credential-extract / credential-mask-env / credential-mask-files / credential-sentinel（多路凭据遮蔽）。这说明设计者很清楚：真正的威胁不是恶意进程，而是"意外地合法地把凭据发出去"。

还有 generate-seccomp-filter.ts——动态生成 seccomp 过滤器来阻断 Unix socket 访问，这是可选的加固层。

上手门槛

npm install -g @anthropic-ai/sandbox-runtime
srt "curl anthropic.com"        # 允许的域名：成功
srt "curl example.com"          # 不在白名单：Connection blocked by network allowlist
srt "cat README.md"             # 工作目录内：允许
srt "cat ~/.ssh/id_rsa"         # 敏感路径：Operation not permitted

要求 Node.js >= 22.12.0，源码构建用 Bun。

Linux 需要三个系统依赖，且有个容易踩的坑：

Ubuntu 24.04+ 默认启用 kernel.apparmor_restrict_unprivileged_userns，允许 unshare(CLONE_NEWUSER) 但会剥离命名空间能力。而 bubblewrap 和 seccomp 隔离层都需要带能力的 user namespace。必须手动执行 sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0，或添加授予 userns 的 AppArmor profile。

官方对此的处理方式是警告而非拒绝——这是个值得注意的产品决策：它把安全判断的责任留给了使用者。

争议与局限

• Windows 仍是 alpha，且官方自陈了两处盲区：过滤器不跟踪"换 token 再建 socket"的线程，也无法拦截由系统服务代发的流量。
• Linux 网络隔离层级较低：域名白名单在宿主代理层生效而非内核边界。这意味着"绕过代理直接建立连接"的路径需要额外防护，设计上的复杂度正体现在那 25+ 个 sandbox 模块里。
• 研究预览定位：README 明确说 API 与配置格式会演进。目前配置是 JSON schema 校验（zod），但格式不稳定意味着生产集成要预留适配层。
• bubblewrap 版本约束：0.4.0 起支持，但涉及非普通文件（fifo/socket/设备节点）的 bind 时需要 0.5.0+，否则会在只读挂载上失败并阻塞在 fifo 上。
• 代理本身是单点：所有流量过宿主代理，代理的鉴权与转发逻辑一旦有洞，隔离就失效。这是集中式架构的固有代价。
• 约 3,600 人贡献（GitHub 贡献者端点为 38 人，仓库为 Anthropic 组织内部开发为主）：这更像官方参考实现而非社区项目，路线由 Anthropic 主导。

行业意义

srt 代表 AI Agent 安全的一条轻量路线：不是"每个 Agent 一个容器"，而是"OS 级边界 + 显式权限声明"。对本地运行 Coding Agent、需要让 Agent 访问文件系统但限制网络出口的场景，这条路比容器更自然、更快、更少资源开销。

更大的意义在于它把"沙箱能力"从大厂特权变成了可安装的依赖。此前只有 Claude Code 内置了 OS 级沙箱；现在任何 Agent 框架都能 npm install 一份同样的实现。它也侧面验证了 Anthropic 的判断：Agent 安全的下一个战场不是模型对齐，而是模型之外的系统边界。

适合谁

适合：构建本地 Coding Agent / MCP Server / 任意需要执行子进程的 AI 应用；希望在多租户或企业环境里给 Agent 加权限边界的安全团队；研究 Agent 沙箱机制的工程师。

不适合：需要强隔离保证的多租户 SaaS 场景（Windows 侧尚未成熟、Linux 网络隔离非内核级）；只做云端 API 调用、无本地执行的需求。

一句话结论：目前最实用、最贴近生产的一个 Agent 沙箱参考实现——但它是研究预览，Windows 未成熟，Linux 的网络隔离不在内核层，适合作为起点而非终点。