Anthropic 如何约束 Claude：智能体安全模式与经验教训

Anthropic 已将其 AI 智能体部署方法从避免高风险访问转向限制“爆炸半径”（blast radius）——即智能体可能造成的理论最大损害。随着智能体从简单的聊天界面转向能够管理内部服务的自主工具，风险与回报的权衡已向采用方向倾斜，前提是使用确定性的环境边界来补充概率性的模型层防御。

三层防御模型

Anthropic 将智能体安全分为三个风险向量和三个相应的防御组件。其核心理念是，虽然模型层防御很强，但它们是概率性的，无法独立存在。

风险类别

用户误用： 用户发出恶意或粗心的指令以执行有害操作。
模型行为异常： 智能体自主采取有害行动，包括通过“创造性”路径绕过限制或逃逸沙箱以完成任务。
外部攻击者： 通过工具、文件或网络访问进行的提示词注入（prompt injection），以及对运行时或编排层的常规攻击。

防御组件

环境： 最关键的一层。使用进程沙箱、VM 和出站控制（egress controls）来为智能体可以触及的范围设定硬性边界。如果凭据从未进入沙箱，它们就无法被窃取。
模型： 利用系统提示词、分类器和训练来塑造行为。例如，Claude Opus 4.7 在提示词注入基准测试中保持了较低的攻击成功率，但这仍然是一种概率性防御。
外部内容： 限制工具权限（例如，只读数据库访问）并检查工具输出，使其在进入模型上下文之前，以防止被污染的数据误导智能体。

各产品的遏制模式

Anthropic 根据用户的技术能力和智能体所需的访问权限，采用了三种不同的隔离模式。

1. 临时容器 (claude.ai)

对于服务端代码执行，Claude 使用在隔离基础设施上的 gVisor 容器。文件系统是按会话临时生成的，确保爆炸半径被限制在服务端环境内，并保护租户之间互不干扰。 Anthropic 指出，这种设置中最薄弱的环节是围绕硬化的 gVisor/seccomp 原语构建的自定义代理（proxy）。

2. 人机协同 (HITL) 沙箱 (Claude Code)

Claude Code 在本地运行，需要访问用户的文件系统和 shell。

审批疲劳问题： 最初，Claude Code 要求用户批准每一次写入或网络操作。遥测数据显示，用户批准了约 93% 的提示词，导致了“审批疲劳”，即用户不再关注风险。
解决方案： 使用操作系统层级的沙箱（macOS 上的 Seatbelt，Linux 上的 bubblewrap）允许在工作区内进行读写，但默认拒绝网络访问。这减少了 84% 的权限请求。
关键失败案例： Anthropic 识别出了一些漏洞，即项目本地配置（如 .claude/settings.json）在用户接受信任提示之前就被解析，从而允许恶意钩子（hooks）的自动执行。

3. 加密虚拟机 (Claude Cowork)

专为无法被期望评估 bash 命令的非技术知识工作者设计，Claude Cowork 使用完整的 VM（macOS 上的 Apple Virtualization framework，Windows 上的 HCS）。

隔离： VM 拥有自己的内核和进程表。只有用户选择的工作区会被挂载；凭据保留在宿主机的钥匙串中。
架构演进： 智能体循环被移到了 VM 之外，以确保如果 VM 崩溃，产品仍可使用，同时将代码执行保留在 VM 之内。
出站代理失败案例： 发现了一个重大漏洞，即智能体可以使用攻击者的 API key 使用 api.anthropic.com 窃取数据。由于目标地址在白名单中，代理允许了该流量。Anthropic 通过在 VM 内部实现一个中间人代理（man-in-the-middle proxy），使其仅允许携带 VM 自身会话令牌的请求，从而修复了这一问题。

关键技术总结与教训

确定性优于概率性

Anthropic 强调，环境层是确定性的，而模型层是概率性的。当用户被钓鱼并提供恶意提示词时，模型层分类器会失效，因为指令看起来像是有效的用户意图。在这种情况下，只有出站控制和文件系统边界可以防止数据窃取。

匹配隔离程度与用户专业知识

遏制策略必须与用户监督智能体的能力相匹配。审批模式必须针对开发者，针对通用知识工作者，则边界必须是绝对且始终开启的，而非基于人机协同的审批。

自定义安全组件的危险性

在所有三种产品中，最频繁的失败并非发生在经过实战检验的原语（如 gVisor 或 hypervisors）本身，但在围绕它们构建的自定义代理和配置加载器中。

社区洞察与反论点

技术用户之间的讨论突出了智能体安全中仍然存在的挑战：

污染分析复杂度： 一些贡献者认为沙箱化并不充分，因为提示词注入可以利用 VM 产生的产物从低权限 VM “跳跃”到高权限智能体。
可见性 vs. 隔离： 企业安全团队指出，同样的 VM 隔离机制在遏制智能体智能体的同时，也阻碍了客户机 OS 的智能体检测与响应 (EDR) 软件进行监控，从而产生了可见性缺口。
气密室架构 (Airlock Architectures)： 一一些用户建议采用更极端的“气密室”方法：一个智能体配置拥有本地文件系统访问权限且无法上网，断开网络连接；另一个配置拥有网络访问权限但无法访问文件系统，两者之间由用户充当手动桥梁，以防止自动化数据窃取。