🛡️ AI Agent 的沙箱与安全隔离
(Sandboxing & Containment)

1 · 🎯 30 秒速览

先说人话版:沙箱(sandbox)就是给 Agent 划一个「儿童游乐区」——它在里面可以随便跑代码、写文件、发请求,但栅栏外的东西(你的 SSH 密钥、公司数据库、任意外网地址)碰不到。Containment(隔离/围堵)是更大的概念:不去猜 Agent「会做什么」,而是用硬边界限定它「能做什么」,从而给最坏情况的损失封顶——业界把这个最坏损失叫爆炸半径(blast radius)。

为什么现在(2026 年)这个主题突然变成必修课?三件事撞到了一起:① Agent 的权限从「聊天」升级到「操作文件系统 + 执行 Shell + 调私有服务」;② 业界共识形成——普通 Docker 容器不足以运行 LLM 生成的不可信代码(共享内核就是共享爆炸半径);③ 头部厂商同时把牌摊开:Anthropic 发布了讲述三个产品隔离架构的工程复盘并开源了沙箱运行时 srt,OpenAI 也在 2026 年把原生沙箱执行加入 Agents SDK。下面逐层展开。

2 · 🧭 背景与动机:为什么「人工审批」撑不住了

在沙箱流行之前,Agent 安全的主流方案是人在回路(human-in-the-loop):Agent 每次要执行命令,先弹窗问用户「允许吗?」。理论上滴水不漏,实际上 Anthropic 的遥测数据揭穿了它:

这就是所谓的审批疲劳(approval fatigue):一个为「监督」设计的机制,反而训练出了无脑点「允许」的用户。Anthropic 工程博客对此的总结很直接:任何概率性防御(弹窗、分类器、模型对齐)都有非零漏报率;只有确定性的环境边界,才能兜住所有概率性防线都失手的那一次。(来源:Anthropic《How we contain Claude across products》,2026-05-25)

另一条线:为什么 Docker 容器也不够

普通容器(Docker/runc)里的进程和宿主机共享同一个内核,只是用命名空间和 cgroups 做了逻辑隔离。跑自己团队写的、过了 CI 的代码没问题;但 LLM 生成的代码、用户上传的代码应当按「敌意代码」对待——一个内核漏洞就能让它越出容器。社区选型指南(2026-02)总结的行业信号很清楚:AWS 为 Lambda 造了 Firecracker、Google 为多租户造了 gVisor、Azure 用 Hyper-V 做临时沙箱——三大云厂商面对 AI 工作负载,没有一家选普通容器。(来源:Manveer Chawla《AI agent sandboxing in 2026》)

3 · ⚔️ 三类风险、三道防线(Anthropic 的威胁模型)

做隔离设计前,先想清楚「防的是谁」。Anthropic 把 Agent 的安全风险分成三类(官方框架):

对应地,防线也有三道,部署在三个不同的组件上:

模型层防御的现实水位可以参考官方公布的数字:在测试提示注入敏感性的 Gray Swan Agent Red Teaming 基准上,Claude Opus 4.7 单次攻击成功率约 0.1%,但 100 次自适应尝试后升到 5–6%;Claude Code 的 auto mode 分类器能在执行前拦下约 83% 的越权行为(误拦良性命令约 0.4%,漏过约 17%)。很强,但都不是 100%——这正是它们必须和环境层叠加使用的原因。

4 · 🪜 隔离技术光谱:从容器到机密计算的五级台阶

「沙箱」不是一种技术,而是一个光谱。每往上走一级,安全边界更硬,性能开销也更大。以下五级分类整理自社区选型指南(2026-02),术语先用大白话过一遍:

5 · 🏗️ 三种落地模式:同一家公司,三套架构

光谱是原材料,产品要的是完整方案。Anthropic 的工程博客难得地公开了自家三个产品的隔离架构——最有价值的洞察是:没有唯一正确的沙箱,隔离强度要匹配「用户看得懂多少」。

模式一:临时容器(claude.ai 代码执行)

Claude 在 claude.ai 里跑代码时,是在服务端一个 gVisor 容器里,文件系统按会话即弃,不碰用户本地机器。爆炸半径最小,能力上限也最低。这里的威胁模型其实很传统:不是保护用户机器,而是保护自家基础设施和租户之间的互相隔离。

模式二:人在回路的沙箱(Claude Code)

Claude Code 跑在用户机器上,必须碰文件、Shell 和网络。它的赌注是:用户是开发者,看得懂 bash,所以「弹窗审批」是可行的兜底。审批疲劳出现后,补上了 OS 级沙箱(macOS 用 Seatbelt,Linux 用 bubblewrap):沙箱内读随意、写限工作区、网络默认拒绝——换来弹窗减少 84%,并把这套运行时开源为 srt(见第 6 章)。

模式三:本地虚拟机(Claude Cowork)

Cowork 面向不会读 bash 的知识工作者——「让用户判断 find . -exec rm {} \; 危不危险」不成立,所以边界必须绝对、常开、不弹窗:整个执行环境放进本地 VM(macOS 用 Apple Virtualization framework,Windows 用 HCS),只挂载用户选择的工作区,凭证留在宿主机钥匙串、永不进入客户机。后来的两次架构调整也值得记:Agent 循环移出 VM(VM 启动失败时产品不至于瘫痪,代码执行仍留在 VM 内),本地 MCP 服务器也移到宿主机(与 Claude Desktop 对齐,交由管理员审核)。

🖼️ 原图已失效(来自 Anthropic 工程博客)。该图展示 Cowork VM 的六大隔离机制:其中两项(hypervisor 边界、vsock 通道)在客户机内核之外强制执行,即使 Agent 在 VM 内拿到 root 也无法突破;另外四项为客户机内部机制,刻意保持精简。

Cowork VM 的六大隔离机制。图源:Anthropic 工程博客《How we contain Claude across products》。

表格译自 Anthropic 工程博客原文。

6 · 🧰 上手实战:用 srt 给任意进程套沙箱

理论讲完,上手最快的路径是 Anthropic 开源的 srt(Sandbox Runtime):一个轻量沙箱工具,不需要容器,直接用 OS 原生原语(macOS 的 sandbox-exec/Seatbelt、Linux 的 bubblewrap)+ 代理式网络过滤,给任意进程加上文件和网络限制。它就是 Claude Code 沙箱的提取物,GitHub 约 3.7k star,目前为 Beta 研究预览(API 可能变动),暂不支持 Windows。以下命令与配置均摘自官方 README:

# 安装
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

核心心智模型:双重隔离 + 两种默认方向

srt 的设计哲学是默认安全(secure-by-default):进程从最小权限出发,你只显式凿开需要的洞。四条规则记住方向即可:

1. 读:先允许后拒绝(deny-then-allow)
   默认全盘可读;可以先拒掉大区域(如 /Users),再放行其中的具体路径(如 .)。allowRead 优先于 denyRead。
2. 写:默认全拒(allow-only)
   必须显式放行(如 .、/tmp);denyWrite 优先于 allowWrite,用于在可写区里再挖出保护区(如 .env)。注意读写的优先级方向刻意相反。
3. 网络:默认全拒
   空的 allowedDomains = 完全断网。所有流量强制走宿主机上的 HTTP/SOCKS5 代理(Linux 直接移除网络命名空间,macOS 的 Seatbelt 只放行代理端口),由代理执行域名允许清单。
4. 强制保护路径:内置兜底
   .bashrc、.gitconfig、.git/hooks/、.mcp.json、.vscode/ 等永远禁写——即使落在你 allowWrite 的范围内。这是针对「往 shell 配置注入命令实现沙箱逃逸」的纵深防御。

实用场景:给 MCP 服务器套沙箱

官方 README 的招牌用例——只改一行,把不可信 MCP 服务器关进沙箱(.mcp.json):

{
  "mcpServers": {
    "filesystem": {
      "command": "srt",   // 原来是 "npx",在前面套一层 srt 即可
      "args": ["npx", "-y", "@modelcontextprotocol/server-filesystem"]
    }
  }
}

再在 ~/.srt-settings.json 里写限制策略(工作区可写、敏感目录禁写、默认断网):

{
  "network":    { "allowedDomains": [], "deniedDomains": [] },
  "filesystem": {
    "denyRead":  ["~/.ssh"],
    "allowWrite": ["."],
    "denyWrite": ["~/sensitive-folder", ".env"]
  }
}

也可以作为库嵌入自己的 Agent(TypeScript,摘自官方 README):

import { SandboxManager } from '@anthropic-ai/sandbox-runtime'

await SandboxManager.initialize({
  network:    { allowedDomains: ['api.github.com'], deniedDomains: [] },
  filesystem: { denyRead: ['~/.ssh'], allowWrite: ['.', '/tmp'], denyWrite: ['.env'] },
})
const cmd = await SandboxManager.wrapWithSandbox('curl https://example.com')
// spawn(cmd, ...) 正常执行,限制已生效

顺带一提生态对照:OpenAI 也在 2026 年 4 月为其 Agents SDK 加入了原生沙箱执行与模型原生 harness(先 Python 后 TypeScript),并面向企业推出连接私有 MCP 服务器的 Secure MCP Tunnel(据 TechCrunch 与 OpenAI 官方文档)。两家路线殊途同归:沙箱正在从「产品内部实现」变成「暴露给开发者的标准件」。

7 · 🧭 选型:自建、API 还是托管平台?

如果你要为自己的 Agent 产品选沙箱方案,2026 年的生态可以按抽象层次分成三层(整理自社区选型指南)。选型的第一问不是「哪个技术强」,而是「你想把工程精力花在哪」:

另有一个跨层选项:Google Agent Sandbox(KubeCon NA 2025 发布的 CNCF 开源项目),K8s 原生控制器,支持 gVisor/Kata 双后端和暖池 CRD——已在 Kubernetes 上的团队应优先评估它,代价是集群仍要自己运维。

四个决策问题(按顺序问自己)

1. 代码有多不可信?
   自家 CI 过的代码 → 容器够用;LLM 生成的代码 → gVisor 或 microVM 起步;用户上传的任意二进制 → 按敌意代码办,microVM 起步。
2. 会话跑多久?
   一次性脚本看冷启动(快照恢复能到几十毫秒);长时 Agent 看计费模型——按秒计费的 API 会话一闲置就烧钱。
3. 数据在哪?(data gravity)
   每次执行要搬几个 GB 的模型权重或 CSV,远程沙箱 API 的延迟和出网费用会失控——让计算去找数据(平台层或自建同址),别让数据迁就沙箱。
4. 合规要求什么?
   SOC 2 / 数据驻留 / 审计日志——自建原语栈拿认证按 12–18 个月工程量估;托管平台可以「继承」合规控制,BYOC(部署进你自己的云账号)是数据驻留的关键筛选项。

注:各平台的具体参数(冷启动毫秒数、GPU 支持、会话时长上限)多来自厂商自述或竞品对比博客,采购前应以各家当前官方文档实测为准。

8 · 💣 真实事故与常见坑(最值钱的一章)

Anthropic 在博客里罕见地公开了四起「我们漏掉的风险」。每一起都对应一类普遍的设计盲区,强烈建议对照自查:

🖼️ 原图已失效(来自 Anthropic 工程博客)。该图上半部展示攻击路径:目的地是合法域名 api.anthropic.com,代理放行,数据外传;下半部展示修复:VM 内的 MITM 代理只放行携带本 VM 会话令牌的请求。

经允许域名外传数据的攻击路径与修复。图源:Anthropic 工程博客。

其他高频坑(来自官方文档与社区)

• 符号链接逃逸:symlink 解析必须发生在路径校验之前,否则授权目录里的一个软链就能指向外部逃出边界(Anthropic 官方提示)。
• 「自建组件是最弱一环」:Anthropic 复盘里跨产品成立的规律——gVisor、seccomp、hypervisor 这些久经沙场的标准原语全都顶住了,出事的两次都是自己写的代理代码。能用成熟原语就别自己造。
• 宽域名 = 外传通道:srt README 官方提醒,放行 github.com 意味着可以向任意仓库 push;需要更细粒度就上可审计的 MITM 代理过滤具体 API 调用。
• 工具输出是攻击面,即使工具可信:通过恶意软件检查的 GitHub 连接器,照样能把一个投毒 README 装进模型上下文——「审计过的连接器 ≠ 审计过的数据」。Claude Code/Cowork 的做法是让工具调用过代理、返回值入上下文前先过一个小而快的检查模型。

9 · 🔭 趋势展望(2026 下半年 – 2027)

• 持久记忆投毒:CLAUDE.md、产品记忆、定时任务状态目录……跨会话存活的上下文越来越多,一次注入=每次启动都重新加载,这是经典后渗透「持久化」在 Agent 世界的翻版。会话启动时的分类器扫描将成标配。(Anthropic 展望)
• 多智能体信任升级:子 Agent 可以隔离不可信内容(只上报结构化事实),但若子 Agent 输出被当作「自己人」而获得更高信任,反而制造了新的注入向量——信任分级与信任升级攻击是一体两面。(Anthropic 展望)
• Agent 身份:Agent 该有自己的独立身份,还是作为用户的延伸继承用户权限?Cowork 当前答案是「宿主钥匙串保管凭证 + VM 拿按会话降权的令牌、可独立吊销」;跨平台的通用答案业界还在摸索,NIST 已立项研究。(Anthropic 展望)
• 协议层权限:MCP 清单 → 沙箱策略:一个正在收敛的方向——让沙箱的防火墙规则和文件挂载直接由 Agent 声明的 MCP 工具清单推导(只授权 web_search 的 Agent 自动只开 443 出站)。据社区指南判断,目前尚无生产级实现,首批集成预计 2026 年底出现。
• 更轻的隔离形态:微软 LiteBox(Library OS,自带 SEV-SNP 机密计算 runner)和 BoxLite(把 microVM 隔离做成可 import 的库,「沙箱界的 SQLite」)都还早期,但指向同一趋势——隔离下沉为语言级标准件。

10 · 📚 学习资源清单

• 必读(官方一手):Anthropic《How we contain Claude across products》 — anthropic.com/engineering/how-we-contain-claude(本文第 3、5、8 章的主要来源)
• 动手(官方工具):srt 仓库与 README — github.com/anthropic-experimental/sandbox-runtime;配套博文《Making Claude Code more secure and autonomous with sandboxing》 — anthropic.com/engineering/claude-code-sandboxing;Claude Code 沙箱文档 — docs.claude.com
• 选型全景:Manveer Chawla《AI agent sandboxing in 2026》 — manveerc.substack.com(五级光谱与三层生态框架来源)
• 平台对比(注意厂商立场):Modal《Best Code Execution Sandboxes for AI Agents》 — modal.com;Northflank — northflank.com
• K8s 路线:Google Agent Sandbox(CNCF) — github.com/kubernetes-sigs/agent-sandbox
• OpenAI 侧:Agents SDK 沙箱升级报道 — TechCrunch(2026-04-15);Agents SDK 文档 — openai.github.io
• 治理延伸:NIST《AI Agent Identity and Authorization》项目 — nccoe.nist.gov