剥离容器黑盒：拆解 Anthropic 进程级原生沙箱 runtime 架构

1. 痛点突围：它究竟击穿了什么工程死穴？

AI Agent 正在接管终端的执行权。无论是 Claude Code 自动运行单元测试，还是通过 Model Context Protocol (MCP) 挂载的本地文件系统工具，大语言模型生成的 Bash 脚本与宿主机环境仅隔着一层终端确认提示。开发者频繁给出的确认，最终会演变成凭据泄漏、隐式覆盖关键代码库，甚至是外部 Prompt 注入触发的任意命令执行。

长久以来的防御方案依赖 Docker 容器化。但把工程链路塞进容器必须承担昂贵的代价：复杂的卷挂载配置导致宿主机环境上下文断裂；Node 与 Python 的庞大镜像使得构建和启动拉长到数秒级；开发机与宿主机网络桥接配置复杂。这种沉重的虚拟化开销阻碍了轻量级 Agent 任务的高频调用。

Anthropic 团队在孵化 Claude Code 过程中开源的 sandbox-runtime (srt) 转换了防线构建思路。它直接利用操作系统内置的安全原语，在普通用户空间以原生进程级别施加强制访问控制。整个方案舍弃了容器层，依然能实现针对任意进程树的强约束。

💡 架构核心洞见：通过将安全围栏从虚拟化容器下沉至 OS 内核原语（Seatbelt / bubblewrap / WFP），srt 以零启动延迟和原生环境继承能力，实现了进程级的文件与网络双向防御闭环。

2. 核心架构与底层数据流向解析

srt 的底层核心是“双重隔离模型”（Dual Isolation Model）。代码审计或 Agent 执行不仅需要约束文件系统读写，更要切断未授权的网络通道，防止凭证在读取后被回传至未知服务器。整个执行生命周期遵循“默认拒绝网络、写操作严格白名单、读操作细粒度黑名单覆盖”的原则。

跨平台运行时根据底层 OS 特性分发隔离策略： - macOS：动态编译 Scheme 格式的 Apple Seatbelt 规则（通过私有 sandbox-exec 接口下发），对沙箱进程施加硬性文件系统与网络拦截。 - Linux：依托 bubblewrap 剥离沙箱进程的 network namespace，直接消除网卡可见性，同时按需挂载只读系统目录与白名单工作区。 - Windows：切换至受限本地账户 srt-sandbox，利用 Windows Filtering Platform (WFP) 绑死安全标识符 (SID) 的出站流量，搭配受限访问令牌 (Restricted Token) 固化只读权限。

+-------------------------------------------------------------+
|                      Host Environment                       |
|                                                             |
|  +--------------------+       Domain Whitelist / Rules     |
|  |   srt Supervisor   | <--- (~/.srt-settings.json)         |
|  +---------+----------+                                     |
|            |                                                |
|       Spawns Proxy                                          |
|            v                                                |
|  +--------------------+                                     |
|  | Host Loopback Proxy|<========+                           |
|  | (HTTP / SOCKS5)    |         |                           |
|  +--------------------+         | (Filtered Traffic)        |
+------------|--------------------|---------------------------+
             | Enforces OS        | Unix Socket / Fixed Port
             | Sandbox Primitives | (Egress Firewall Bound)
+------------v--------------------|---------------------------+
| Target Sandboxed Process Tree   |                           |
| (e.g., MCP Server / Bash)       |                           |
|                                 |                           |
|  +---------------------------+  |                           |
|  | Filesystem Access Control |  |                           |
|  | - Read: Whitelist Overrides  |                           |
|  | - Write: Deny-by-Default  |  |                           |
|  +---------------------------+  |                           |
|  +---------------------------+  |                           |
|  | Network Isolation         |==+                           |
|  | - Direct Traffic: BLOCKED |                              |
|  +---------------------------+                              |
+-------------------------------------------------------------+

网络拦截链条的设计尤为精妙。沙箱进程无法直接与外网建连。在 Linux 环境下，srt 甚至移除了沙箱的网络命名空间，进程仅能通过 bind-mount 入沙箱内部的 Unix Domain Socket 与宿主机通信。在 macOS 与 Windows 上，系统规则将出站请求完全限制在固定的本地环回端口。沙箱内的 HTTP 与 SOCKS5 代理客户端拦截所有外发流量，由宿主侧的 Node.js 代理中间层完成域名解析与白名单校验，校验失败直接在传输层返回连接阻断。

3. 技术选型与性能横向硬核对比

将 sandbox-runtime 放置在现代开发环境与云原生沙箱体系中横向评估，各架构维度的取舍特征鲜明：

点评：Docker 这类容器技术最初设计目标是环境打包与云端部署，用在 Agent 本地调用场景显得体量过载且迟钝。srt 舍弃了环境打包的包袱，专注做系统调用的围栏拦截。它不是传统虚拟化工具的替代品，而是填补了本地 Agent 运行时高频启动和强安全约束之间的工程空白。

4. 手把手极客实操：从零构建最小闭环

环境安装

srt 以跨平台 CLI 和底层库的形式打包，依赖全局 npm 即可分发安装：

npm install -g @anthropic-ai/sandbox-runtime

编排受控 MCP 节点服务

以下配置展示了如何在 Claude 桌面客户端或 Claude Code 配置文件（~/.mcp.json）中接入 srt，以严格受限模式运行官方 Filesystem MCP 服务，防止 Agent 任意读取 ~/.ssh 或改写关键配置：

{
  "mcpServers": {
    "filesystem": {
      "command": "srt",
      "args": [
        "npx",
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/Users/developer/workspace"
      ]
    }
  }
}

声明沙箱边界策略

在根目录创建 ~/.srt-settings.json，配置精确的写权限与出网名单：

{
  "filesystem": {
    "denyRead": ["~/.ssh", "~/.aws", "**/.env"],
    "allowWrite": [".", "/tmp/build"],
    "denyWrite": ["~/sensitive-folder"]
  },
  "network": {
    "allowedDomains": [
      "registry.npmjs.org",
      "api.github.com"
    ],
    "deniedDomains": []
  }
}

命令行执行与断言测试

通过终端直接运行受限 Bash 指令，观察 OS 底层返回的拦截行为：

# 验证网络拦截：非白名单域名立即被宿主代理断开
$ srt "curl https://example.com"
Running: curl https://example.com
Connection blocked by network allowlist

# 验证文件写权限：尝试在非白名单路径创建文件触发系统级 EPERM
$ srt "touch ~/sensitive-folder/payload.sh"
Running: touch ~/sensitive-folder/payload.sh
touch: /Users/developer/sensitive-folder/payload.sh: Operation not permitted

5. 生产落地踩坑指南与避坑建议 (Gotchas)

在生产流水线或本地工作流中嵌入 srt 并不等同于一劳永逸。利用 OS 原语的取舍必然引入底层系统的特殊边界。

⚠️ 避坑预警 [macOS 私有 API 稳定性与 SIP 限制]： srt 在 macOS 上重度依赖 /usr/bin/sandbox-exec 与 Seatbelt 规则语法。苹果长期将该接口标记为“可能在未来弃用”的私有状态。在开启 System Integrity Protection (SIP) 的环境中，高版本 macOS 会限制针对部分系统级目录和守护进程调用的 Hook。在更新系统或部署非标准环境前，必须验证 Seatbelt 配置文件的有效性，避免进程因沙箱初始化解析失败直接 Crash。

⚠️ 避坑预警 [Windows 平台令牌切换缺陷与服务代理出网]： Windows 的实现严重依赖针对 srt-sandbox 账户 SID 设定的 WFP 规则。如果被沙箱化的进程创建了一个包含不同 Access Token 的独立线程并进行 Socket 建连，或者通过命名管道将网络请求委托给其他本地 System Service（例如发起 BITS 或 RPC 调用），WFP 出站过滤规则将无法识别源进程上下文，导致网络拦截静默失效。在 Windows 生产环境，禁止给沙箱进程授予过高的 IPC 交互权限。

⚠️ 避坑预警 [读写权限评估优先级的反直觉陷阱]： 配置文件中的读与写采用了相反的优先级匹配逻辑。写操作严格基于“白名单”构建，denyWrite 永远高于 allowWrite；但读操作默认全局放开，采用“黑名单限制后再局部开放”的模型，即内部路径的 allowRead 优先级高于宽泛的 denyRead。配置包含嵌套文件夹的过滤规则时，如果不显式声明敏感文件（如 .env）的精确路径，单纯配置 allowRead: ["."] 将导致子目录中的关键凭据被默认读取。