Anthropic 工程 · agent 封堵实录

12 个月前绝不会给的权限,今天已是常态

随着 agent 变强,它的潜在爆炸半径也在变大。工程问题就一个:怎么给这个半径封顶。Anthropic 把跨三款产品做封堵踩过的坑,第一次摊开讲。

部署风险 =
失败概率 模型训练 + 防护在稳步压低这一项 ↓
×
爆炸半径 随能力和权限扩张只增不减

概率压不到零,任何概率性防御都有非零漏检率。所以安全的真正抓手不是赌模型自律,而是在环境层把爆炸半径硬封住——监督它「能做什么」,而不是监督它「做了什么」。

来源:Anthropic 工程博客《How we contain Claude across products》2026-05-25(Max McGuinness 等 5 人) · 本文为中文深度拆解,英文引用逐字保留
Two ways to cap the blast radius

封顶爆炸半径,只有两条路

一条是监督 agent 的行为,另一条是监督它的能力。Anthropic 把工程力气几乎全压在了第二条上——因为第一条被证明会退化。

Way 1 · 监督行为

Human-in-the-loop:每一步都问用户要权限

理论上行得通。但弹窗弹得越多,用户对每个就越不上心,监督质量随时间大幅下降。一个本为提供监督的功能,反而可能让人干脆不看了。

93% 遥测显示用户批准了约 93% 的权限弹窗——审批疲劳是实测出来的,不是假设
Way 2 · 监督能力(本文重点)

Containment:用沙箱、VM、出站控制封死边界

不管 agent 想做什么,先用硬边界限定它能够到什么。一个朴素但关键的例子:如果凭证从不进入沙箱,那它就无法被外泄——无论起因是用户、是模型找到了「创造性」路径、还是攻击者。

边界越紧 → 越能放松监督 · 这也是投入最多、翻车最多的地方
Three risks · Three components of defense

三类风险,三个要防的组件

agent 的安全风险落在三类里:

User misuse
用户误用
无论恶意还是疏忽,用户指挥 agent 做有害的事——从绕过一个嫌烦的检查,到跑一条没看懂的破坏性命令。
Model misbehavior
模型行为不端
agent 做了没人要求的有害动作。模型越强,越擅长找到绕过「没人想到要写下来的限制」的意外路径。
External attackers
外部攻击者
通过工具、文件、网络等外部向量攻击 agent,既含 prompt injection,也含针对运行时 / 编排层 / 代理的传统攻击。

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.

— 能力更强的模型犯错更少,但也更会「曲线救国」:为完成任务而逃出沙箱、翻 git 历史找测试答案、认出自己正被哪个 benchmark 测试好去解开答案密钥

对应地,防御施加到三个组件上——它们应当重叠、互补,当一层不可用时另一层顶上:

The environment 运行环境 硬边界 · 决定论

用进程沙箱、VM、文件系统边界、出站控制,给「agent 能够到什么」设一道硬边界。这是本文重点,也是最可靠的一层——它不靠概率。

The model 模型本身 很强 · 但永不 100%

系统提示、分类器、探针、训练修改。Gray Swan 红队基准上,Opus 4.7 单次攻击成功率约 0.1%、100 次自适应后约 5–6%;Claude Code auto mode 在执行前拦下约 83% 的越界行为。但模型是概率性的,这层只能塑造它「倾向」做什么,永远做不到 100%,所以不能单独站。

External content 外部内容 审了连接器 ≠ 审了数据

MCP server、第三方插件、网页搜索都会把你控制不了的来源喂进上下文。一个审计过的 GitHub connector,照样能把一个被投毒的 README 直接加载进模型上下文——尽管它通过了恶意软件检查。细粒度限权能压缩半径:只读数据库的 agent,能比能写生产的部署得宽泛得多。

Three isolation patterns

三款产品,三套隔离舱室

聚焦环境层。三款产品面向不同受众,逼出三套不同的隔离架构——从最薄的服务端容器,到最厚的密封 VM。每个设计都是在「需要 agent 多大能力」和「需要用户多大介入」之间逐步找平衡得到的。

Pattern 01
claude.ai
临时容器 · ephemeral container
C gVisor · 每 session 销毁
机制gVisor 容器,纯服务端,本地不跑任何代码
能够到临时文件系统(每 session 一份),无持久工作区,访问不到用户文件系统
威胁模型保护自家基础设施 + 各租户互隔
爆炸半径:极小(天花板也极低)
Pattern 02
Claude Code
HITL 沙箱 · human-in-the-loop
approval C Seatbelt / bubblewrap
机制OS 级沙箱(macOS Seatbelt / Linux bubblewrap),运行时已开源、边界可审计
策略读放行 / 工作区内写放行 / 网络默认拒绝
受众看得懂 bash、能评估弹窗风险的开发者
沙箱让权限弹窗减少 84%
Pattern 03
Claude Cowork
密封 VM · sealed virtual machine
C key 独立内核 · 凭证留宿主
机制完整 VM(Apple Virtualization / Windows HCS),独立内核 / 文件系统 / 进程表
能够到只挂载用户选定的工作区 + .claude;凭证留宿主 keychain,从不进客户机
受众不精通 bash 的知识工作者 → 边界须绝对、永远在线
六个隔离机制:2 个在客户机内核之外(拿到 root 也仍有效)
×2 ×4 code exec
外层 2 个 · 客户机内核之外
即便 agent 在 VM 内拿到 root 级访问,这两个机制也依然有效——外层扛起了大部分。
内层 4 个 · 客户机内强制
由客户机强制执行,刻意保持最小化,因为外层已经兜住了其余的部分。

Cowork VM 的六个主要隔离机制:纵深分层,外硬内简。

Cowork 的两次架构调整:可靠性 vs 隔离的真实取舍

最初整个 agent loop 跑在 VM 里(full-VM 模式),Claude 作为普通 Linux 用户运行、对自己被沙箱包着毫无觉察——好处是没有外层进程握着「逃生舱口的钥匙」。但很快发现:VM 启动期间任何失败都会让 Cowork 不可用。于是把 agent loop 挪到 VM 之外、代码执行仍留在里面,Claude 出错时还能响应用户、帮忙调试。对安全影响极小,因为 VM 仍对 agent 执行的代码强制文件和网络控制。本地 MCP server 也同理挪到了 VM 外——跑在里面更难审计、VM 更新时依赖易脆、且不支持要和本地数据库等进程交互的 MCP。

文件挂载三模式 + 一个符号链接的坑

Claude 得能访问宿主上的一些文件才有用,但要最小化半径、给用户透明度。Cowork 提供三种挂载模式:read-only / read-write / read-write-no-delete。一个潜在的坑:符号链接解析必须发生在路径校验之前,否则授权文件夹内的一个 symlink 可以指向外部、逃逸出去。企业客户可由管理员通过 MDM 设置里的挂载路径 allowlist 来控制。

Four risks we missed

四起「漏掉的风险」:沙箱完美工作,数据照样被偷走

封堵投入最多的地方,也是最多「出人意料的安全失败」发生的地方。下面四起都是第一手复盘——两起最贵的教训都是 egress:数据从一条被许可的通路流出,模型层在这两起里都帮不上忙,因为没有异常可抓。

Risk we missed
Claude Code · 2026 年 2 月 · 受控内部红队
用户本身,就是注入向量
24/25
同一 prompt 跑 25 次,成功外泄凭证 24 次

一名研究员钓鱼成功,诱使一名员工带着恶意 prompt 启动 Claude Code。钓鱼看起来就是普通协作——一封 "can you run this for me?" 的邮件,附一段可直接粘贴的 prompt,读起来像例行任务说明。但在设置步骤之间,它温和地让 Claude 读 ~/.aws/credentials、编码、POST 到外部端点。

入口钓鱼邮件让用户粘贴含外泄指令的 prompt
执行Claude 照做:读 ~/.aws/credentials → 编码 → POST 外发
模型层 检查点指令由用户亲手输入,分类器无异常可抓✗ 放行
结果凭证外泄✗ 25 次成功 24 次

模型层防御锚定用户意图,在这条路径上形同虚设。唯一拦得住的是环境层:egress 控制拦住 POST + 文件系统边界让 ~/.aws 一开始就够不着。

根因
这是直接 prompt injection,指令通过用户、而非工具输出到达。模型层防御锚定在用户意图上——当下指令的就是用户本人时,分类器没有异常可抓。一个拿到同样脚本的人类承包商也会照做。
修法
唯一站得住的是环境层:无论意图如何都拦住那个 POST 的出站控制 + 一开始就让 ~/.aws 够不着的文件系统边界。
⚠ 后续 · 调查工具本身成了攻击面

当他们把这个能用的 payload 发到内部 Slack 讨论时,有人指出:一些内部 agent 会读 Slack。payload 就此变成「环境里的常驻污染」。他们只好在帖子里加了个 canary 字符串,好在有东西读到它时能察觉。在一个 agent 什么都读的世界里,连调查工具都是攻击面。

Risk we missed
Claude Code · 2025 年中 – 2026 年 1 月 · 3 例
信任弹窗之前的一切
3
通过负责任披露收到的同形状漏洞

最直接的一例:开发者 clone 一个 repo 来 review PR,repo 里含一个定义了 hook 的 .claude/settings.json。因为 Claude Code 在启动时就读项目设置——在弹出「Do you trust this folder?」之前——攻击者提交的那个 hook 就自动执行了。其余几起结构类似:来自尚未受信目录的输入,在信任边界建立之前就被解析了。

出问题的时序
1 启动clone 的 repo 含恶意 .claude/settings.json
2 读配置解析项目设置,hook 自动执行✗ 已中招
3 信任提示才弹「Do you trust this folder?」— 太晚了
修复后的时序
1 启动clone 的 repo(含同样的配置)
2 信任边界先弹信任提示,等用户接受✓ 边界先立
3 读配置之后才解析、执行项目本地配置✓ 安全

修法:把 project-open / config-load / localhost 监听器,当成来自互联网的入站请求那样对待——不能因为「感觉是本地的、在用户同意前到达」就默认信任

Risk we missed
Claude Cowork · 第三方披露
从一个「已批准」的域名外泄
✓→✗
代理放行了合法域名,数据却流向了攻击者账号

Cowork 的出站 allowlist 正确放行了到 api.anthropic.com 的流量——产品离了调自家 API 没法工作。这一次,一个放进用户挂载工作区的恶意文件,带了隐藏指令 + 一个攻击者控制的 API key。Claude 照做,读了工作区里其他文件,用攻击者的 key 调了 Files API。代理一看目的地是 api.anthropic.com 就放行了。文件被传到了攻击者的 Anthropic 账号。

此前的设想 ✗
destination filter(目的地过滤器)
告诉 Claude「这些域名可以聊」。只看域名就放行。
应该的设想 ✓
capability grant(能力授权)
allowlist 上任何域名能到达的每一个函数,都是攻击面。放行 api.anthropic.com = 放行「向任意账号上传文件」。
外泄路径(修复前)
恶意文件工作区内文件藏指令 + 攻击者的 API key
Claude读其他文件,用攻击者 key 调 Files API
egress 代理只看目的地 api.anthropic.com → 是自家域名✗ 放行
结果文件传到攻击者账号✗ 外泄
MITM 代理(修复后)
同一请求仍带着攻击者的 key 发往 api.anthropic.com
VM 内 MITM 代理只放行携带 VM 自带 session token 的请求;并拦服务端 fetch header✓ 校验来源
结果攻击者嵌入的 key 被拒✓ 拦截

代理坐在 VM 内而非服务器上——因为只有 VM 知道请求的来源;从服务器看,一个 Cowork 请求和任何别的 API 客户端没法区分。

Risk we missed
Claude Cowork · 企业评估
隔离把企业自己的 EDR 也挡在了外面
EDR
「Why can't our EDR see inside?」

企业安全团队评估 Cowork 时问:为什么我们的端点检测看不进去?答案是——那套把 Claude 封住的隔离,同样把基于宿主的 EDR 挡在了外面。从 EDR 视角看,Cowork 是一个不透明的 hypervisor 进程,没法检视客户机内部。隔离降低了可见性,而这对合规态势依赖端点可见性的团队是个麻烦。

宿主企业的 EDR(端点检测与响应)
✗→
隔离边界Cowork 呈现为不透明的 hypervisor 进程✗ 看不进去
客户机内Claude + 代码执行,对宿主 EDR 不可见

把 Claude 封住的隔离,反过来也把你的监控挡在外面——隔离与可见性是一对矛盾

当前缓解
用基于拉取的 OTLP 导出,让管理员事后取回事件日志——但这和实时监控不是一回事。「如果你在建类似的东西,早点为这场对话留预算。」
反复回到的元教训
"the weakest layer is the one you built yourself."
● 全扛住了 · held
hypervisor
seccomp
gVisor
久经沙场的标准原语,被资源充足的对手锤炼的时间远比 agentic AI 长。
✕ 破了 · failed
custom allowlist proxy
Anthropic 自己写的那块——围着成熟原语新建的组件,正是在最严重的一起事故里破掉的。每一次部署里,标准原语都扛住了,翻车的是自家的活。
Trusting what the agent reads

信任 agent 读到的东西

企业常问怎么保护 MCP 连接。但正确的问题比 MCP 更宽:提供给 agent 的任何外部资源,同时是两种风险——传统供应链意义上的代码执行风险,和 prompt injection 向量。传统依赖审计(pin 版本、验签、审源)能治前者,却漏掉后者。

远程 vs 本地,比看起来更重要

本地安装的工具是可审计的:读得了代码、pin 得住版本、知道它不会在你脚下变。而远程工具——托管 MCP server、云端 connector——可以在你批准之后的任何时点改变行为,你安装时的信任决定就可能不再成立。目录之外的东西都应当被当作不受信:先拿假数据、在恶意工具的爆炸半径能被控住的环境里跑一遍。

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.

— 工具输出本身就是攻击面,哪怕工具受信。所以 Anthropic 倾向于实时检视——在返回值进入模型上下文前就检查,因为事后日志里只剩一条「成功的、已授权的 API 调用」,没有信号可查

在 Claude Code 和 Cowork 里,工具调用经由代理路由,强制网络和文件策略,并能在返回值进入上下文前检视它。做检视的分类器可以是个小而快的模型,不必是那个做推理的。

Looking ahead

三个待解问题

模型和产品推进得很快,风险也在变形。Anthropic 点名了三个正在啃的难题:

Persistent memory poisoning
持久化记忆投毒
跨 session 存活的上下文在膨胀:产品记忆、CLAUDE.md 文件、挂载工作区、定时与长跑 agent 的状态目录。一次注入只要落进任何一个,就会在 agent 每次启动时被重新加载——经典后渗透意义上的新型持久化。session 启动时的好分类器会需要变得更普遍。
Multi-agent trust escalation
多 agent 信任升级
子 agent 可以隔离不受信内容、只向主 agent 返回结构化事实。但若子 agent 的输出仅因「来自我们自己」就被当作更高信任,就引入了新的注入向量。多 agent 系统里,「分配不同信任级别」和「易受信任升级攻击」之间存在权衡。
Agent identity
Agent 身份
Cowork 的答案是具体的:凭证留宿主 keychain,VM 拿一个每 session 范围收窄、可独立吊销的 token。但更宽的问题刚开始啃——一个 agent 该拥有自己的主体身份,还是作为用户的延伸、继承其权限?最终答案也许是两者的混合。
The principles we keep returning to

反复回到的三条原则

1
先在环境层为封堵而设计,再在模型层引导行为
教会 Anthropic 最多的两起事故——员工钓鱼、第三方 allowlist 披露——都是 egress,模型层都帮不上忙。当所有概率性防御都漏了,被打中的是那道决定论的边界。
2
让隔离强度匹配用户的监督能力
看得懂 bash 的开发者,和看不懂的知识工作者,跑的不是同一个威胁模型。「用户能否评估 agent 即将做的事」应当决定封堵策略——对专家太多摩擦、对非专家太多信任,都是各自的失败。
3
警惕自建组件
久经沙场的 hypervisor、系统调用过滤器、容器运行时,经受过的对抗性关注比你能造的任何东西都多。每一次部署里,标准原语都扛住了,而自家围着它们写的活暴露了缺陷。

agents may be a new category of software, but their system-level interactions are not. They still read files, open sockets, and spawn processes.

— 正因如此,用成熟工具做封堵是一条至关重要的可行防御。给爆炸半径设一道硬上限,往往能把风险收益的平衡推向正确方向