Anthropic 近日详细阐述了 Claude 在 Web、开发者工具及桌面产品中的安全隔离架构。该公司强调，Agent 安全不能仅依赖权限确认或模型自身的防御机制，核心在于通过文件系统、网络及执行环境等基础设施，构建确定性的安全边界。文章深入分析了多起发生在信任边界和出站路径上的安全事件，并揭示了这些事件如何推动 Anthropic 优化其系统设计。
Anthropic 将 Agent 面临的风险归纳为三类：用户误用、模型自身错误行为，以及源自文件、工具或网络内容的攻击。其核心观点指出，分类器、系统提示词及模型训练虽能引导模型行为，但无法提供绝对保障。真正决定 Agent 访问权限与数据外发能力的，是运行环境施加的底层限制。
Anthropic 将 Agent 系统划分为三个层次：具有概率性的模型、执行环境，以及可能影响模型行为的外部内容。（来源：Anthropic）
Claude Code：从人工确认到系统级沙箱
以 Claude.ai 为例，其代码执行环境运行在隔离基础设施的临时 gVisor 容器中，完全隔绝用户本地文件系统。而面向开发者的 Claude Code 则直接运行于本机。初期，该系统采用逐项授权机制，每次文件写入、Shell 命令执行或网络访问均需用户确认。然而数据显示，用户最终批准了约 93% 的请求，导致人工确认的安全价值大幅稀释。
为此，Anthropic 引入操作系统级沙箱：macOS 采用 Seatbelt，Linux 采用 bubblewrap。新设计允许 Agent 在当前工作区内自由读写，但默认禁止网络访问。这一调整使权限确认弹窗数量减少了 84%，显著提升了安全性与用户体验。
配置加载逻辑的安全修正
在一次安全事件中，Anthropic 发现即在用户未确认信任项目目录前，Claude Code 已开始解析本地配置文件。某案例中，仓库内的.claude/settings.json定义了启动时自动执行的 Hook。针对此漏洞，Anthropic 重构了实现逻辑：仅在用户明确选择信任该项目后，才会解析并执行相关本地配置。
红队测试揭示授权机制局限
Anthropic 通过受控红队测试验证了单纯依赖权限确认或意图分类器的局限性。测试模拟了钓鱼攻击场景：诱导员工让 Claude Code 执行“读取 AWS 凭证并发送至外部地址”的指令。结果显示，25 次测试中有 24 次成功执行了数据外传。这表明，无论请求源自真实用户、模型误判还是恶意工具，仅靠授权机制无法阻断风险，必须依靠文件系统隔离和出站网络限制等底层机制兜底。
Claude Cowork：虚拟机隔离与代理架构演进
相比 Claude Code，面向非技术用户的 Claude Cowork 更难判断 Shell 命令安全性，因此采用了更严格的隔离机制。初始设计中，Agent 完全运行在虚拟机内，仅挂载指定工作目录，凭证存储于宿主机密钥链。后续为提升可靠性，Anthropic 将 Agent 主循环迁移至宿主机，但代码执行仍保留在虚拟机内部。
Claude Cowork 的初始全虚拟机架构，以及后续采用宿主机 Agent Loop 的架构。（来源：Anthropic）
域名白名单机制的漏洞与修复
该架构暴露出域名白名单机制的重要局限。第三方研究人员发现，恶意文件可诱导 Claude 通过已加入白名单的api.anthropic.com，利用 Files API 将工作区文件上传至攻击者账户。由于域名可信，请求顺利通过了目的地址检查。
对此，Anthropic 在虚拟机内部增设了一层代理。新代理仅接受当前会话生成的 Session Token，并拦截与服务端抓取相关的请求头，从而阻断此类攻击。这一事件表明，将域名加入白名单意味着授权访问其全部功能，而非单一接口，需警惕由此产生的横向移动风险。
域名白名单让攻击者得以通过 Anthropic Files API 实现数据外传；新的代理机制仅允许使用虚拟机会话生成的 Token 发起请求。（来源：Anthropic）
结语：基于有效监督的隔离设计
Anthropic 总结指出，Agent 的安全隔离机制应根据用户所能提供的有效监督程度进行差异化设计。真正的 Agent 安全不应仅寄希望于识别恶意意图，更关键在于通过运行环境建立严格边界，确保即便 Agent 执行了不安全操作，其造成的影响也能被限制在可控范围内。
查看英文原文：
Anthropic Details How it Contains Claude across Web, Code, and Cowork - InfoQ (https://www.infoq.com/news/2026/07/anthropic-claude-containment/)
声明：本文由 InfoQ 翻译，未经许可禁止转载。