我们如何在各产品中约束 Claude

How we contain Claude across products

• security
• sandbox
• prompt-injection
• claude-code

一句话总结#

模型层的防御是概率性的，总会漏；真正兜底的是环境层的确定性边界——凭证不进沙箱、出站流量受控、文件挂载受限，并且隔离强度要和用户的监督能力相匹配。

为什么重要#

• 一份来自一线的智能体安全复盘：不只讲架构，还讲了哪些地方真的出过问题、怎么修。
• 把威胁分为三类、防御分为三个组件，提供了一个清晰的思考框架。
• 几个反直觉的教训：白名单域名其实是“能力授予”；自己写的组件最脆弱；用户本人也可能是注入的载体；隔离会降低可见性。
• 把第 21 篇（沙箱）和第 22 篇（auto 模式）放进了更大的纵深防御图景中。

核心概念（中英对照）#

方法 / 步骤#

1. 风险框架：给破坏范围设上限#

• 风险 = 失败的可能性 × 失败的破坏力。防护和训练在降低前者，但随着能力和权限扩大，理论上的破坏范围只会增大；同时，不部署的代价也越来越高。原文提到，Claude Mythos Preview 因破坏范围过大，在 2026 年 4 月被判定不宜发布。
• 两条路：
  1. 人在回路监督：遥测显示用户同意约 93% 的权限请求，看得越多越不仔细；auto 模式能缓解，但任何概率性防御都有非零漏报率（脚注：auto 模式约 0.4% 误报、约 17% 的过度热心动作会漏过，它是沙箱内纵深防御的一层，而不是沙箱的替代品）。
  2. 约束：通过沙箱、虚拟机、出站控制强制访问边界——本文的重点，也是出现最多意外安全故障的地方。

2. 三类风险 × 三个防御组件#

防御要相互重叠：没有环境层防御时，由模型层兜底（这正是 auto 模式的定位）。

3. 三种约束模式#

模式 1 要点：上线前的工作以网络配置、内部服务认证、编排等传统安全工作为主；最老的教训——最弱的一层是你自己造的那层，所以审查精力放在 gVisor、seccomp 周围的自研组件上。

模式 2 要点：

• 开发者熟悉 rm -rf，每周都会从不可信来源 npm install，有能力评估审批弹窗，所以最初的防御是：读放行，写 / bash / 网络需要审批。
• 几周内就出现审批疲劳 → 推出操作系统级沙箱（macOS Seatbelt、Linux bubblewrap）：读放行、工作区内写放行、网络默认拒绝；权限弹窗减少 84%；运行时开源以便审计。
• 匿名使用数据：老用户自动批准的比例约是新用户的两倍，但也更常中途打断智能体——从逐步把关转向“跑偏时才介入”。这同样不可靠：bash 越来越复杂、转向多智能体后，人更难察觉偏离。

模式 3 要点：

• 知识工作者不应被要求判断 find ... -exec rm 这类命令；当批准例外需要用户不具备的专业知识时，管理员应设置绝对的、始终开启的边界。
• 凭证留在宿主机的钥匙串中，从不进入虚拟机。
• 最初是“全虚拟机模式”：智能体循环本身在虚拟机里，以普通 Linux 用户身份运行，不知道自己在沙箱中，外面没有掌握“逃生钥匙”的特权进程（对比 Claude Code：沙箱外有一个特权进程逐条决定是否强制沙箱，有说服力的注入或疲劳的点击可能让它放行）。
• 后来改为“宿主模式”：智能体循环移到虚拟机外，代码执行仍在虚拟机内——虚拟机启动失败时 Claude 仍能回应并帮忙排错；安全影响很小，因为虚拟机仍对智能体执行的代码施加文件和网络控制。本地 MCP 服务器也移出虚拟机，与 Claude Desktop 一致，由管理员决定启用哪些。
• 原文图示列出 Cowork 虚拟机的六种主要隔离机制：两种在客户机内核之外强制执行（即使智能体在虚拟机内拿到 root 也仍然有效），四种在客户机内执行，刻意保持精简。
• 文件挂载提供只读、读写、读写但不可删除三种模式；符号链接解析必须在路径校验之前完成，否则授权文件夹中的符号链接可以指向外部逃逸；企业可以通过 MDM 设置挂载路径白名单。

4. 真实的失误与修复#

5. 信任智能体读到的内容#

• 任何提供给智能体的外部资源都同时带来两种风险：代码执行风险（传统供应链意义上）和提示注入载体。锁定版本、校验签名、审查源码只能解决前者。
• 远程与本地的差别比看起来大：本地工具可以审计、可以锁版本；远程工具（托管 MCP、云连接器）在你批准之后随时可能改变行为。连接器目录有持续审查，目录之外的应视为不可信，先在破坏范围受控的环境中用假数据试运行。
• 即使工具可信，工具输出也是攻击面：对网页做的输入扫描，对联网工具的返回结果也要同样严格。原文倾向于实时检查，因为一旦被投毒的返回值诱导智能体外泄，日志里只是一次成功的、经过授权的 API 调用，事后找不到信号。检查用的分类器可以是小而快的模型。

6. 展望#

• 持久记忆投毒：产品记忆、CLAUDE.md、挂载的工作区、定时和长期运行智能体的状态目录——注入一旦落进去，每次启动都会被重新加载。会话启动时的分类器会越来越必要。
• 多智能体信任升级：子智能体可以隔离不可信内容、只向上返回结构化事实；但如果因为“是自己人产出的”就给予更高信任，就会成为新的注入路径。
• 智能体身份：Cowork 的做法是凭证留在宿主机钥匙串，虚拟机获得按会话、范围收窄、可以独立吊销的令牌；更大的问题是智能体应该拥有自己的主体身份，还是作为用户的延伸继承用户权限，答案可能是两者结合。
• 呼吁行业共同投入：共享基准、披露规范、通用身份标准、跨厂商红队（并列举了 NIST、六国机构联合指南、ISO/IEC 42001 等）。

7. 三条原则#

1. 先在环境层设计约束，再在模型层引导行为。 员工被钓鱼和白名单外泄两起事件都是经由允许的路径出站，模型层无能为力。
2. 隔离强度与用户的监督能力相匹配。 对专家摩擦过大、对非专家信任过多，都是失败。
3. 警惕自研组件。 成熟的 hypervisor、系统调用过滤器和容器运行时一直守得住，暴露问题的是自己围绕它们写的东西。

图解#

图 1：三类风险、三个防御组件#

flowchart LR
    subgraph R["风险来源"]
        R1[用户滥用]
        R2[模型失当行为]
        R3[外部攻击者]
    end
    subgraph D["防御组件"]
        D1["环境<br/>沙箱 / 虚拟机 / 文件边界 / 出站控制<br/>（确定性硬边界）"]
        D2["模型<br/>系统提示 / 分类器 / 探针 / 训练<br/>（概率性）"]
        D3["外部内容<br/>MCP / 插件 / 搜索<br/>（限制工具权限、检查返回值）"]
    end
    R1 --> D1
    R2 --> D1
    R3 --> D1
    R1 --> D2
    R2 --> D2
    R3 --> D2
    R3 --> D3

图 2：按用户的监督能力选择隔离强度#

flowchart TD
    Q1{智能体需要访问用户本地资源吗？}
    Q1 -- 否 --> P1["临时容器（claude.ai）<br/>服务端 gVisor，按会话的临时文件系统"]
    Q1 -- 是 --> Q2{用户能看懂并评估 bash 命令吗？}
    Q2 -- 能（开发者） --> P2["人在回路沙箱（Claude Code）<br/>工作区可写、网络默认拒绝、越界才审批"]
    Q2 -- 不能（知识工作者） --> P3["本地虚拟机（Cowork）<br/>绝对、始终开启的边界<br/>凭证留在宿主机"]

图 3：经由已批准域名外泄，以及修复#

sequenceDiagram
    participant F as 工作区中的恶意文件
    participant C as Claude（虚拟机内）
    participant M as 虚拟机内的防御性代理（修复后）
    participant E as 出站白名单
    participant A as api.anthropic.com
    F->>C: 隐藏指令 + 攻击者的 API 密钥
    C->>M: 用攻击者密钥上传工作区文件
    alt 修复前（没有该代理）
        M->>E: 目的地是 api.anthropic.com
        E->>A: 放行 → 文件进入攻击者账户
    else 修复后
        M-->>C: 不是本虚拟机的会话令牌 → 拒绝
    end

图解：修复前，带着攻击者 API 密钥的上传请求发往已批准的 api.anthropic.com，会被出站白名单放行；修复后，虚拟机内的防御性代理检查令牌，不是本虚拟机会话令牌的请求直接拒绝。

图 4：Cowork 架构从全虚拟机模式到宿主模式#

flowchart LR
    subgraph V1["全虚拟机模式"]
        direction TB
        a1["虚拟机：智能体循环 + 代码执行 + 本地 MCP"]
        a2["问题：虚拟机启动失败时整个产品不可用"]
    end
    subgraph V2["宿主模式"]
        direction TB
        b1["宿主机：智能体循环、本地 MCP（由管理员管控）、钥匙串中的凭证"]
        b2["虚拟机：代码执行<br/>仍施加文件与网络控制"]
        b1 --> b2
    end
    V1 ==> V2

关键原话#

“The deterministic boundary is what gets hit when everything probabilistic misses.” —— 当所有概率性的防御都失手时，最终被撞上的是那条确定性的边界。

“Allowing api.anthropic.com meant allowing file uploads to arbitrary Anthropic accounts.” —— 放行 api.anthropic.com，就意味着允许把文件上传到任意 Anthropic 账户。

实践建议#

• 先问“最坏情况下它能碰到什么”，再问“它通常会做什么”；先设计环境边界，再加模型层防御。
• 凭证不要进入智能体执行代码的环境；用按会话、范围收窄、可以独立吊销的令牌。
• 把出站白名单中的每个域名当作一项能力授予来审视：这个域名下有哪些可能被滥用的功能（上传、服务端抓取等）？
• 把打开项目、加载配置、本地监听端口都当作不可信的入站请求，在用户确认信任之前不要解析和执行。
• 文件挂载提供只读 / 不可删除等模式，并且先解析符号链接、再校验路径。
• 对联网工具的返回值做实时注入检查，可以用小而快的分类器。
• 远程 MCP / 连接器先用假数据、在受控环境中试运行。
• 面向非技术用户的产品不要依赖用户审批命令，而要用始终开启的硬边界。
• 尽早与企业安全团队讨论可见性（EDR、日志导出）问题。
• 优先使用成熟的隔离原语，对自己写的代理、白名单逻辑投入最多审查。
• 笔者补充：CLAUDE.md、记忆文件等跨会话持久的内容也要纳入审查范围，它们是新的“持久化”落点。

延伸阅读#

站内笔记

• 第 21 篇：Claude Code 沙箱
• 第 22 篇：Claude Code auto 模式
• 第 20 篇：Managed Agents — 凭证保险库与 MCP 代理。
• 第 14 篇：BrowseComp 中的评测意识 — 模型识别基准并解密答案的案例。
• 第 10 篇：Desktop Extensions — 本地 MCP 的分发与管理。

原文引用的资源

• 开源 sandbox-runtime
• Claude Code 参考 devcontainer
• 衡量智能体自主性（匿名使用数据）
• 连接器目录
• OTLP 协议
• NIST 关于软件与 AI 智能体身份和授权的项目
• ISO/IEC 42001
• Claude Mythos Preview 相关说明

本笔记依据 2026-10-17 抓取的在线原文撰写。原文：Anthropic,《How we contain Claude across products》。