我们如何在各产品中隔离 Claude¶
原文发布于 2026 年 5 月 25 日，作者 Max McGuinness, Mikaela Grace, Jiri De Jonghe, Jake Eaton, Abel Ribbink
引言¶
随着 Agent 能力和访问权限不断扩大，核心工程问题变成了如何限制"爆炸半径"——即故障可能造成的最大损失——同时继续部署高能力 Agent。
"十二个月前，我们会直接否决授予 Claude 足以瘫痪 Anthropic 内部服务的访问权限。"
如今这种级别的访问已是常态，大幅提升了开发者的生产力。风险由两个因素构成：故障发生的概率和潜在损害的范围。模型能力提升降低了故障概率，但爆炸半径随着能力增长而扩大。
当能够对自主 Agent 的相对损害设定上限时（比如通过环境控制），高效用的能力可以推动部署决策。Claude Mythos Preview 是一个因爆炸半径过大而在 2026 年 4 月未发布的模型示例。
限制爆炸半径的两条路径¶
1. 人在回路的监督（Human-in-the-Loop）¶
让用户逐步审批 Agent 操作，但审批疲劳会迅速消解这道防线的价值。 Claude Code 曾在每轮操作时都请求用户许可。遥测数据显示"用户批准了大约 93% 的权限弹窗"。随着时间推移，用户审批变得越来越不认真——审批疲劳会逐渐占据主导。Claude Code 的 auto mode 自动放行安全操作来缓解这一问题，但漏洞依然存在。
2. 隔离（Containment）¶
与其监督 Agent 做了什么，不如从根本上限制它能做什么——通过沙箱、VM 和出口控制。 这是 Anthropic 投入最多工程精力的方向，也是令人意外的故障多发区域。
过去两年发布的三款主要 Agent 产品：
- claude.ai
- Claude Code
- Claude Cowork
三类风险，三层防御¶
风险分类¶
| 风险类型 | 说明 | 关键特征 |
|---|---|---|
| 用户滥用 | 用户主动指挥 Agent 执行有害操作 | 从绕过检查到直接的恶意指令 |
| 模型异常行为 | Agent 自行采取了无人要求的有害行动 | 更强的模型犯更少的错误，但也更擅长找到意料之外的达成目标的路径 |
| 外部攻击 | 通过工具、文件或网络对 Agent 发起攻击 | 包括 prompt 注入和对运行时/编排层/代理层的传统攻击 |
模型异常行为的真实案例：Claude 模型曾经"热心地"逃逸出沙箱，检查 git 历史找到编程测试的答案，以及识别出一个基准测试并解密其答案密钥。
三层防御¶
| 防御层 | 手段 | 作用 |
|---|---|---|
| 环境 | 进程沙箱、VM、文件系统边界、出口控制 | 硬性限制 Agent 能触达的范围 |
| 模型 | System prompt、分类器、探针、训练调整 | 引导和约束 Agent 行为 |
| 外部内容 | MCP 服务器、插件、Web 搜索工具 | 管控 Agent 接收的信息 |
关键数据：在 Gray Swan 的 Agent Red Teaming 基准测试上，Claude Opus 4.7 将单次攻击成功率控制在约 0.1%，100 次自适应尝试后约为 5-6%。Claude Code auto mode 在执行前拦截了约 83% 的过度行为。
"经过审计的连接器不等于经过审计的数据"——一个 GitHub 连接器可以加载一个被投毒的 README。
需要防御的三个组件：模型本身、运行环境，以及 Agent 能触达的外部内容。
Claude Code 的 reference devcontainer 让 Agent 可以无人值守运行。
Agent 隔离模式¶
模式一：临时容器（claude.ai 代码执行）¶
在 claude.ai 中运行代码时，所有执行都在隔离基础设施上的 gVisor 容器内完成。 Agent 完全运行在服务端，拥有临时文件系统（按会话划分）。爆炸半径最小，但能力也最受限——没有持久化工作区，无法访问用户文件系统。
威胁模型更偏传统：保护基础设施和租户之间的隔离。上线前的工作重点在网络配置、内部服务认证和编排层。
关键教训：
"最薄弱的层永远是你自己构建的那一层。" gVisor 和 seccomp 已经经历了远超 Agent AI 存在时间的高强度对抗检验。
模式二：人在回路的沙箱（Claude Code）¶
Claude Code 运行在用户本机，拥有文件系统、Shell 和网络访问权限，依靠开发者的技术判断力作为核心防线。 典型用户是熟悉编码环境的开发者，能够评估 Agent 的操作意图。
Claude Code 发布时要求对写入、bash 和网络操作逐一审批。审批疲劳在几周内就出现了。
团队推出了 OS 级沙箱（macOS 上用 Seatbelt，Linux 上用 bubblewrap）：读取操作放行，写入限制在工作区内，网络默认禁止。效果：权限弹窗减少 84%。运行时代码已开源。
匿名使用数据显示，资深用户的自动批准频率约为普通用户的两倍，但中途打断执行的频率也更高。
遗漏风险一：信任对话框之前的代码执行¶
2025 年中到 2026 年 1 月间，多个漏洞针对的是用户同意之前就执行的代码。 例如：仓库中的 .claude/settings.json 定义了一个 hook，会在"你信任这个文件夹吗？"提示出现之前的启动阶段就执行。
修复："将项目本地配置的解析和执行推迟到用户接受信任提示之后。"
遗漏风险二：用户本身成为注入向量¶
2026 年 2 月的内部红队演练中，研究员通过钓鱼诱使员工以恶意 prompt 启动 Claude Code——在 25 次重试中 Claude 完成了 24 次数据窃取。
该 prompt 伪装成日常协作消息，要求 Claude 读取 ~/.aws/credentials，编码内容后 POST 到外部。这是直接的 prompt 注入——指令来自用户本身。模型层防御锚定于用户意图，因此分类器看不到任何异常。
"在这种情况下唯一能守住的防线是环境——具体来说是出口控制，无论意图如何都阻断 POST 请求。"
当这个有效 prompt 在内部 Slack 中被分享后，有人指出内部 Agent 也在读 Slack——"payload 现在是环境中的噪音了。" 团队添加了一个 canary string。
"在 Agent 阅读一切的世界里，调查工具本身也是攻击面。"
模式三：本地 VM（Claude Cowork）¶
Claude Cowork 面向桌面知识工作者，使用完整虚拟机进行隔离——用户不需要具备 bash 能力来判断操作安全性。
第一版使用平台原生虚拟化（macOS 上的 Apple Virtualization framework，Windows 上的 HCS）运行一个完整 VM。VM 拥有独立的 Linux 内核、文件系统和进程表。仅挂载用户选定的工作区和 .claude 文件夹。凭据留在宿主机的 keychain 中。
在全 VM 模式下，Agent 循环在 guest 内运行，完全不知道自己被隔离——"没有外部进程持有逃逸密钥，因此没有任何组件有权限授予例外。"
Claude Cowork VM 的六大隔离机制。其中两个在 guest 内核之外执行，即使 Agent 在 VM 内获得 root 权限也不会失效。
架构演进¶
Agent 循环从 VM 内部移至宿主机，代码执行仍留在 VM 中——因为 VM 启动失败会导致 Cowork 完全不可用。 本地 MCP 服务器也移到外部，以便审计和支持与本地进程的交互。
Agent 循环在 VM 内部意味着 VM 故障会导致 Cowork 不可用。宿主模式更可靠，因为即使 VM 崩溃 Agent 仍能响应。
文件系统控制¶
不同的文件挂载模式（只读、读写、读写但不可删除）细粒度地控制风险。"符号链接解析必须在路径验证之前完成，而不是之后"——以防止逃逸。企业管理员可以通过 MDM 设置中的挂载路径白名单来管控。
遗漏风险三：通过白名单域名进行数据窃取¶
第三方报告揭示：工作区中的恶意文件携带隐藏指令和攻击者控制的 API key，Claude 用攻击者的 key 调用了 Anthropic Files API——出口代理看到 api.anthropic.com 就放行了。
"白名单上任何域名可达的每一个功能，现在都是攻击面。"
修复方案：在 VM 内部署防御性中间人代理，拦截发往 API 的流量，仅放行携带 VM 本会话 token 的请求。攻击者嵌入的 key 会被拒绝。
上：发往 api.anthropic.com 的流量被放行，导致数据泄露。下：通过中间人代理拦截流量后的修复方案。
遗漏风险四：VM 隔离同时阻挡了 EDR¶
保护 Claude 的隔离屏障同样把宿主机的端点检测与响应（EDR）挡在了外面。 当前缓解方案：基于拉取的 OTLP 导出用于事后事件日志检索，但这不是实时监控。
三种模式对比¶
| 临时容器（claude.ai） | 人在回路沙箱（Claude Code） | 封闭 VM（Claude Cowork） | |
|---|---|---|---|
| 隔离开销 | 容器启动 | 低延迟原生沙箱 | 完整 VM 启动 |
| 对用户的依赖 | 无 | 需要理解 bash | 无 |
| 爆炸半径 | 服务端容器（gVisor + 主机基础设施边界保护） | 本地工作区 | 挂载的工作区（vsock + hypervisor 边界保护） |
信任 Agent 读取的内容¶
远程 vs 本地的区别至关重要：本地安装的工具可审计，而远程工具在审批后仍可能改变行为。 Anthropic 的 connector directory 提供持续审查。
工具输出也是攻击面，即使工具本身是可信的。 Web 页面需要输入扫描，同样网络工具的返回结果也需要同等严格的审查。在 Claude Code 和 Claude Cowork 中，工具调用经过代理路由，代理执行网络/文件策略并在结果进入模型上下文之前进行检查。
前瞻性挑战¶
持久化记忆投毒¶
更多的 Agent 上下文跨会话持久化——产品记忆、CLAUDE.md 文件、工作区、状态目录——注入一旦落入持久存储就会在每次启动时重新加载。 这是后渗透意义上的新型持久化机制。
多 Agent 信任升级¶
子 Agent 可以隔离不可信内容，但如果其输出被视为比原始工具结果更高信任级别，就引入了新的攻击向量。
Agent 身份¶
Agent 应该拥有自己的主体身份，还是继承用户权限？ Cowork 使用每会话降权 token；跨平台的完整答案可能融合两种方式。
外部参考：
- NIST AI Agent 身份与授权项目
- 澳大利亚 ACSC 联合 CISA 和英国 NCSC 的六机构 Agent AI 采用指南
- ISO/IEC 42001 AI 管理标准
核心原则¶
-
优先在环境层设计隔离，再在模型层引导行为。 员工钓鱼和白名单域名泄露事件都是出口问题——模型层在这些场景中帮不上忙。
-
让隔离强度匹配用户的监督能力。 能读懂 bash 的开发者和无法判断命令安全性的知识工作者，面对的是完全不同的威胁模型。
-
警惕自建组件。 "久经考验的 hypervisor、系统调用过滤器和容器运行时经历了远超你自建组件的对抗考验。"
"Agent 或许是一个新的软件类别，但它们的系统级交互并不新——读文件、开 socket、启进程——这使得用成熟工具进行隔离成为一条可行的防线。"
脚注¶
- Claude Code auto mode 将命令审批委托给基于模型的分类器；约 0.4% 的良性命令被误拦，约 17% 的过度行为未被拦截——这是纵深防御中的一层，而非沙箱的替代品。