不用容器也能关住 agent：Anthropic 的 sandbox-runtime 到底是什么

先说清楚：这不是一个“10 月 24 日横空出世”的新工具

10 月 24 日，多家科技媒体在同一天集中介绍了 Anthropic 的 sandbox-runtime（命令行叫 srt）。如果你只看标题，会以为 Anthropic 当天发布了一个全新沙箱。但仓库本身的历史要老得多：anthropics/sandbox-runtime 在 GitHub 上创建于 2025 年 10 月 20 日，至今已有 886 个提交、44 个 release，npm 包 @anthropic-ai/sandbox-runtime 目前的版本是 0.0.81。它最早是 Claude Code 沙箱化 bash 工具背后的那套实现，Anthropic 在 2025 年 10 月的《Beyond permission prompts》一文中就讲过它的思路。所以更准确的说法是：一个已经在 Claude Code 里跑了一年的内部件，在 10 月 24 日这一波报道里正式走到了台前，变成任何人都能直接拿去套在自己 agent 和 MCP 服务器上的独立工具。这篇的新闻锚点是 10 月 24 日的集中报道与当前版本状态，而不是“首发日”。把这一点先讲明，是因为 agent 安全这个领域最怕的就是把“被报道”当成“被验证”。

另外划一道界线：本站此前写过 Vercel 的 durable-harness（让 agent 崩溃后不断线、不用重复烧 token），那是“跑得住”的问题；srt 是“关得住”的问题。一个管任务续跑，一个管权限边界，两者不重叠，刚好互补。

srt 到底是什么：一句话，操作系统原生的笼子

srt 的定位写在仓库 README 的第一行：一个轻量沙箱工具，在操作系统层面给任意进程加上文件系统与网络限制，不需要容器。你用 npm 全局装上 @anthropic-ai/sandbox-runtime（需要 Node.js 22.12 以上，解压后约 11.4MB，Apache-2.0 协议），然后在任何命令前面加一个 srt 前缀就行：srt npm install、srt node server.js，或者把它当 TypeScript 库用，调用 SandboxManager 包一层再 spawn。它也可以直接套在 MCP 服务器外面：把 .mcp.json 里某个服务器的 command 从 npx 改成 srt，原命令当参数传进去，规则写进 ~/.srt-settings.json，服务器立刻就被关进了笼子。

“不需要容器”是它最大的卖点，也是最容易被误读的一点。它不是说容器没用，而是说它用的是每个操作系统自带的隔离原语：macOS 上是 sandbox-exec 配合动态生成的 Seatbelt 配置，Linux 上是 bubblewrap（需要另外装 socat 和 ripgrep），Windows 目前还是 alpha，用的是一个专用的 srt-sandbox 本地账号加 Windows Filtering Platform 出站围栏和显式文件 ACL。同一套规则，到了不同平台由不同机制执行，这意味着你在 macOS 上调通的配置，换到 Linux CI 上不一定行为一致，跨平台团队要按平台各测一遍，不能只测开发机。

双隔离模型：读、写、网络是三套不同的默认规则

srt 最值得认真读的部分是它的三套默认规则，因为它们并不对称，抄错一套就会留洞：

• 读是“先放行、再拒绝”：默认读哪里都行，你要显式 deny 掉大片区域（比如整个用户目录），再把工作目录等个别路径重新 allow 回来。更细的规则是：更具体的 deny 仍然优先于较宽泛的 allow，比如 denyRead 里写 **/.env，即使 allowRead 放行了当前目录，.env 还是读不到。
• 写是“只许明确放行的”：默认全都不许写，必须显式 allowWrite 工作目录、/tmp 这类路径。空的 allow 列表就等于完全不能写。
• 网络是“只许明确放行的”：默认全都不通，必须显式 allow 域名，支持通配符和端口，比如 *.npmjs.org、api.example.com:443。空的 allow 列表就等于断网。

这三套规则覆盖的是整棵进程树：命令本身、它拉起的脚本、脚本再拉起的子进程，全在笼子里。这一点很关键，因为 agent 的典型作恶路径从来不是主进程本身，而是它中途调用的某个脚本、某个安装步骤、某个被提示词注入带偏的子命令。只管主进程的沙箱，在 agent 场景里等于没管。

网络那一侧的实现也值得说透：沙箱里的进程并没有自己的出网通道，它的流量只能走宿主机上跑着的 HTTP 代理和 SOCKS5 代理。Linux 上沙箱进程的网络命名空间整个被拿掉，代理通过 bind-mount 进沙箱的 Unix socket 接入；macOS 上 Seatbelt 配置只放行一个本地端口，代理就监听在那个端口上。代理按请求查你的域名 allowlist 和 denylist，还会做解析地址检查：一个被放行的域名如果解析到了 loopback 地址或云厂商元数据地址，照样会被拦。这是对付“域名合法、解析结果不合法”那类绕过手法的，vibe 项目里 agent 要访问内网元数据服务骗密钥的场景，正好撞在这个检查上。

默认配置里藏着的那个洞：读默认是放开的

如果你不写任何配置文件直接跑 srt，README 写明的默认行为是：没有网络、写不出默认路径之外、读不受限。也就是说，一个“默认配置”的 srt 沙箱，agent 照样能读你机器上的敏感文件。社区实测也印证了这一点：Claude Code 的沙箱文档本身就写着，被沙箱化的命令可以读“机器上的大部分内容，包括 ~/.ssh 这类凭证文件”，除非你显式 deny 掉。所以 srt 的第一条落地规则应该是：不要只写 allowWrite 和 allowedDomains，denyRead 清单要和它们同等重要，~/.ssh、~/.aws、.env、各类云凭证目录，第一次配就要写进去。把默认配置当成安全配置，是用 srt 最容易犯的错。

配套的另一条规则是：配置文件本身要当成代码管起来。srt-settings.json 进版本控制、走评审、改动留记录；但别把真实密钥写进这个文件——它的作用是划边界，不是存凭证。README 里还提到一套强制 deny 路径（.bashrc、.zshrc、.gitconfig、.mcp.json、.git/hooks 等），无论 allowWrite 怎么写都写不进去，这是防止 agent 改掉你的 shell 启动文件和 git 钩子给自己留后门，属于“就算你配错了也有底线”的设计，值得肯定，但不能替代你自己的 deny 清单。

84% 这个数字，到底该怎么理解

报道里引用最多的一个数字是：Anthropic 内部使用中，沙箱让 Claude Code 的权限提示减少了 84%。这个数字来自 Anthropic 自己，不是独立基准测试，也没有公开的对照实验细节，所以不能把它读成“安全性提升 84%”——它量的是提示次数，不是拦截成功率。它的真正含义是另一个维度的：审批疲劳。开发者一天点几百次“允许”，到后来根本不看内容就点，审批就名存实亡。固定边界的好处是把“每次都要人点头”变成“边界内随便干、出边界才问人”，人的注意力只花在真正越界的那几次上。这个逻辑是对的，但前提是边界本身划得对；边界划错了，提示少了，风险反而更大。84% 是一个关于体验的数字，不是关于安全的保证，引用时必须带上“Anthropic 内部自报”这个定语。

真正的权衡不在“开不开沙箱”，而在 allowlist 的宽度

编码 agent 不是只改文件的程序，它要装依赖、拉文档、调 API。allowlist 太严，npm install 先失败，agent 开始绕路；太宽，沙箱等于摆设。srt 给这个两难准备了几个调节旋钮，值得逐个知道：通配符与端口放行；ask 回调——对没有规则覆盖的域名做一次决策，还能把拒绝理由回传给模型，让它知道该走哪个被允许的替代地址；单次命令放行——只给某一次调用临时开个口子；--control-fd——命令跑着的时候通过文件描述符实时换整套网络配置（注意是整套替换，不是打补丁，漏写的键会回到默认值）；以及上面提到的解析地址检查。实战里最实用的组合是：基础 allowlist 只放包 registry、代码托管和你明确调用的 API 域名，临时需求走单次放行或 ask 回调，而不是为了图省事把 *.com 一放了之。一个 allowlist 里出现顶级通配符的那天，就是这个沙箱名存实亡的那天。

给 vibe 开发者的落地清单

如果你现在就想在一个 vibe 项目里用上 srt，按这个顺序做，比直接全量套上去更稳：第一步，先给最危险的外部件上套——那些你没审过代码的 MCP 服务器，把 command 换成 srt，denyRead 先写 ~/.ssh、~/.aws、**/.env，allowWrite 只给当前项目目录，网络只放它确实要访问的域名，跑一周看它报什么错，再决定放宽哪里。第二步，再给 agent 自己的长会话上套，重点是写权限和网络，而不是读权限的完美清单——先保证它写不坏系统、发不出去数据，再慢慢收紧读。第三步，把 srt-settings.json 提交进仓库，让团队每个人跑的都是同一套边界；本地一份、私下一份的配置，等于没有配置。第四步，Windows 团队先别急：alpha 状态加上一串已知限制（走系统 TLS 栈的 curl、PowerShell Invoke-WebRequest、.NET HttpClient、winget 都不能用，系统服务代发的流量会绕过围栏），等它稳定再上生产路径。第五步，定期做一次“越狱演习”：故意让 agent 去读 deny 掉的路径、访问没放行的域名、写系统目录，看它是不是真的被拦住——沙箱和测试一样，不演习就等于没装。

它不能替你解决的问题

最后要泼三盆冷水。第一，srt 还是 Beta Research Preview，README 自己写着 API 和配置格式都可能变，现在把大量自动化绑死在它的配置格式上，将来要还迁移账。第二，它防的是“越界”，不是“在界内作恶”：一个被提示词注入带偏的 agent，在你放行的写路径里删库、在你放行的 API 域名上调删除接口，沙箱不会拦，因为那都在你允许的范围内——边界之内的行为正确性，还得靠评审、测试和本文之外的护栏。第三，TLS 终止目前还是实验性功能，用来在代理层检查 HTTPS 内容，开启前要想清楚中间人检查对隐私与合规的影响。srt 的价值不在于它是一个完美的笼子，而在于它把“agent 到底能碰什么”从一句口头承诺变成了一份可以版本控制、可以测试、可以审计的配置文件。在 agent 越来越能干的今天，这份文件本身，就是安全工作的一部分。

时间线还原：它是怎么从 Claude Code 内部件走到台前的

把 srt 的来龙去脉按时间排开，能避免很多误读。2025 年 10 月，Anthropic 发表《Beyond permission prompts》，讲 Claude Code 如何用沙箱减少权限提示，那篇文章里提到的沙箱实现就是后来独立成包的 sandbox-runtime；同月，anthropics/sandbox-runtime 仓库在 GitHub 上创建。之后的一年里，它随着 Claude Code 的迭代持续演进，提交数累积到 886 个，release 做到 44 个，npm 版本走到 0.0.81。2026 年 10 月 24 日，MarkTechPost、AIWeekly 等媒体在同一天集中介绍了它，npm 包的下载量与仓库 star 数（目前 6479 个）在报道后明显走高。也就是说，10 月 24 日这个日期的意义是“被公众集中注意到”，而不是“被创造出来”。对评估一个安全工具来说，这个区分很重要：一个跑了一年的内部件，意味着它的默认行为、已知限制、配置格式都经历过真实使用，而不是发布当天才写出来的演示代码；但也意味着，报道里那些“全新发布”的措辞要打折扣，真正的新信息是它作为独立工具的定位被正式讲清楚了——不绑定 Claude Code，任何进程、任何 MCP 服务器都能套。

这个时间线还解释了为什么它的文档里有两种语气混在一起：一部分是面向 Claude Code 用户的“开箱即用”语气，另一部分是面向独立采用者的“研究预览、接口可能变”语气。读文档时要以后者为准：你现在采用它，采用的是一个仍在演进的预览版，而不是一个 frozen 的稳定版。团队如果要把它写进内部安全基线，基线里应该同时写上“跟随上游配置格式变化”的维护责任，而不是假设配置格式永远不变。

配置实战：一份可以直接改着用的骨架

光讲原理不够，这里给一份骨架配置，照着改就能在自己的项目里先跑起来。注意这份骨架的假设场景是：你在本机给一个 MCP 服务器上套，服务器只需要访问包 registry 与代码托管，不需要访问云厂商控制台；工作目录就是当前项目目录。把 allowedDomains 换成你自己的域名清单之前，不要直接照搬：

{
  "network": {
    "allowedDomains": ["registry.npmjs.org", "*.npmjs.org", "github.com", "api.github.com"],
    "deniedDomains": []
  },
  "filesystem": {
    "denyRead": ["~/.ssh", "~/.aws", "**/.env"],
    "allowWrite": ["."],
    "denyWrite": [".env", ".git/hooks"]
  }
}

这份骨架里有三个刻意的设计。第一，denyRead 与 allowWrite、allowedDomains 平起平坐，缺了 denyRead 就等于默认配置的洞还在。第二，denyWrite 里除了 .env，还写了 .git/hooks——因为 agent 一旦能改 git 钩子，就能在你下次提交、切换分支时自动执行它留下的代码，这是最典型的持久化后门路径，README 的强制 deny 清单里本来就有这一项，这里显式写出来是提醒你不要在自己的配置里把它覆盖掉。第三，allowedDomains 只放了四条：npm registry、GitHub 域名与 API 域名；你的 MCP 服务器如果还要访问别的服务（比如某个云存储、某个内部 API），一次加一条、加一条测一次，而不是一开始就放宽到 *.com。配置改完之后的第一件事不是跑正式任务，而是跑一次“越狱测试”：让 agent 去 cat ~/.ssh/id_rsa、去 curl 一个没放行的域名、去写项目目录外的文件，确认三条都被拦住，再投入使用。

还有一个容易被忽略的细节：srt 的配置文件如果存在但读不懂、或者校验不通过，它的做法是直接报错退出，而不是悄悄退回默认配置。这个行为值得肯定——静默回退到默认配置会把你的 denyRead 一起丢掉，比报错更危险。但它也意味着：配置文件的语法错误会在任务启动时直接表现为失败，排查时要先看配置校验，而不是先怀疑网络或模型。把配置文件纳入版本控制、改动走评审，同样也是为了避免“某人随手改了一行配置，整个团队的边界就变了”这种事故。

和容器、微虚拟机的取舍：轻不等于弱，但也不等于全能

把 srt 放到整个 agent 沙箱光谱里看，它的位置在“操作系统原生隔离”这一档：比纯提示词约束和纯权限审批强得多，比 Docker 容器轻，比 Firecracker 微虚拟机更轻，但隔离强度也相应更依赖宿主操作系统的实现质量。Docker 沙箱和 E2B 这类微虚拟机方案的优势是边界更硬：一台微虚拟机被攻破，宿主机通常还能保住；劣势是启动开销、镜像管理、跨平台一致性都要额外成本。srt 的优势正好反过来：零镜像、毫秒级启动、直接跑在本机开发环境里，和现有工作流贴合；劣势是隔离边界就是操作系统原语本身的边界——Seatbelt 配置写错、bubblewrap 参数给错、Windows 的 WFP 围栏有已知绕过路径，都会直接变成沙箱的洞。选型时不要问“哪个更安全”这种抽象问题，要问“我的威胁模型里，攻击者已经能控制到哪一层”：如果你的 agent 只处理可信代码、主要防的是误操作和提示词注入带偏，srt 这一档足够；如果你要跑完全不可信的第三方代码、或者要把 agent 服务开放给外部用户，微虚拟机那一档才是起点，srt 只能作为其中一层，而不是全部。

还有一个选型维度是“可观测性”。srt 在 macOS 上可以接系统沙箱违规日志做实时告警，Linux 上可以用 strace 追踪违规；这意味着它的违规行为是能被看见、被记录、被复盘的。一个沙箱如果只能“拦”，不能“记”，出事之后你连它拦过什么、漏过什么都不知道，复盘就无从谈起。落地时要把违规日志接到你已有的日志系统里，和任务日志放在同一个时间轴上对照：某次任务失败，到底是模型能力问题、还是沙箱拦住了它需要的某次访问，日志对照一眼就能分清。很多团队把沙箱违规当成“任务失败”去调提示词，调了半天才发现是沙箱配置问题，这个弯路完全可以靠日志对照省掉。

三档配置：按 MCP 服务器的危险程度分级上套

前面给了一份骨架配置，这里再往前一步：不要给所有 MCP 服务器用同一套规则。服务器的危险程度不同，笼子的松紧也应该不同，分三档处理最省事。第一档是“只读工具型”：比如只查文档、只读仓库文件的服务器，网络可以放宽到它确实要查的那几个域名，但写权限要收得最紧——只给一个专门的输出目录，甚至完全不给写权限，因为它本来就不需要写。第二档是“可写工具型”：比如能改文件、能跑测试的服务器，写权限只给当前项目目录，denyRead 照单全写，网络只放包 registry 与代码托管；这一档是 vibe 项目里最常见的，也是最容易因为“图方便”而放宽的一档，规则是：每次放宽都要写一条理由，理由写在配置文件的注释或提交信息里，三个月后回看时还能知道当初为什么放。第三档是“联网工具型”：比如要调外部 API、要访问云服务的服务器，网络 allowlist 要按“域名 + 用途”逐条登记，拒绝理由要配好（deniedDomainReasons），让 agent 被拒绝时能读到“应该走哪个被允许的替代地址”，而不是只看到一句冷冰冰的拒绝；这一档还要额外打开违规日志的采集，因为联网工具的越界行为最难事后追溯。

分档还有一个附带好处：出问题时定位更快。某个服务器突然开始报错，先看它属于哪一档，再看这一档最近改过哪条规则，基本就能锁定是配置问题还是服务器本身的问题；而不分档的配置一出问题，只能把整份规则从头读一遍。另外，分档配置要和团队的服务器清单放在一起维护：新接一个 MCP 服务器时，先定档、再写规则、再跑越狱测试，三步走完才算接完；跳过定档直接套通用配置的服务器，往往就是第一个出事的服务器。

图注： 数据中心机房实拍，象征 agent 运行背后的基础设施与隔离边界——配图为通用机房照片，并非 srt 本身的界面截图。