Twelve months ago, we'd have rejected out of hand the idea of granting Claude access sufficient to take down an internal Anthropic service. Today that level of access is routine, and Anthropic developers are more productive for it. The risk of these deployments has two components: how likely a failure is, and how much damage one could do. Progress on safeguards and model training has steadily driven down the first; the second—the theoretical blast radius—only grows as capabilities and access expand. Yet as agents become capable of doing work that once required a person or even a team, the cost of not deploying grows large enough that the risk-reward calculation tips heavily toward adoption, as long as products can be made safe. The engineering question becomes how to cap the blast radius.
十二个月前，如果要给 Claude 足以搞垮 Anthropic 某个内部服务的权限，我们会不假思索地拒绝。今天，这种级别的访问已经是日常，Anthropic 的开发者也因此更高效。这类部署的风险有两个分量：出事的概率有多大，以及真出事能造成多大破坏。安全防护与模型训练的进展在持续压低前者；而后者——理论上的影响半径（blast radius）——只会随着能力和权限的扩张而变大。然而，当 Agent 已经能完成过去需要一个甚至一队人才能做的工作时，「不部署」的代价大到让风险收益的天平狠狠倒向采用——前提是产品能做得安全。于是工程问题变成了：怎么给影响半径封顶。
There are broadly two ways to do this.
大方向上有两条路。
The first is to supervise the agent's behavior via a human-in-the-loop. Claude Code previously protected against agents taking unintended actions by asking users for permission at each turn. Theoretically that works, but we've found the approach to be fallible. Our telemetry showed users approved roughly 93% of permission prompts. The more approvals a user sees, the less attention they pay to each, becoming over time much less diligent in their supervision. We recently built Claude Code auto mode, which automates safer approvals in order to reduce this approval fatigue. Still, vulnerabilities remain—any probabilistic defense has a non-zero miss rate.1
第一条路是靠人在环路（human-in-the-loop）监督 Agent 的行为。Claude Code 早先靠每一轮都向用户请求许可，来防止 Agent 做出意外动作。理论上这行得通，但我们发现它并不可靠：遥测数据显示，用户批准了大约 93% 的权限弹窗。弹窗见得越多，用户对每一个的注意力越少，天长日久监督就越来越走过场。我们最近推出的 Claude Code auto mode，就是把更安全的审批自动化，以此缓解这种审批疲劳（approval fatigue）。但漏洞依然存在——任何概率性防御都有非零的漏检率。¹
The second approach to capping the blast radius—and the focus of much of this post—is containment. Rather than supervising what the agent does, we supervise what it's able to do by enforcing access boundaries through, for example, sandboxes, virtual machines, and egress controls. This is where Anthropic engineering has devoted the most effort, and also where many of the most surprising security failures have occurred.
给影响半径封顶的第二条路——也是本文的重点——是遏制（containment）。我们不去监督 Agent「做了什么」，而是监督它「能做什么」：通过沙箱、虚拟机、出口管控（egress controls）等手段强制划出访问边界。Anthropic 的工程力气大多投在这里，而许多最让人意外的安全事故，也恰恰出在这里。
Over the past two years, we've shipped three primary agentic products: claude.ai, Claude Code, and Claude Cowork. Each serves a different audience, requiring a different containment architecture. This article shares what's held up, what's broken, and what we've learned about agent security along the way.
过去两年我们发布了三个主要的 Agent 产品：claude.ai、Claude Code 和 Claude Cowork。它们服务不同人群，需要不同的遏制架构。这篇文章分享：哪些设计经受住了考验、哪些坏过，以及我们一路上学到的 Agent 安全经验。
Three types of risk, three components of defense · 三类风险，三个防御组件
Security risks to agents fall into one of three categories:
Agent 面临的安全风险不外乎三类：
User misuse: A user—either maliciously or through carelessness—directs the agent to do something harmful. This includes everything from asking the agent to bypass a check they find annoying, to running a destructive command they don't understand, to specifying intentional harm.
用户滥用：用户出于恶意或疏忽，指使 Agent 做有害的事。轻则让 Agent 绕过某个碍事的检查，重则跑一条自己都看不懂的破坏性命令，乃至蓄意指使作恶。
Model misbehavior: The agent takes a harmful action no one asked for. As our models have improved, they have become more aligned on most behavior evaluations, but this doesn't mean risk necessarily shrinks. Less capable models are more likely to misread a situation and make obvious errors. More capable models make fewer mistakes, but they're also better at finding unexpected paths to a goal, often by routing around restrictions nobody thought to write down.
模型行为失当：Agent 做了没人让它做的有害行为。随着模型进步，大多数行为评估上的对齐程度在提高，但这不等于风险必然缩小——能力弱的模型更容易误判局面、犯低级错误；能力强的模型犯错更少，但也更擅长找到通往目标的意外路径，常常是绕过那些「没人想到要写进规则」的限制。
At Anthropic, we've seen Claude models "helpfully" escape a sandbox in order to complete a task, examine git history to find answers to a coding test, and spontaneously identify the benchmark it was being run on in order to decrypt its answer key. Each model brings a new set of capabilities that are sometimes put to work in unexpected ways.
在 Anthropic，我们亲眼见过 Claude「热心地」为了完成任务而逃出沙箱、翻 git 历史找编程测验的答案、自发认出自己正在被哪个基准测试评测、进而解密出答案钥匙。每一代模型都带来一组新能力，而这些能力有时会用在意想不到的地方。
External attackers: The agent is attacked through external vectors such as tools, files, or network access. This category includes both prompt injection and conventional attacks on the agent's runtime, orchestration layer, or proxy.
外部攻击者：Agent 经由工具、文件、网络等外部通道被攻击。这一类既包括提示注入（prompt injection），也包括对 Agent 运行时、编排层或代理层的传统攻击。
When building containment and defense systems, we apply defenses to three main components:
构建遏制与防御体系时，我们把防御落在三个主要组件上：
The environment in which the agent runs. We constrain where and how an agent can act with process sandboxes, VMs, filesystem boundaries, and egress controls. The goal is to set a hard boundary on what an agent can reach. For example, if credentials never enter the sandbox, they can't be exfiltrated, regardless of whether the cause is a user, a model finding a "creative" path, or an attacker.
Agent 运行的环境。用进程沙箱、虚拟机、文件系统边界和出口管控，约束 Agent 能在哪里、以什么方式行动。目标是给「Agent 能摸到什么」划一条硬边界。比如：凭证根本不进沙箱，它就不可能被外泄——无论起因是用户、是模型找到了某条「创造性」路径，还是攻击者。
A tight perimeter also means you can relax oversight. Claude Code's reference devcontainer exists precisely so that the agent can run unattended, without per-action approvals.
边界足够紧，监督就可以放松。Claude Code 的参考 devcontainer 正是为此而生：让 Agent 无人值守地运行，不需要每步审批。
The model the agent consults. The mechanisms here include system prompts, classifiers, probes, and training modifications. Because models are probabilistic, these shape only what the agent tends to do, not what it is theoretically capable of doing.
Agent 所依赖的模型。手段包括系统提示词、分类器、探针和训练层面的修正。但模型是概率性的，这些手段只能塑造 Agent「倾向于做什么」，管不住它「理论上做得到什么」。
These defenses are strong. On Gray Swan's Agent Red Teaming benchmark, which tests susceptibility to prompt injection, Claude Opus 4.7 holds attack success to roughly 0.1% on single attempts, and around 5–6% after 100 adaptive attempts. Claude Code auto mode catches roughly 83% of overeager behaviors before they execute. Yet even with best-in-class defenses, protection in the model layer will never be 100% effective, which is why it can't stand alone.
这些防御相当强：在专门测提示注入易感性的 Gray Swan Agent 红队基准上，Claude Opus 4.7 把单次尝试的攻击成功率压到约 0.1%，100 次自适应尝试后也只在 5–6% 左右；Claude Code auto mode 能在执行前拦下约 83% 的「过头行为」。但即便是业界最好的防御，模型层的防护也永远到不了 100%——所以它不能孤军奋战。
The external content the agent can reach. MCP servers, third-party plugins, and web search tools all feed content into the agent's context from sources you don't control. An audited connector isn't the same as audited data—a GitHub connector, for instance, can load a poisoned README straight into the model's context despite passing malware checks. Granularly limiting tool permissions can help limit the blast radius. An agent with read-only DB access, for instance, can be deployed far more broadly than one that writes to prod.
Agent 能触达的外部内容。MCP 服务器、第三方插件、网页搜索工具，都在把你不控制的内容喂进 Agent 的上下文。「连机器审计过」不等于「数据审计过」——比如 GitHub 连接器过了恶意软件检查，照样能把一个带毒的 README 直接装进模型上下文。对工具权限做细粒度限制能压缩影响半径：只读数据库的 Agent，就可以比能写生产库的 Agent 部署得广得多。
Defenses should overlap and complement each other. When environmental defenses aren't available, the model layer has to pick up the slack (this is precisely what Claude Code's auto mode is designed for). Locally, the environment and model defenses can guard against malicious tool outputs, but defenses can be added higher up the chain by limiting the tool's capabilities and access.
防御应该相互重叠、互为补充。当环境层防御不可用时，就得由模型层补位（Claude Code auto mode 正是为此设计的）。在本地，环境与模型两层防御可以挡住恶意工具输出；但更上游还可以再加一层——直接限制工具本身的能力与权限。
Patterns for containing agents · 遏制 Agent 的三种模式
Focusing on the environment layer, we describe three isolation patterns and how they're tailored for each Claude platform—claude.ai, Claude Code, and Cowork. We arrived at each design gradually, after finding the balance between the capabilities we need from the agent and the degree of intervention required from the user.
聚焦环境层，下面讲三种隔离模式，以及它们如何按 claude.ai、Claude Code、Cowork 各自的平台特性量身定制。每个设计都不是一步到位的，而是在「我们需要 Agent 有多大能力」和「需要用户介入多深」之间反复找平衡的结果。
Though best known as a chat interface, claude.ai also writes and runs code, generates files, and calls connectors. When Claude runs code inside claude.ai, it does so in a gVisor container on isolated infrastructure. The agent is entirely server-side; no code runs on the local machine, and the filesystem is ephemeral (per-session). The blast radius is minimal, but so is the ceiling on what Claude can do—there's no persistent workspace and no access to the user's filesystem.
claude.ai 虽以聊天界面著称，但也会写代码、跑代码、生成文件、调用连接器。Claude 在 claude.ai 里跑代码时，跑在隔离基础设施上的 gVisor 容器里。Agent 完全在服务端：本机不跑任何代码，文件系统按会话即弃。影响半径极小，但 Claude 能力的天花板也低——没有持久工作区，碰不到用户的文件系统。
This also makes claude.ai subject to a more traditional threat model. We're not protecting user machines from agents; we're protecting our own infrastructure and each tenant from one another. Our pre-launch work for claude.ai was dominated by traditional security work like network configuration, internal service auth, and orchestration.
这也使 claude.ai 面对的是更传统的威胁模型：我们要保护的不是用户的机器不被 Agent 祸害，而是保护自己的基础设施、以及让各租户互不相扰。上线前的安全工作主要是传统那一套——网络配置、内部服务认证、编排。
That work reinforced the oldest lesson in security: the weakest layer is the one you built yourself. gVisor and seccomp have been hardened against well-resourced adversaries for far longer than agentic AI has existed, so the review effort went into the newer pieces we'd built around them. We'll come back to this later, since our custom proxy is also the piece that broke in our most consequential incident.
这段经历再次印证了安全界最古老的教训：最薄弱的一层，永远是你自己造的那层。gVisor 和 seccomp 被资源充足的对手锤炼的年头，比 Agent AI 的历史长得多，所以审计力气都花在我们围绕它们新造的部分上。这一点后面还会回来——我们自研的代理，恰恰就是在后果最严重的那次事故里坏掉的部件。
Claude Code runs on a user's machine and has access to their filesystem, shell, and network. Without this, coding agents have limited usefulness, so it's imperative to find a way to grant that access safely.
Claude Code 跑在用户自己的机器上，能碰文件系统、shell 和网络。没有这些，编程 Agent 的用处有限——所以必须找到安全地交出这些权限的办法。
One approach is to rely on a human-in-the-loop. This is only a tractable solution for Claude Code because the average user is a developer who's familiar with coding environments: they can read bash, they understand what rm -rf does, and they already run npm install from untrusted sources several times a week. All that means that when an "allow this" dialog pops up, they are highly likely to have the expertise to accurately evaluate what the agent is attempting to do and the risk involved. Given this, Claude Code launched with the simplest possible defense: allow reads, require approval for write, bash, and network access.
一条路是靠人在环路。这在 Claude Code 上之所以可行，只因为典型用户是熟悉编码环境的开发者：读得懂 bash，知道 rm -rf 意味着什么，本来就每周好几次从不可信来源跑 npm install。于是当「允许吗」的弹窗出现时，他们大概率真有能力判断 Agent 想干什么、风险多大。基于此，Claude Code 上线时用的是最简单的防御：读免批，写、bash、网络一律要批。
However, as mentioned, approval fatigue showed up within weeks. Ironically, this meant that a feature originally designed to provide oversight could arguably have the opposite effect—some users might simply stop paying attention. As a first step to mitigate incautious approvals, we shipped an OS-level sandbox (Seatbelt on macOS, bubblewrap on Linux) that hardens the boundary: reads are allowed, writes are allowed inside the workspace, but network is denied by default. Within the sandbox, the agent runs largely without interruption. The result was an 84% reduction in permission prompts, and we open-sourced the runtime, so the boundary is auditable.
但如前所述，几周之内审批疲劳就现形了。讽刺的是：一个本为监督而生的功能，反而可能起反作用——有些用户干脆不看就点允许。作为缓解轻率审批的第一步，我们上线了操作系统级沙箱（macOS 用 Seatbelt，Linux 用 bubblewrap）来加固边界：读放行、工作区内写放行、网络默认拒绝。在沙箱内，Agent 基本不受打断地干活。结果是权限弹窗减少了 84%，而且我们把运行时开源了——这条边界是可审计的。
Our anonymized usage data also showed that experienced users auto-approve roughly twice as often as new users, but they also interrupt the agent mid-execution more frequently. Instead of gating individual steps, experienced users are more likely to supervise the agent only when it goes off track. While this may be a natural evolution in how people prefer to work with agents, this too is fallible, requiring users to be technical and attentive enough to notice drift in the first place. As model capabilities improve and agents begin writing increasingly ambitious bash, it becomes harder to notice any such drift. And as users move to multi-agent systems, this approach is also much less likely to be an effective oversight strategy.
匿名化使用数据还显示：老用户自动批准的频率约为新用户的两倍，但中途打断 Agent 的频率也更高。老用户不是逐步把关，而是等 Agent 跑偏了才出手管。这也许体现了人机协作方式的自然演化，但它同样不可靠——前提是用户既懂技术又足够专注，能在第一时间察觉跑偏。而随着模型能力增强、Agent 写出的 bash 越来越「雄心勃勃」，察觉跑偏会越来越难；等用户转向多 Agent 系统，这种监督方式就更靠不住了。
Between mid-2025 and January 2026, we received reports of vulnerabilities in Claude Code through our responsible disclosure program. Three of these vulnerabilities targeted code that executes before the user has consented to anything. To understand how this is possible, consider the most direct case: a developer clones a repository to review a pull request, and that repository contains a .claude/settings.json which defines a hook. Because Claude Code reads project settings during startup—before presenting the standard "Do you trust this folder?" prompt—the hook the attacker had authored and committed would execute automatically. The remaining cases looked structurally similar, in which input from the not-yet-trusted directory was parsed before the trust boundary had been established.
2025 年中到 2026 年 1 月之间，我们经负责任披露渠道收到过几起 Claude Code 漏洞报告。其中三起瞄准的是「用户还没同意任何东西之前」就执行的代码。怎么做到的？看最直接的一种：开发者 clone 一个仓库来 review PR，仓库里躺着一份定义了 hook 的 .claude/settings.json。Claude Code 在启动时读取项目配置——早于弹出标准的「信任此文件夹吗？」提示——于是攻击者写好并提交的 hook 会自动执行。其余几起结构类似：来自「尚未可信」目录的输入，在信任边界建立之前就被解析了。
The fix in each case had the same shape: defer parsing and execution of project-local configuration until after the user accepts the trust prompt. If you're building something similar, treat project-open, config-load, and localhost listeners the way you'd treat any inbound request from the internet. They shouldn't be implicitly trusted just because they feel local and arrive before the user has consented.
每一例的修法形状都一样：把项目本地配置的解析与执行推迟到用户通过信任提示之后再做。如果你在做类似的东西，请把「项目打开、配置加载、localhost 监听」当作来自互联网的入站请求来对待——别因为它们「感觉是本地的」、来得比用户授权早就默认信任。
In February 2026, during a controlled internal red-team exercise, a researcher successfully phished an employee into launching Claude Code with a malicious prompt. The phish looked like ordinary collaboration—a "can you run this for me?" email with a ready-to-paste prompt attached—and the prompt itself read like routine task instructions. But somewhere among the setup steps, it gently asked Claude to read ~/.aws/credentials, encode the contents, and POST them to an external endpoint. Across 25 retries of that prompt, Claude completed the exfiltration 24 times.
2026 年 2 月，在一次受控的内部红队演练中，研究员成功钓到一名员工，让他带着恶意提示词启动了 Claude Code。钓饵看起来就是普通的协作——一封「能帮我跑一下这个吗？」的邮件，附一段可直接粘贴的提示词，提示词本身读起来也像寻常任务说明。但在若干个准备步骤中间，它不动声色地让 Claude 读取 ~/.aws/credentials、编码内容、POST 到一个外部端点。这段提示词重试 25 次，Claude 完成了 24 次外泄。
This is a direct prompt injection—the attacker's instructions arrived through the user, not through tool output or fetched content. Our model-layer defenses anchor on user intent—when the user is the one typing the instruction, there's nothing anomalous for a classifier to catch. A human contractor handed the same script would have done the same thing.
这是直接型提示注入——攻击者的指令经由用户本人抵达，而不是经工具输出或抓取内容。我们的模型层防御锚定在「用户意图」上：当指令正是用户亲手输入的，分类器没有任何异常可抓。把同样的脚本交给一个人类外包，他也会照做。
The only defense that holds in this situation is the environment, specifically egress controls that block the POST regardless of intent and filesystem boundaries that keep ~/.aws out of reach in the first place.
这种局面下唯一守得住的防线是环境层：出口管控不管你什么意图直接掐掉那个 POST，文件系统边界从一开始就让 ~/.aws 摸不到。
(When we shared the working prompt in internal Slack for discussion, someone pointed out that some internal agents read Slack. The payload was now ambient. We added a canary string to the thread so we'd notice if anything picked it up. In a world where agents read everything, the investigation tooling is also an attack surface.)
（当我们在内部 Slack 里贴出那段可用的提示词讨论时，有人指出：有些内部 Agent 会读 Slack——载荷就此散布在环境里了。我们往讨论串里加了金丝雀字符串，万一有什么东西捡起它我们就能察觉。在 Agent 无所不读的世界里，调查工具本身就是攻击面。）
Claude Cowork runs on a user's desktop with access to a workspace folder selected by the user. Because the platform is built for general knowledge work, not software engineering, the average user is much less likely to be fluent in bash.
Claude Cowork 跑在用户桌面，能碰的是用户选定的一个工作区文件夹。这个平台面向的是通用知识工作而非软件工程，典型用户懂 bash 的概率低得多。
As a result, the human-in-the-loop sandbox strategy may not transfer; a non-technical knowledge worker shouldn't be expected to judge bash incantations such as find . -name "*.tmp" -exec rm {} \;. When approving an exception requires expertise the typical user doesn't have, admins should set a boundary that is absolute and always-on.
因此人在环路的沙箱策略未必迁移得过来：不能指望非技术的知识工作者判断 find . -name "*.tmp" -exec rm {} \; 这类 bash 咒语。当「批准一个例外」需要典型用户不具备的专业知识时，就该由管理员给出绝对且常开的边界。
To enable this, our first version of Claude Cowork ran inside a full virtual machine using the platform's vendor hypervisor (Apple's Virtualization framework on macOS, HCS on Windows). The VM has its own Linux kernel, its own filesystem, and its own process table. The user's selected workspace and .claude folder are mounted; nothing else on the host is visible. Credentials stay in the host's keychain and never enter the guest machine. This design protects against the possibility that Claude will, at some point, behave in a misaligned manner. A compromised Claude could still damage what's inside the workspace folder, so the architecture is designed to make sure that's the only thing it can reach (until the user adds connectors), and that the user controls what's mounted there.
为此，Claude Cowork 第一版跑在平台自带 hypervisor（macOS 的 Virtualization framework、Windows 的 HCS）支撑的完整虚拟机里。VM 有自己的 Linux 内核、自己的文件系统、自己的进程表。用户选的工作区和 .claude 文件夹挂载进去；宿主机上其余一切不可见。凭证留在宿主机钥匙串里，永不进 Guest 机。这个设计防的就是「Claude 哪一天行为失准」：被攻陷的 Claude 仍可能破坏工作区文件夹内的东西，所以架构要保证那是它唯一摸得到的东西（除非用户添加连接器），且挂载什么由用户说了算。
In the original architecture—what we call full-VM mode—the agent loop itself ran inside the guest, so Claude executed as an ordinary Linux user with no awareness it was sandboxed. Compare this to Claude Code, where a privileged process sits outside the sandbox deciding per-command whether to enforce it; a persuasive injected prompt or a fatigued approval click can get that process to run something un-sandboxed. Here, there was no outer process holding an escape-hatch key, and so no component with the authority to grant an exception.
最初的架构——我们称之为全 VM 模式——Agent 循环本身就跑在 Guest 里，Claude 以普通 Linux 用户身份执行，根本不知道自己在沙箱里。对比 Claude Code：一个特权进程坐在沙箱外，逐条命令决定要不要强制执行；一段有说服力的注入提示词、或一次疲劳下的点击允许，都可能让那个进程放行未经沙箱的东西。而在这里，外面没有任何持有逃生钥匙的进程，也就没有任何组件有权力批出例外。
However, we soon realized that running the whole agent in full-VM mode caused practical problems: any failure during VM startup made Cowork unusable. Moving the agent loop outside of the VM, while keeping code execution inside of it, allowed Claude to still respond to the user and help debug issues rather than freeze on an error. This change caused minimal security impact because the VM still enforces filesystem and network controls over code executed by the agent.
但我们很快发现全 VM 模式有现实麻烦：VM 启动阶段任何失败都会让 Cowork 直接不可用。于是把 Agent 循环挪出 VM、代码执行留在 VM 内——这样出问题时 Claude 还能响应用户、帮忙排查，而不是冻在报错上。这个改动对安全影响很小：VM 依然对 Agent 执行的代码强制文件系统与网络管控。
Separately, we also moved local MCP servers outside the VM. Running them inside the VM made them harder to audit, created brittle dependency issues when the VM updated, and didn't support MCPs that required interaction with local processes such as databases—such servers had to run on the host regardless. The change brings Claude Cowork in line with how local MCP servers already work in Claude Desktop: treating them like any software a user might choose to install and entrusting admins to decide which local MCPs to enable (if any). Remote MCP servers are unaffected since they do not run on the user's machine.
另一个独立改动：本地 MCP 服务器也挪出了 VM。放在 VM 里既难审计，又在 VM 更新时带来脆弱的依赖问题，而且不支持需要与本地进程（比如数据库）交互的 MCP——这类服务器横竖只能跑在宿主机上。调整后，Claude Cowork 与 Claude Desktop 的本地 MCP 逻辑对齐了：把它们当作用户自行安装的软件对待，由管理员决定启用哪些本地 MCP（如果启用）。远程 MCP 不受影响——它们本来就不跑在用户机器上。
Filesystem controls were another important architectural choice. Claude needs to be able to access some files on the host in order to be useful, but we wanted to minimize the blast radius and provide transparency to the user about local file access. We found that offering different file-mount modes helps to granularly control risk; Claude Cowork offers read-only, read-write, and read-write-no-delete. One potential gotcha here is that symlink resolution has to happen before path validation, not after, or a symlink inside an authorized folder can point outside and escape. For enterprise customers, we allow admins to control this via mount-path allowlists in MDM settings.
文件系统管控是另一个重要的架构选择。Claude 得摸到宿主机上的部分文件才有用，但我们想压缩影响半径、并让本地文件访问对用户透明。实践发现提供多种挂载模式有助于细粒度控险：Cowork 提供只读、读写、读写不可删三档。一个坑：符号链接解析必须发生在路径校验之前而不是之后，否则授权文件夹内的软链接可以指向外部、越狱出去。企业客户可以让管理员通过 MDM 设置里的挂载路径白名单来管控。
A clear example of exfiltration through an approved domain came from a third-party disclosure. Claude Cowork's egress allowlist correctly passed traffic to api.anthropic.com—the product can't function without calling our own API. In this case, a malicious file placed in the user's mounted workspace carried hidden instructions along with an API key controlled by the attacker. Claude, following the instructions, read other files in the workspace and called Anthropic's Files API using the attacker's key. The egress proxy checked the destination, saw api.anthropic.com, and let it through. The files were uploaded to the attacker's Anthropic account. The sandbox worked perfectly, and yet the data was exfiltrated.
一条「经白名单域名外泄」的清晰案例来自第三方披露。Claude Cowork 的出口白名单放行 api.anthropic.com——不调自家 API 产品没法工作，这没毛病。这次，用户挂载工作区里的一个恶意文件夹带了隐藏指令和一把攻击者控制的 API key。Claude 照指令读了工作区里的其他文件，用攻击者的 key 调用 Anthropic 的 Files API。出口代理查了目标，看到是 api.anthropic.com，放行。文件就这样上传进了攻击者的 Anthropic 账户。沙箱完美运转，数据照样被外泄。
Previously, we'd conceptualized the allowlist as a destination filter, something that told Claude these domains are okay to talk to. But it may be better conceptualized as a capability grant. Every function reachable through any domain on an allowlist is now an attack surface. Allowing api.anthropic.com meant allowing file uploads to arbitrary Anthropic accounts.
此前我们把白名单理解成目的地过滤器——告诉 Claude 这些域名可以交谈。但更准确的理解或许是「能力授予」：白名单上任何域名能触达的每一个功能，都成了攻击面。放行 api.anthropic.com，就意味着放行「向任意 Anthropic 账户上传文件」。
We fixed it using a defensive man-in-the-middle proxy inside the VM that intercepts traffic to our API. It only passes requests carrying the VM's own provisioned session token; an attacker-embedded key is rejected by the proxy. It also blocks headers that would enable server-side fetch. The proxy sits inside the VM rather than on our servers because only the VM knows provenance—from the server's perspective, a Cowork request is indistinguishable from any other API client.
修法是在 VM 内部署一个防御性中间人代理，拦截发往自家 API 的流量：只放行携带 VM 自己配发的会话令牌的请求，攻击者植入的 key 会被代理拒掉；同时屏蔽那些会启用服务端 fetch 的请求头。代理放在 VM 内而不是我们的服务器上，是因为只有 VM 知道流量出身——在服务器看来，Cowork 的请求与任何其他 API 客户端无法区分。
This is also a second instance of the principle that the software you build yourself is often the weakest. The hypervisor, seccomp, and gVisor across our products have been dependable. Our custom allowlist proxy was the piece that failed.
这也第二次印证了那条原则：自己造的软件往往最薄弱。我们的产品里，hypervisor、seccomp、gVisor 一直可靠；坏掉的，是我们自研的白名单代理。
When evaluating Claude Cowork, enterprise security teams asked, "Why can't our EDR see inside?" The answer was that the same isolation keeping Claude contained also kept host-based endpoint detection and response out. From the EDR's perspective, Claude Cowork is an opaque hypervisor process. It can't inspect the guest.
评估 Claude Cowork 时，企业安全团队问：「为什么我们的 EDR 看不进去？」答案是：把 Claude 关住的隔离，同样把基于主机的端点检测与响应（EDR）关在了外面。在 EDR 视角里，Claude Cowork 就是个不透明的 hypervisor 进程，看不见 Guest 内部。
Isolation reduces visibility, and opacity is problematic for teams whose compliance posture depends on endpoint visibility. Our current mitigation is to use pull-based OTLP exports that let administrators retrieve event logs after the fact, but this is not the same as live monitoring. If you're building something similar, budget for this conversation early.
隔离削减可见性，而对于合规姿态依赖端点可见性的团队，不透明是个麻烦。我们当前的缓解是采用拉取式 OTLP 导出，让管理员事后取回事件日志——但这不等于实时监控。如果你在做类似的东西，请把这场对话提前算进预算。
Trusting what the agent reads · 信任 Agent 读到的东西
Enterprises often ask us how to secure MCP connections. It's a good question, but the right one is broader than MCP specifically. Any external resource provided to an agent represents two risks at once: a code execution risk, in the traditional supply-chain sense, and a prompt injection vector. Traditional dependency auditing (pinning versions, verifying signatures, reviewing source) addresses the first, but misses the second.
企业常问我们怎么保 MCP 连接安全。这是个好问题，但正确的问题比 MCP 更宽：给 Agent 的任何外部资源都同时构成两种风险——传统供应链意义上的代码执行风险，和提示注入载体。传统的依赖审计（锁版本、验签名、审源码）管得住第一种，管不住第二种。
Remote versus local is more important than it seems. A locally installed tool is auditable. You can read the code, pin the version, and know it won't change under you. A remote tool—a hosted MCP server, a cloud connector—can change behavior at any point after you've approved it; your install-time trust decision may no longer apply. Our connector directory addresses this through ongoing review, but anything outside it should be treated as untrusted. Run it against fake data first, in an environment where the blast radius of a malicious tool is contained.
远程还是本地，比看上去更重要。本地安装的工具是可审计的：代码读得到、版本锁得住、不会在你脚下变卦。远程工具——托管 MCP 服务器、云端连接器——在你批准之后的任何时刻都可能改变行为，你安装时做出的信任决定可能早已失效。我们的连接器目录靠持续复审来兜着，目录之外的一切都应按不可信对待：先拿假数据跑，把它关在影响半径可控的环境里。
Tool output is an attack surface even when the tool is trusted. The GitHub README example mentioned earlier is exactly this case; any input scanning applied to web pages needs to be applied to network-enabled tool results with the same rigor. Even though this adds latency and isn't a perfect defense, we err toward live inspection: once a poisoned tool return has steered the agent into exfiltrating data, the log just shows a successful, authorized API call. There's no after-the-fact signal to find.
即使工具本身可信，工具输出也是攻击面。前面 GitHub README 的例子正是这种情形；对网页做的一切输入扫描，要以同样的严格度施加在联网工具的返回结果上。这会加延迟、也非完美防御，但我们宁可倾向实时检查：一旦带毒的工具返回已经把 Agent 引向数据外泄，日志里看到的只是一次成功、已授权的 API 调用——事后没有任何信号可查。
In Claude Code and Claude Cowork, tool calls route through proxies that enforce network and file policy and can inspect return values before they enter the model's context. The classifier that does the inspection can be a small, fast model; it doesn't need to be the one doing the reasoning.
在 Claude Code 和 Claude Cowork 里，工具调用都经由代理路由：代理执行网络与文件策略，并能在返回值进入模型上下文之前先行检查。做检查的分类器可以是又小又快的模型——不必是干活推理的那个。
Looking ahead · 展望
Models and products are advancing fast. As they do, risks morph and evolve, and our mitigations must keep pace to meet them.
模型与产品在飞速前进。风险随之变形演化，缓解手段必须跟上。
Persistent memory poisoning. The share of agent context that persists across sessions keeps growing—this includes product memory, CLAUDE.md files, mounted workspaces, and the state directories of scheduled and long-running agents. An injection that lands in any of these is reloaded each time the agent starts. As more agent state survives the session, we are threatened by new persistence mechanisms in the classic post-exploitation sense. Good classifiers on session startup will need to become more commonplace.
持久记忆投毒。跨会话存活的 Agent 上下文占比持续增长——产品记忆、CLAUDE.md 文件、挂载的工作区、定时与长时运行 Agent 的状态目录都算。落进其中任何一处的注入，会在 Agent 每次启动时被重新加载。随着越来越多 Agent 状态活过会话，经典后渗透意义上的「持久化机制」正在成为新的威胁。会话启动时的高质量分类器检查，需要变得司空见惯。
Multi-agent trust escalation. On the one hand, sub-agents can isolate untrusted content, returning structured facts rather than raw text up to the main agent. On the other hand, this can be abused: if a sub-agent's output is treated as higher-trust than raw tool results, because such output came from "us," a new vector for prompt injection is introduced. In multi-agent systems, there is a tradeoff between allocating differing trust levels and becoming liable to trust escalation.
多 Agent 信任升级。一方面，子 Agent 能把不可信内容隔离在外，只把结构化事实而非原始文本交回主 Agent；另一方面这也可能被滥用——若子 Agent 的输出因「出自我们自家」而被赋予高于原始工具结果的信任，就引入了新的提示注入载体。多 Agent 系统里，「分配差异化信任」与「沦陷于信任升级」之间是一场取舍。
Agent identity. Claude Cowork's answer to agent identity is concrete: credentials stay in the host keychain, the VM gets a per-session scoped-down token, and that token can be revoked independently of the user's. However, we are starting to grapple with the broader question of cross-platform agent identity. Should an agent possess its own principal identity, or should it act as an extension of the user and inherit the user's permissions? Ultimately, the answer may be a blend of the two.
Agent 身份。Claude Cowork 对 Agent 身份的答案是具体的：凭证留在宿主机钥匙串，VM 拿到按会话收窄的令牌，且该令牌可独立于用户令牌吊销。但更宏观的跨平台 Agent 身份问题才刚开始 grappling：Agent 应该拥有自己的主体身份，还是作为用户的延伸、继承用户的权限？最终的答案也许是两者的混合。
As agents grow more capable, attack surfaces are constantly shifting. The types of failures we've seen are likely to be repeated across industries and labs. We need collective investment in agent-specific security posture, from shared benchmarks and disclosure norms to common identity standards and cross-vendor red-teaming. We focus on containment in this piece, but that's only one part of the security picture for agents. For governance, observability, and the rest of the stack, see NIST's project on AI agent identity and authorization, the six-agency guidance on adopting agentic AI led by Australia's ACSC with CISA and the UK's NCSC, and ISO/IEC 42001, the AI management standard. Our Glasswing initiative is one contribution, but we look forward to working with both partners and competitors on this critical issue.
随着能力增强，攻击面在不断漂移。我们见过的这些失败类型，大概率会在各行业、各实验室重演。Agent 专属的安全态势需要集体投入——从共享基准与披露规范，到统一的身份标准与跨厂商红队。本文聚焦遏制，但这只是 Agent 安全版图的一部分；治理、可观测性与技术栈其余部分，可参考 NIST 的 AI Agent 身份与授权项目、由澳大利亚 ACSC 牵头联合 CISA 与英国 NCSC 的六机构 Agent AI 采用指南、以及 ISO/IEC 42001 AI 管理标准。我们的 Glasswing 计划是一份贡献，也期待与伙伴和竞争者一起面对这个关键议题。
Summary · 小结
In short, there are a few principles we keep returning to:
简而言之，有几条原则我们反复回到：
Design for containment at the environment layer first, then steer behavior at the model layer. Two of the incidents that taught us the most—the employee phish and the third-party allowlist disclosure—were both cases of egress, in which data left through a permitted path. In each, the model layer couldn't help; there was nothing anomalous for it to catch. The deterministic boundary is what gets hit when everything probabilistic misses.
先在环境层设计遏制，再在模型层引导行为。教给我们最多的两起事件——员工钓鱼与第三方白名单披露——都是出口问题：数据经一条被允许的路径离开。两起里模型层都帮不上忙，没有任何异常可供它捕捉。当一切概率性手段都失手时，接住局面的是确定性边界。
Match isolation strength to the user's capacity for oversight. A developer who can read bash and a knowledge worker who can't are not running the same threat model. The question of whether a user can evaluate what an agent is about to do should help determine the containment strategy, and answering it wrong in either direction—too much friction for experts, too much trust for non-experts—is its own failure.
隔离强度要与用户的监督能力相匹配。读得懂 bash 的开发者和读不懂的知识工作者，跑的不是同一个威胁模型。「用户能否评估 Agent 将要做的事」应当参与决定遏制策略——两头答错都是失败：给专家太多摩擦，或给非专家太多信任。
Be wary of custom components. Battle-tested hypervisors, syscall filters, and container runtimes have survived more adversarial attention than anything you'll build. Across every deployment described here, the standard primitives held while our own work around them exposed flaws.
警惕自研组件。身经百战的 hypervisor、系统调用过滤器、容器运行时，扛过的对抗审视比你将造的任何东西都多。本文描述的每一次部署里，标准原语都稳住了，暴露缺陷的都是我们围绕它们自己写的那部分。
Ultimately, while agents may be a new category of software, their system-level interactions are not. They still read files, open sockets, and spawn processes; this makes containment with mature tooling a crucially viable defense. The risk-reward balance of deployments will keep shifting as AI develops, but placing a hard limit on blast radius often forces that balance into the right direction.
归根结底：Agent 或许是软件的新品类，但它们的系统级交互不是。它们照样读文件、开 socket、起进程——这让「用成熟工具做遏制」成为一条至关重要的可行防线。部署的风险收益天平会随 AI 发展不断移动，但给影响半径上一道硬顶，往往就能把天平压向正确的方向。
Written by Max McGuinness, Mikaela Grace, Jiri De Jonghe, Jake Eaton, and Abel Ribbink.
作者：Max McGuinness、Mikaela Grace、Jiri De Jonghe、Jake Eaton、Abel Ribbink。
We're also grateful to 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, and others for their contributions.
同时感谢以上诸位及其他贡献者（名单从略，详见原文）。
Special thanks to our security and product engineering teams, and to the individuals and organizations that have reported vulnerabilities in Claude products.
特别感谢我们的安全与产品工程团队，以及所有报告过 Claude 产品漏洞的个人与组织。
Claude Code auto mode delegates command approvals to a model-based classifier; it minimizes friction (roughly 0.4% of benign commands blocked) at the cost of missing a fraction of risky ones (~17% of overeager actions get through), so it's one layer of defense-in-depth inside a sandbox, not a substitute for one.
注：Claude Code auto mode 把命令审批交给基于模型的分类器；它把摩擦压到最低（约 0.4% 的无害命令被误拦），代价是漏掉一部分危险命令（约 17% 的过头行为会溜过）。所以它是沙箱内纵深防御的一层，不能替代沙箱。