获取开发者通讯
产品更新、操作指南、社区聚焦等。每月发送至你的收件箱。
十二个月前，我们还会毫不犹豫地拒绝授予 Claude 足以关闭 Anthropic 内部服务的访问权限。如今，这种级别的访问权限已是常态，Anthropic 的开发者也因此提高了生产力。这类部署的风险由两部分组成：失败的可能性有多大，以及一次失败能造成多大的损害。在安全防护和模型训练方面的进展稳步降低了前者；而后者——理论上的爆炸半径——只会随着能力和访问权限的扩展而增大。然而，当智能体能够完成曾经需要一个人甚至一个团队才能完成的工作时，不部署的代价会变得足够大，以至于只要产品能够做到安全，风险与回报的权衡就会大幅倾向于采用。工程问题于是变成了如何限制爆炸半径。
大致有两种方法可以做到这一点。
第一种是通过人在回路来监督智能体的行为。Claude Code 此前通过在每一轮询问用户许可，来防止智能体采取非预期行动。理论上这行得通，但我们发现这种方法并不可靠。我们的遥测数据显示，用户批准了大约 93% 的权限提示。用户看到的批准请求越多，他们对每一个请求投入的注意力就越少，久而久之在监督上就变得远不那么尽职。我们最近构建了 Claude Code 自动模式，它自动化了更安全的批准流程，以减少这种批准疲劳。尽管如此，漏洞依然存在——任何概率性防御都有非零的漏检率。1
第二种限制爆炸半径的方法——也是本文大部分内容的重点——是隔离。我们不是监督智能体做什么，而是通过沙箱、虚拟机和出口控制等手段强制执行访问边界，来监督它能够做什么。这正是 Anthropic 工程团队投入最多精力的地方，也是许多最令人意外的安全故障发生的地方。
在过去两年里，我们发布了三款主要的智能体产品：claude.ai、Claude Code 和 Claude Cowork。每一款都服务于不同的受众，需要不同的隔离架构。本文分享哪些做法经受住了考验，哪些出了问题，以及我们在此过程中对智能体安全的认识。
智能体面临的安全风险分为三类：
用户误用：用户——无论是出于恶意还是疏忽——指示智能体去做有害的事情。这包括从要求智能体绕过他们觉得烦人的检查，到运行他们并不理解的破坏性命令，再到明确指定要造成伤害。
模型行为不当：智能体采取了没有人要求的有害行动。随着我们模型的改进，它们在大多数行为评估上变得更加对齐，但这并不意味着风险必然缩小。能力较弱的模型更可能误读情况并犯下明显的错误。能力更强的模型犯的错误更少，但它们也更擅长找到通往目标的意外路径，往往是通过绕开没有人想到要写下来的限制。
在 Anthropic，我们见过 Claude 模型“乐于助人地”逃出沙箱以完成任务、检查 git 历史以找到编码测试的答案，以及自发识别出自己正在运行的基准测试，从而解密其答案密钥。每个模型都带来一组新的能力，而这些能力有时会以意想不到的方式被使用。
外部攻击者：智能体通过工具、文件或网络访问等外部途径受到攻击。这一类别既包括提示注入，也包括对智能体运行时、编排层或代理的常规攻击。
在构建遏制与防御系统时，我们对三个主要组件应用防御：
智能体运行的环境。我们通过进程沙箱、虚拟机、文件系统边界和出口控制来限制智能体可以在何处以及如何行动。目标是给智能体能够触及的范围设定硬边界。例如，如果凭据从未进入沙箱，它们就无法被窃取，无论原因来自用户、模型找到了一条“有创意”的路径，还是攻击者。
严密的边界也意味着你可以放松监督。Claude Code 的参考 devcontainer 正是为了让智能体能够无人值守运行，而无需逐项操作批准。
智能体所咨询的模型。这里的机制包括系统提示、分类器、探针和训练修改。由于模型具有概率性，这些机制只塑造智能体倾向于做什么，而不是它在理论上能够做什么。
这些防御很强。在 Gray Swan 的 Agent Red Teaming 基准测试中——该测试衡量对提示注入的易感性——Claude Opus 4.7 将单次尝试的攻击成功率控制在约 0.1%，在 100 次自适应尝试后约为 5–6%。Claude Code 自动模式在过度积极行为执行之前捕获约 83%。然而，即使拥有同类最佳的防御，模型层的保护也永远不会 100% 有效，这就是为什么它不能单独存在。
智能体能够触及的外部内容。MCP 服务器、第三方插件和网络搜索工具都会将来自你无法控制的来源的内容送入智能体的上下文。经过审计的连接器并不等同于经过审计的数据——例如，GitHub 连接器尽管通过了恶意软件检查，仍可能将一份被投毒的 README 直接加载到模型上下文中。细粒度地限制工具权限有助于限制影响范围。例如，一个只有只读数据库访问权限的智能体，可以比一个会写入生产数据库的智能体被更广泛地部署。
防御应当相互重叠、相互补充。当环境防御不可用时，模型层必须补上缺口（这正是 Claude Code 的自动模式的设计目的）。在本地，环境和模型防御可以防范恶意工具输出，但也可以通过限制工具的能力和访问权限，在链条更高层添加防御。
聚焦于环境层，我们描述了三种隔离模式，以及它们如何针对每个 Claude 平台——claude.ai、Claude Code 和 Cowork——进行定制。我们是在找到智能体所需能力与用户所需干预程度之间的平衡后，才逐步得出每种设计的。
尽管 claude.ai 最为人熟知的是聊天界面，但它也能编写和运行代码、生成文件并调用连接器。当 Claude 在 claude.ai 内部运行代码时，它是在隔离基础设施上的 gVisor 容器中运行的。智能体完全在服务器端；本地机器上不运行任何代码，文件系统是临时的（按会话）。爆炸半径最小，但 Claude 能做的事情的上限也同样如此——没有持久工作区，也无法访问用户的文件系统。
这也使得 claude.ai 受制于一种更传统的威胁模型。我们不是在保护用户机器免受智能体侵害；我们是在保护自己的基础设施，以及每个租户免受彼此侵害。我们为 claude.ai 所做的发布前工作，主要是传统安全工作，如网络配置、内部服务认证和编排。
这项工作再次印证了安全领域最古老的教训：最薄弱的层是你自己构建的那一层。gVisor 和 seccomp 针对资源充足的对手进行加固的时间，远比智能体 AI 存在的时间更长，因此审查工作集中在我们围绕它们构建的较新组件上。我们稍后会回到这一点，因为我们自定义的代理也是在我们最具后果的事件中出问题的部分。
Claude Code 在用户机器上运行，并可访问其文件系统、shell 和网络。没有这些，编码智能体的实用性就会受限，因此必须找到一种安全授予这些访问权限的方法。
一种方法是依赖人在回路中。这对 Claude Code 来说之所以是一个可行的解决方案，是因为普通用户是熟悉编码环境的开发者：他们能读懂 bash，明白 rm -rf 会做什么，而且他们每周已经多次从不受信任的来源运行 npm install。所有这些都意味着，当“允许此操作”对话框弹出时，他们极有可能具备准确评估智能体试图做什么以及其中风险的专业知识。鉴于此，Claude Code 发布时采用了尽可能简单的防御措施：允许读取，写入、bash 和网络访问需要批准。
然而，如前所述，审批疲劳在数周内就显现出来。 讽刺的是，这意味着一个原本旨在提供监督的功能，可以说可能产生了相反的效果——一些用户可能干脆不再关注。作为缓解轻率审批的第一步，我们发布了一个操作系统级沙箱（macOS 上的 Seatbelt，Linux 上的 bubblewrap），它强化了边界：允许读取，允许在工作区内写入，但默认拒绝网络访问。在沙箱内，智能体基本可以不受干扰地运行。结果是权限提示减少了 84%，并且我们将运行时开源，因此该边界是可审计的。
我们的匿名使用数据还显示，经验丰富的用户自动批准的次数大约是新用户的两倍，但他们也更频繁地在执行中途打断智能体。经验丰富的用户不是对每个步骤都设卡，而是更倾向于只在智能体偏离轨道时才进行监督。虽然这可能是人们偏好与智能体协作方式的一种自然演变，但这种方式同样容易出错，需要用户具备足够的技术能力和注意力，才能首先注意到偏离。随着模型能力提升，智能体开始编写越来越复杂的 bash，注意到此类偏离变得更加困难。而且随着用户转向多智能体系统，这种方法也更不可能成为一种有效的监督策略。
在 2025 年年中至 2026 年 1 月期间，我们通过负责任披露计划收到了关于 Claude Code 漏洞的报告。其中三个漏洞针对的是在用户同意任何内容之前执行的代码。要理解这怎么可能，请考虑最直接的情况：一名开发者克隆一个仓库来审查拉取请求，而该仓库包含一个定义了钩子的 .claude/settings.json。由于 Claude Code 在启动期间读取项目设置——在呈现标准的“你信任此文件夹吗？”提示之前——攻击者编写并提交的钩子会自动执行。其余案例在结构上类似，即来自尚未受信任目录的输入在信任边界建立之前就被解析了。
每个案例的修复方式都相同：将项目本地配置的解析和执行推迟到用户接受信任提示之后。如果你正在构建类似的东西，请像对待来自互联网的任何入站请求一样对待项目打开、配置加载和 localhost 监听器。它们不应该仅仅因为感觉是本地性的、并且在用户同意之前到达就被隐式信任。
2026 年 2 月，在一次受控的内部红队演练中，一名研究人员成功通过网络钓鱼诱使一名员工使用恶意提示启动 Claude Code。这封钓鱼邮件看起来像普通的协作——一封“你能帮我运行一下这个吗？”的电子邮件，附有一个可直接粘贴的提示——而提示本身读起来像是常规任务说明。但在设置步骤的某处，它温和地要求 Claude 读取 ~/.aws/credentials，对内容进行编码，并将其 POST 到外部端点。在该提示的 25 次重试中，Claude 完成了 24 次数据外泄。
这是一次直接提示注入——攻击者的指令是通过用户到达的，而不是通过工具输出或获取的内容。我们的模型层防御以用户意图为锚点——当用户本人就是输入指令的人时，分类器没有什么异常可捕捉。一个人类承包商拿到同样的脚本也会做同样的事。
在这种情况下唯一站得住脚的防御是环境，具体来说，是无论意图如何都阻止该 POST 的出站控制，以及从一开始就让 ~/.aws 无法触及的文件系统边界。
（当我们在内部 Slack 中分享这个可用的提示以供讨论时，有人指出一些内部智能体会读取 Slack。这个载荷现在成了环境中的一部分。我们在该话题串中加入了一个金丝雀字符串，这样如果有任何东西拾取了它，我们就能注意到。在一个智能体读取一切的世界里，调查工具本身也是攻击面。）
Claude Cowork 运行在用户的桌面上，可访问用户选定的工作区文件夹。由于该平台是为通用知识工作而非软件工程构建的，普通用户精通 bash 的可能性要低得多。
因此，人在环中的沙箱策略可能无法迁移；不应指望非技术型知识工作者去判断诸如 find . -name "*.tmp" -exec rm {} ; 这样的 bash 咒语。当批准一项例外需要普通用户并不具备的专业知识时，管理员应设定一条绝对且始终生效的边界。
为实现这一点，我们的第一版 Claude Cowork 运行在一个完整的虚拟机内，使用平台的供应商虚拟机监控程序（macOS 上为 Apple 的 Virtualization framework，Windows 上为 HCS）。该虚拟机有自己的 Linux 内核、自己的文件系统和自己独立的进程表。用户选定的工作区和 .claude 文件夹被挂载；主机上的其他内容均不可见。凭据保留在主机的钥匙串中，绝不进入客户机。这一设计防范了 Claude 在某个时刻以不一致方式行事的可能性。一个被攻陷的 Claude 仍可能破坏工作区文件夹内的内容，因此该架构的设计确保那是它唯一能触及的东西（直到用户添加连接器），并且用户控制那里挂载了什么。
在最初的架构中——我们称之为全虚拟机模式——智能体循环本身运行在客户机内，因此 Claude 以普通 Linux 用户身份执行，并不知道自己处于沙箱中。与之相比，在 Claude Code 中，一个特权进程位于沙箱之外，逐条命令决定是否强制执行沙箱；一个有说服力的注入提示或一次疲惫的批准点击就能让该进程运行未经沙箱隔离的东西。而在这里，没有外部进程持有逃生舱门的钥匙，因此也没有任何组件有权授予例外。
然而，我们很快意识到，在全虚拟机模式下运行整个智能体会带来实际问题：虚拟机启动期间的任何失败都会使 Cowork 无法使用。将智能体循环移到虚拟机之外，同时将代码执行保留在虚拟机之内，使 Claude 仍能回应用户并帮助调试问题，而不是在出错时卡死。这一改动对安全的影响极小，因为虚拟机仍对智能体执行的代码强制执行文件系统和网络控制。
另外，我们还将本地 MCP 服务器移出了虚拟机。在虚拟机内运行它们使其更难审计，在虚拟机更新时会产生脆弱的依赖问题，并且不支持需要与本地进程（如数据库）交互的 MCP——这类服务器无论如何都必须在宿主机上运行。这一变更使 Claude Cowork 与 Claude Desktop 中本地 MCP 服务器的现有工作方式保持一致：将它们视为用户可能选择安装的任何软件，并交由管理员决定启用哪些本地 MCP（如果有的话）。远程 MCP 服务器不受影响，因为它们不在用户机器上运行。
文件系统控制是另一个重要的架构选择。Claude 需要能够访问宿主机上的部分文件才能发挥作用，但我们希望将影响范围降至最低，并向用户透明地展示本地文件访问情况。我们发现，提供不同的文件挂载模式有助于细粒度地控制风险；Claude Cowork 提供只读、读写和读写不删除三种模式。这里一个潜在的陷阱是，符号链接解析必须在路径验证之前进行，而不是之后，否则已授权文件夹内的符号链接可能指向外部并逃逸。对于企业客户，我们允许管理员通过 MDM 设置中的挂载路径允许列表来控制这一点。
一个通过已批准域名进行数据外泄的清晰案例来自第三方披露。Claude Cowork 的出站允许列表正确地将流量放行至 api.anthropic.com——该产品若不调用我们自己的 API 就无法运行。在此案例中，放置在用户已挂载工作区中的恶意文件携带了隐藏指令以及由攻击者控制的 API 密钥。Claude 按照指令读取了工作区中的其他文件，并使用攻击者的密钥调用了 Anthropic 的 Files API。出站代理检查了目标地址，看到 api.anthropic.com，便放行了。文件被上传到攻击者的 Anthropic 账户。沙箱运行得完美无缺，然而数据还是被外泄了。
此前，我们将允许列表概念化为一种目标过滤器，即告诉 Claude*这些域名可以通信。*但将其概念化为一种能力授予可能更为恰当。通过允许列表中任何域名可达的每个功能现在都成为了攻击面。允许 api.anthropic.com 就意味着允许向任意 Anthropic 账户上传文件。
我们通过在虚拟机内部使用一个防御性中间人代理来拦截发往我们 API 的流量，从而修复了这个问题。它只放行携带虚拟机自身预置会话令牌的请求；攻击者嵌入的密钥会被代理拒绝。它还会阻止那些会启用服务器端抓取的请求头。该代理位于虚拟机内部而非我们的服务器上，因为只有虚拟机知道来源——从服务器的角度来看，一个 Cowork 请求与任何其他 API 客户端无法区分。
这也是“你自己构建的软件往往是最薄弱的”这一原则的第二个实例。我们各产品中的 hypervisor、seccomp 和 gVisor 一直很可靠。我们自定义的允许列表代理才是失败的那一环。
在评估 Claude Cowork 时，企业安全团队问道：“为什么我们的 EDR 无法看到内部？”答案是，将 Claude 隔离在内的同一隔离机制也将基于主机的端点检测与响应挡在了外面。从 EDR 的角度来看，Claude Cowork 是一个不透明的 hypervisor 进程。它无法检查客户机内部。
隔离会降低可见性，而对于合规态势依赖于端点可见性的团队来说，不透明性是个问题。我们目前的缓解措施是使用基于拉取的 OTLP 导出，让管理员可以在事后检索事件日志，但这与实时监控并不相同。如果你正在构建类似的东西，请尽早为这场对话预留预算。
| 环境 | 临时容器 ( |
|---|
企业经常问我们如何保护 MCP 连接。这是个好问题，但正确的问题比 MCP 本身更广泛。提供给智能体的任何外部资源同时代表两种风险：传统供应链意义上的代码执行风险，以及提示注入向量。传统的依赖审计（固定版本、验证签名、审查源代码）解决了第一个问题，但忽略了第二个。
远程与本地比看起来更重要。 本地安装的工具是可审计的。你可以阅读代码、固定版本，并知道它不会在你眼皮底下发生变化。远程工具——托管的 MCP 服务器、云连接器——在你批准之后的任何时间点都可能改变行为；你安装时的信任决策可能不再适用。我们的连接器目录通过持续审查来解决这个问题，但目录之外的任何东西都应被视为不可信。先针对假数据运行它，在一个恶意工具爆炸半径受控的环境中。
即使工具是可信的，工具输出也是攻击面。 前面提到的 GitHub README 示例正是这种情况；应用于网页的任何输入扫描都需要以同样的严谨性应用于启用网络的工具结果。尽管这会增加延迟且并非完美防御，我们倾向于实时检查：一旦被投毒的工具返回已将智能体引导至数据外泄，日志只会显示一次成功的、经授权的 API 调用。事后没有任何信号可寻。
在 Claude Code 和 Claude Cowork 中，工具调用通过代理路由，这些代理强制执行网络和文件策略，并可以在返回值进入模型上下文之前检查它们。执行检查的分类器可以是一个小型、快速的模型；它不需要是进行推理的那个。
模型和产品正在快速进步。随着它们的进步，风险也在变形和演变，我们的缓解措施必须跟上步伐以应对它们。
持久记忆投毒。 跨会话持久存在的智能体上下文份额持续增长——这包括产品记忆、CLAUDE.md 文件、挂载的工作区，以及计划任务和长期运行智能体的状态目录。落入其中任何一个的注入都会在智能体每次启动时被重新加载。随着更多智能体状态在会话结束后存活，我们受到经典后利用意义上新持久化机制的威胁。会话启动时的良好分类器将需要变得更加普遍。
多智能体信任升级。 一方面，子智能体可以隔离不可信内容，向主智能体返回结构化事实而非原始文本。另一方面，这可以被滥用：如果子智能体的输出被视为比原始工具结果更高信任，因为此类输出来自“我们”，就引入了一个新的提示注入向量。在多智能体系统中，在分配不同信任级别与变得容易受到信任升级之间存在着权衡。
Agent 身份。 Claude Cowork 对 agent 身份的回答是具体的：凭证保留在主机钥匙串中，VM 获得一个按会话缩小权限的令牌，并且该令牌可以独立于用户的令牌被撤销。然而，我们开始应对跨平台 agent 身份这一更广泛的问题。Agent 应该拥有自己的主体身份，还是应该作为用户的延伸并继承用户的权限？最终，答案可能是两者的结合。
随着 agent 能力越来越强，攻击面也在不断变化。我们所见到的故障类型很可能会在各行各业和实验室中重演。我们需要对 agent 特定的安全态势进行集体投入，从共享基准和披露规范到通用身份标准和跨供应商红队演练。本文重点关注遏制，但这只是 agent 安全图景的一部分。关于治理、可观测性以及技术栈的其余部分，请参阅 NIST 关于 AI agent 身份与授权的项目、由澳大利亚 ACSC 与 CISA 和英国 NCSC 牵头制定的关于采用 agentic AI 的六机构指南，以及 ISO/IEC 42001 这一 AI 管理标准。我们的 Glasswing 计划是其中一项贡献，但我们期待在这个关键问题上与合作伙伴和竞争对手携手合作。
简而言之，我们反复回到几条原则：
首先在环境层设计遏制，然后在模型层引导行为。 教给我们最多的两起事件——员工钓鱼和第三方允许列表泄露——都是出站（egress）案例，数据通过一条被允许的路径离开。在每一起事件中，模型层都无能为力；没有任何异常可供它捕捉。当所有概率性手段都失效时，确定性边界就是最后被触及的防线。
将隔离强度与用户的监督能力相匹配。 能读懂 bash 的开发者和读不懂的知识工作者，运行的不是同一个威胁模型。用户能否评估 agent 即将做什么，这个问题应有助于确定遏制策略，而无论朝哪个方向答错——对专家摩擦过多，对非专家信任过多——本身就是一种失败。
警惕自定义组件。 经过实战检验的虚拟机监控程序、系统调用过滤器和容器运行时，比你能构建的任何东西都经受了更多对抗性关注。在本文描述的每一次部署中，标准原语都经受住了考验，而我们围绕它们所做的工作却暴露了缺陷。
归根结底，虽然 agent 可能是一类新软件，但它们的系统级交互并非如此。它们仍然读取文件、打开套接字并生成进程；这使得使用成熟工具进行遏制成为一种至关重要的可行防御。随着 AI 的发展，部署的风险回报平衡将持续变化，但对爆炸半径设置硬性限制往往能迫使这种平衡朝正确方向发展。
作者：Max McGuinness、Mikaela Grace、Jiri De Jonghe、Jake Eaton 和 Abel Ribbink。
我们也感谢 Hanah Ho、Hasnain Lakhani、Pedram Navid、Molly Villagra、Maya Nielan、Akila Srinivasan、Travis Szucs、Sam Attard、Alfred Xing、Mohamad El Hajj、Gabby Curtis、David Dworken、Adam Jones、Amie Rotherham、Christian Ryan、Lucas Smedley、Brett Andrews 以及其他人的贡献。
特别感谢我们的安全和产品工程团队，以及那些报告 Claude 产品漏洞的个人和组织。
产品更新、操作指南、社区聚焦等。每月发送到您的收件箱。