个人 agent 住在哪：三种执行环境，三种安全代价

作者：Anthropic 工程团队（原文是他们公开的 agent 隔离架构复盘）

个人 agent 这个品类最近扎堆发布： Meta 的 Muse（云 VM）、Google 的 Gemini Spark（云 agent）、Anthropic 的 Claude Cowork（本地 VM）、苹果的 Siri AI（屏上感知）……

它们都在回答同一个问题：agent 该跑在哪里？

Anthropic 发了一篇很实在的复盘——他们做了三个产品，每个都用了不同的隔离架构，而且把「我们错过了什么」一节单独写了出来。我想把这三种模式讲清楚，因为你在自建 agent 时也要做同样的选择。

一、先讲一个前提：为什么监管不如围堵

作者开篇给了一个数字，很值得记：

Claude Code 以前靠每一轮都问用户要授权来防止 agent 做意外的事。理论上这能工作，但我们的遥测显示用户批准了大约 93% 的权限提示。

用户看到的批准请求越多，对每一个的注意力就越少，随着时间推移会变得远不如下一开始那么勤勉。

他们还发现了一个更微妙的规律：

我们的匿名使用数据还显示，有经验的用户自动批准的频率约为新用户的两倍，但他们打断 agent 执行的频率也更高。 有经验的用户不是去卡每一步，而是倾向于只在 agent 跑偏时才介入。

这个观察很关键：它说明「人工在环」的真实形态不是「逐条审批」，而是「事后纠偏」——而那要求用户有足够的技术能力察觉偏航。

另一个必须承认的事实：

任何概率性防御都有非零的漏检率。

所以他们的结论是：

在环境层为围堵而设计，然后再在模型层引导行为。 教给我们最多的两个事故——员工钓鱼和第三方披露的 allowlist 问题——都是出口问题，数据从一条被允许的路径离开了。 在这两个案例里，模型层帮不上忙，因为没有任何异常供它捕捉。

当所有概率性的东西都漏掉时，被撞上的是那个确定性的边界。

二、三种隔离模式

模式一：临时容器（claude.ai 的代码执行）

当 Claude 在 claude.ai 里跑代码时，它跑在 gVisor 容器里，跑在隔离的基础设施上。

• agent 完全在服务端

• 没有代码跑在你的机器上

• 文件系统是临时的（每个会话一个）

作者的评价很直白：

爆炸半径极小，但 Claude 能做到的上限也极小——没有持久工作区，也访问不到用户的文件系统。

这带来的是一个传统的威胁模型：

我们不是在保护用户的机器免受 agent 侵害；我们是在保护自己的基础设施、以及租户彼此之间。

然后是最有价值的一句经验：

那份工作强化了安全领域最老的一课：最薄弱的那一层，往往是你自己造的那一层。 gVisor 和 seccomp 面对资源充足的对手被加固的时间，比 agentic AI 存在的时间长得多，所以审查的精力都花在了我们围绕它们构建的更新部件上。

模式二：人工在环的沙箱（Claude Code）

Claude Code 跑在用户的机器上，能访问文件系统、shell 和网络。 没有这些，编码 agent 的用处就有限。

他们为什么敢用「人工在环」：

这之所以对 Claude Code 是个可行的方案，是因为它的平均用户是熟悉编程环境的开发者：他们能读 bash、知道 rm -rf 是什么意思、而且每周已经要从不可信来源跑好几次 npm install。

这意味着当「允许这个」对话框弹出来时，他们很可能会具备评估 agent 想做什么、以及其中风险的专业能力。

但批准疲劳在几周内就出现了。 于是他们加了 OS 级沙箱（macOS 上是 Seatbelt，Linux 上是 bubblewrap）：

读：允许

写：允许（但仅在工作区内）

网络：默认拒绝

效果：权限提示减少了 84%。 而且他们把运行时开源了，所以边界是可审计的。

⚠️ 他们错过的风险：信任对话框之前的一切

在 2025 年年中到 2026 年 1 月之间，我们通过负责任的披露计划收到了 Claude Code 的漏洞报告。其中三个针对的是「在用户同意任何东西之前就执行的代码」。

具体场景：

一个开发者克隆一个仓库来审一个 PR，那个仓库里有个 .claude/settings.json 定义了一个 hook。因为 Claude Code 在启动时会读项目设置——而且在弹出标准的「你信任这个文件夹吗？」提示之前——攻击者提交的那个 hook 会自动执行。

修法的形状是一样的：

把项目本地配置的解析和执行，推迟到用户接受信任提示之后。

如果你在构建类似的东西，请把「打开项目」「加载配置」「本地监听器」当成来自互联网的入站请求来对待。它们不该仅仅因为感觉本地、而且在用户开口之前就到达，就被隐式信任。

模式三：本地 VM（Claude Cowork）

Cowork 面向的是一般知识工作者，不是软件工程师。 作者点出了这里的关键差别：

不应该指望一个非技术型知识工作者去判断 find . -name “*.tmp” -exec rm {} ; 这种 bash 咒语。当批准一个例外需要的专业知识是典型用户所不具备的，管理员就应该设置一个绝对且始终生效的边界。

所以第一版 Cowork 跑在一整个虚拟机里（macOS 上用 Apple 的 Virtualization framework，Windows 上用 HCS）：

• VM 有自己的 Linux 内核、自己的文件系统、自己的进程表

• 只挂载用户选定的工作区和 .claude 文件夹，宿主机上的其他东西都看不见

• 凭据留在宿主机的 keychain 里，永远不进 guest

这里有一个设计细节我认为很值得学：

在最初的架构里——我们称之为全 VM 模式——agent 循环本身跑在 guest 里，所以 Claude 作为一个普通 Linux 用户执行，完全不知道自己被沙箱化了。

对比 Claude Code：那里有一个特权进程坐在沙箱外面，逐条命令决定要不要强制执行它——一个有说服力的注入提示、或者一次疲劳的批准点击，就能让那个进程跑未沙箱化的东西。

而在这里，没有一个外层进程握着逃生门的钥匙，因此也没有任何组件有权授予例外。

但全 VM 模式有实际代价：任何 VM 启动失败都会让 Cowork 不可用。 所以后来他们把 agent 循环移到 VM 外面，只把代码执行留在里面——这样 VM 崩了 Claude 还能响应、还能帮用户调试，而不是直接卡死。

文件挂载也做了分级：只读 / 读写 / 读写但不可删除。

一个我之前没想过的坑：

符号链接的解析必须在路径校验之前，而不是之后，否则一个位于已授权文件夹内的软链可以指向外面并逃逸。

⚠️ 他们错过的风险：通过一个被批准域名的外泄

这个事故我读完觉得很值得单独讲，因为它完美地反驳了「加了沙箱就安全」：

Cowork 的出口 allowlist 正确地放行了发往 api.anthropic.com 的流量——这个产品不调用我们自己的 API 就没法工作。

在这种情况下，一个放在用户挂载工作区里的恶意文件携带了隐藏指令，以及一个攻击者控制的 API key。Claude 按照指令读了工作区里的其他文件，并用攻击者的 key 调用了 Anthropic 的 Files API。

出口代理检查了目的地，看到是 api.anthropic.com，就放行了。文件被上传到攻击者的 Anthropic 账号。

沙箱工作得完美无缺，然而数据还是被外泄了。

他们的重新理解：

之前我们把 allowlist 概念化成目的地过滤器——告诉 Claude 这些域名可以通信。但把它理解为一个能力授予可能更好：任何可通过 allowlist 上任一域名触达的功能，现在都是一个攻击面。

允许 api.anthropic.com 就意味着允许向任意的 Anthropic 账号上传文件。

修法：在 VM 内放一个防御性中间人代理，拦截发往自家 API 的流量，只放行携带 VM 自己预配会话令牌的请求。攻击者内嵌的 key 会被代理拒绝。

而且他们点出了一条更深的道理：

代理放在 VM 里而不是我们的服务器上，因为只有 VM 知道来源——从服务器的视角看，一个 Cowork 请求和任何其他 API 客户端无法区分。

这是「你造的软件往往最薄弱」这条原则的第二个实例。 hypervisor、seccomp 和 gVisor 在我们的产品里一直可靠。失败的是我们自己写的 allowlist 代理。

⚠️ 还有一条我认为最容易被忽略的：

当企业安全团队评估 Cowork 时，他们问：「为什么我们的 EDR 看不到里面？」

答案是：那些把 Claude 关住的隔离，同样地把基于主机的端点检测与响应关在了外面。从 EDR 的视角看，Cowork 是一个不透明的 hypervisor 进程，它没法检查 guest。

隔离会降低可见性，而这种不透明对合规姿态依赖于端点可见性的团队来说是个问题。 我们目前的缓解措施是用基于拉取的 OTLP 导出，让管理员事后取回事件日志，但这和实时监控不是一回事。

三、三者的对照

作者给了一张表，我把它转成文字：

临时容器(claude.ai) HITL 沙箱(Claude Code) 密封 VM(Cowork)

隔离开销 容器启动 低延迟原生沙箱 完整 VM 启动

用户负担 无 必须能读懂 bash 无

爆炸半径 服务端容器 本地工作区 挂载的工作区

(gVisor+主机边界) (工作区边界) (vsock+hypervisor 边界)

作者提炼的选择原则：

把隔离强度匹配到用户的监督能力上。 一个能读 bash 的开发者和一个不能的知识工作者，跑的不是同一个威胁模型。

「用户能不能评估 agent 即将做什么」这个问题，应该帮助决定围堵策略——而两个方向答错都糟：对专家太多摩擦，或对非专家太多信任。

四、往前看：三个正在长出来的风险

① 持久记忆投毒

agent 上下文中跨会话持久的部分持续增长——产品记忆、CLAUDE.md 文件、挂载的工作区，以及定时和长期运行 agent 的状态目录。

任何落进这些地方的注入，都会在 agent 每次启动时被重新加载。 随着更多 agent 状态在会话之后存活，我们在经典的「后利用」意义上受到了新的持久化机制的威胁。

② 多 agent 的信任升级

一方面，子 agent 可以隔离不可信内容，返回结构化事实而不是把原始文本往上传给主 agent。

另一方面，这可以被滥用：如果子 agent 的输出因为「来自我们自己」而被当成比原始工具结果更可信，就引入了一个新的提示注入向量。

在多 agent 系统里，「分配不同信任级别」和「变得容易信任升级」之间有一个取舍。

③ agent 身份

Cowork 对 agent 身份的回答很具体：凭据留在宿主机 keychain，VM 拿到一个按会话缩权的令牌，而且那个令牌可以独立于用户被吊销。

但我们开始纠结一个更大的问题：跨平台的 agent 身份。一个 agent 应该拥有自己的主体身份，还是应该作为用户的延伸、继承用户的权限？

最终答案可能是两者的混合。

五、我认为最值得带走的三条

① 「你自己造的那一层往往最薄弱」

这句话在这个行业里被反复验证。gVisor、seccomp、hypervisor 都被别人用很多年、由资源充足的对手打磨过；而你为了让产品跑起来写的那层胶水，是没人替你打磨的。

② 「allowlist 是能力授予，不是目的地过滤器」

这是我认为全篇最有价值的一句。它把「我允许了这个域名」重新理解为「我允许了这个域名背后所有可达的功能」。 一个看似狭窄的放行，实际打开的是一整片表面。

③ 「当所有概率性的东西都漏掉时，被撞上的是那个确定性的边界」

这句话解释了为什么「加沙箱」比「加检测」更根本——检测有漏检率，边界没有。

链接

原文（Anthropic 工程博客）：https://www.anthropic.com/engineering/how-we-contain-claude

Gemini 的 agent 沙箱文档：https://ai.google.dev/gemini-api/docs/antigravity-agent

Meta 对 Muse 隔离的设计说明：https://research.meta.ai/blog/security-and-safety-for-ai-agents-our-approach-with-muse

#Agent工程 #安全 #隔离