Anthropic开源sandbox-runtime：无需容器的AI代理沙箱

当AI代理开始"动手"，边界在哪里

AI代理能读写文件、调用命令行、通过MCP服务器连接外部工具——能力越强，失控的代价就越高。Anthropic开源的 sandbox-runtime（简称srt） 正是冲着这个痛点来的：它是Claude Code背后的操作系统级沙箱，用系统自带的安全机制约束代理的文件和网络访问，而不必拉起容器。

这个定位值得细看。容器方案（Docker等）能提供强隔离，但代价是镜像构建、运行时依赖和额外的资源开销，对"跑一条命令"这种高频轻量场景显得笨重。srt选择直接站在操作系统这一层，用macOS的Seatbelt和Linux的bubblewrap做限制，把隔离成本压到接近零。

双平台实现：Seatbelt与bubblewrap

srt的跨平台策略很务实——不自己造轮子，而是复用两个成熟的内核级沙箱设施。

在macOS上，它调用 Seatbelt（即sandbox-exec背后的策略框架），通过声明式配置文件定义进程能访问哪些路径、能否建立网络连接。在Linux上，它依赖 bubblewrap（bwrap），这是Flatpak等项目长期使用的非特权沙箱工具，通过命名空间隔离文件系统和网络。

两者都属于"进程级"约束：不需要虚拟化，不需要守护进程，启动开销极小。对Claude Code这类需要频繁执行shell命令、读取项目文件的工具来说，这种轻量特性是关键。

Seatbelt 是苹果 macOS 内核中基于 TrustedBSD MAC 框架的强制访问控制机制，sandbox-exec 命令只是它的一个用户态入口。其策略文件采用类似 Scheme 的 S-表达式（Sandbox Profile Language），以声明方式规定进程可读写的路径、可连接的网络地址与端口、可调用的系统服务等。策略在进程创建时加载，之后任何越权操作都会被内核直接拒绝并记录日志。由于策略是声明式的，审计者可以直接阅读配置来判断允许范围，而不必猜测运行时行为。Seatbelt 的局限在于它主要约束用户态进程的常规系统调用，对内核漏洞或某些底层原语的防护能力有限。

bubblewrap（bwrap） 是 Linux 上的非特权沙箱工具，最初从 Flatpak 项目中拆分出来，现已成为许多桌面与容器场景的底层组件。它依赖 Linux 命名空间（mount、pid、network、user 等）和 seccomp 过滤器，在不具备 root 权限的情况下为进程构建一个隔离的挂载视图与网络环境。与容器运行时不同，bwrap 不打包镜像、不启动守护进程，只做一次快速的命名空间切换，因此启动开销在毫秒级。它常与 --unshare-net、--ro-bind 等参数配合，精确控制哪些目录只读、哪些目录可写，以及进程是否拥有网络访问能力。

保护对象不止是代理本身

原文特别提到，srt限制的对象包括代理、MCP服务器和CLI工具三类。这个范围划分很有信息量。

MCP（Model Context Protocol）服务器如今是代理连接外部数据的标准通道，但一个配置不当的MCP服务器同样可能成为越权访问的入口。把MCP进程一并纳入沙箱，意味着安全边界不只在"代理主进程"，而是覆盖整条工具调用链。CLI工具同理——代理调用的git、npm、curl，每一个都是潜在的文件与网络出口。

这种"全链路收口"的思路，比只盯着模型输出做内容过滤要扎实得多。

Model Context Protocol（MCP） 是 Anthropic 于 2024 年底开源的协议，用于让 AI 应用以统一方式连接外部数据源与工具。一个 MCP 服务器本质上是一个独立进程，通过标准输入输出或 HTTP/SSE 与客户端通信，对外暴露“资源”“工具”“提示模板”等能力。代理在运行时可能按需拉起或连接多个 MCP 服务器，每个服务器都拥有自己的文件系统与网络权限。如果某个 MCP 服务器配置错误或被恶意替换，它就可能绕过代理层面的限制直接访问敏感文件或外发数据。因此，将 MCP 服务器进程纳入同一沙箱策略，是堵住工具调用链侧门的关键一步。

开源的意义：沙箱不该是黑盒

srt以开源形式发布，本身就是一个信号。AI代理的安全策略如果完全由厂商黑盒实现，企业很难审计"到底限制了什么"，也难以根据自身合规要求调整策略。开源让安全边界变得可检查、可定制、可复现。

对开发者而言，这也意味着可以把srt嵌入自己的代理框架，而不必绑定Claude Code。考虑到Anthropic此前已开源MCP并推动其成为事实标准，srt的开放姿态与之连贯：先定义工具调用协议，再提供执行这些调用的安全底座。

轻量隔离的取舍

OS级沙箱并非没有代价。它隔离的是文件与网络访问，共享的是内核——相比虚拟机或强隔离容器，面对内核漏洞类攻击的防护面更窄。换句话说，srt解决的是"代理误操作或提示注入导致的越权"这类高频风险，而不是"对抗性极强的多租户隔离"。

这个取舍对大多数开发场景是合理的。真正需要硬隔离的生产环境，仍可叠加容器或微虚拟机。srt的价值在于把安全默认值往前推了一步：不必先上重型方案，也能让代理跑在笼子里。

开发者该如何看待它

如果你正在构建或使用编码代理，srt提供了三个可直接落地的启示：一是把MCP服务器和CLI工具纳入同一安全策略，别只防主进程；二是优先用OS原生机制做第一道防线，成本低、易审计；三是安全策略要写成显式配置，而非依赖代理"自觉"。

代理能力的扩张不会停，边界设计必须跟上。srt算不上终极答案，但它把"默认安全"从口号变成了几行配置。