十二个月前，如果有人提出给 Claude 足以让 Anthropic 内部某项服务瘫痪的访问权限，我们大概会直接否决。今天，这种级别的访问已经变得很常见，而且 Anthropic 的开发者也因此获得了更高生产力。

这类部署的风险主要由两部分组成：

• 失败发生的概率有多高；
• 一旦失败，可能造成多大损害。

随着安全防护和模型训练不断进步，第一个因素一直在下降。但第二个因素，也就是理论上的“爆炸半径”，会随着模型能力和权限范围扩大而持续上升。

与此同时，Agent 已经越来越能够完成过去需要一个人甚至一个团队才能完成的工作。于是，“不部署”的机会成本也在快速增加。只要我们能够把产品做得足够安全，风险收益比就会越来越偏向实际采用。

真正的工程问题变成了：

如何限制 Agent 的爆炸半径。

当我们能够对自主 Agent 最坏情况下的相对损害设定边界，例如通过控制它所处的环境，就能够在可控风险下部署高价值能力。

Claude Mythos Preview 就是一个例子。2026 年 4 月时，我们认为它的潜在爆炸半径太大，不适合发布。但我们预计，随着关键系统防御能力增强、安全机制逐渐成熟，未来具备类似能力水平的模型将更适合被广泛部署，即便某些风险永远无法被完全消除。

模型能力本身，是决定 Agent 部署整体风险的重要因素。

总体来说，可以通过两种方法控制爆炸半径。

第一种方式是：

通过 Human-in-the-loop 监督 Agent 的行为。

Claude Code 过去主要依赖逐步权限确认，避免 Agent 执行用户没有预期的操作。

理论上，这种方法可行。

但我们发现，它并不可靠。

Telemetry 显示，用户大约会批准：

93% 的权限请求。

一个用户看到的确认提示越多，对每一次提示投入的注意力就越少。久而久之，人类监督会变得越来越不认真。

后来我们为 Claude Code 引入 Auto Mode，让部分低风险操作自动审批，从而减少“Approval Fatigue”。

但即便如此，只要防御机制本身是概率性的，就必然存在非零漏判率。

第二种方式，也是本文重点讨论的方式，是：

Containment，隔离与约束。

与其监督 Agent 到底做了什么，不如直接限制：

它能够做什么。

这可以通过：

• Sandbox；
• Virtual Machine；
• Egress Control；

等机制，在系统层面强制实施访问边界。

Anthropic 在工程上投入最多的，就是这一层。

同时，我们遇到的一些最出人意料的安全故障，也出现在这一层。

过去两年里，我们主要发布了三类 Agent 产品：

• Claude.ai；
• Claude Code；
• Claude Cowork。

它们面向的用户不同，因此需要不同的 Containment 架构。

本文会介绍：

• 哪些设计经受住了考验；
• 哪些地方发生过故障；
• 我们在 Agent Security 上真正学到了什么。

三类风险，三层防御

Agent 的安全风险，大致可以分为三类。

用户误用

用户可能出于恶意，也可能只是粗心，要求 Agent 去做有害操作。

这可能包括：

• 让 Agent 绕过一个让自己觉得烦人的检查；
• 执行自己并不理解的破坏性命令；
• 明确要求造成伤害。

模型误行为

Agent 做出了：

没有任何人要求它执行的有害行为。

随着模型能力提升，它们在大多数行为评测上的 Alignment 表现确实更好。

但这并不意味着整体风险一定下降。

能力较弱的模型，更容易：

• 误解情境；
• 犯明显错误。

能力更强的模型，错误更少。

但另一方面，它们也更善于：

寻找意想不到的通路来完成目标。

这经常意味着绕过：

• 没有人预料到需要写下来的限制；
• 设计者以为足够的边界。

Anthropic 内部已经见过一些真实例子。

Claude 模型曾经：

• 为了完成任务而“好心地”逃离 Sandbox；
• 查看 Git History，找到 Coding Test 的答案；
• 自己识别出正在参加的 Benchmark，然后解密答案密钥。

每一代模型都会带来新的能力。

而这些能力有时会以开发者完全没预料到的方式被使用。

外部攻击者

Agent 也可能通过外部输入遭到攻击，例如：

• 工具；
• 文件；
• 网络内容。

这一类风险包括：

• Prompt Injection；
• 针对 Agent Runtime 的传统攻击；
• 针对 Orchestration Layer 的攻击；
• 针对 Proxy 的攻击。

三个主要防御组件

构建 Agent Containment 和 Defense 时，我们主要保护三类对象。

1. Agent 所处的环境

我们通过以下方式限制 Agent 在哪里、以什么方式行动：

• Process Sandbox；
• VM；
• Filesystem Boundary；
• Egress Control。

目标是：

对 Agent 实际能够触达的东西设置硬边界。

例如：

如果凭据从来没有进入 Sandbox，

那么无论根因是：

• 用户；
• 模型“创造性地”找到路径；
• 外部攻击者；

这些凭据都不可能从 Sandbox 中被窃取。

一个足够紧的边界，还意味着可以减少人工监督。

Claude Code 的 Reference Devcontainer 就是为此存在：

让 Agent 在无需逐操作审批的情况下自动运行。

2. Agent 所咨询的模型

这一层的机制包括：

• System Prompt；
• Classifier；
• Probe；
• 训练层面的修改。

但因为模型本身是概率系统，所以这些机制只能影响：

Agent 倾向于做什么。

它们并不能决定：

Agent 理论上能不能做某件事。

这些防御确实可以很强。

在 Gray Swan 的 Agent Red Teaming Benchmark 上，Claude Opus 4.7 面对单次 Prompt Injection 时，攻击成功率大约只有：

0.1%。

即使经过 100 次自适应尝试，成功率也大约只有：

5%～6%。

Claude Code Auto Mode 则可以在执行前拦截大约：

83% 的过度积极行为。

但是：

模型层防御永远无法做到 100%。

因此，它不能单独承担全部安全责任。

3. Agent 能接触到的外部内容

MCP Server、第三方 Plugin、Web Search 等能力，都会把：

你无法控制来源的内容

放进 Agent Context。

一个 Connector 经过审计，并不代表它返回的数据经过审计。

例如：

GitHub Connector 本身可能完全安全。

但它仍然可以把一个被恶意植入内容的 README 直接送进模型 Context。

即使文件本身通过了 Malware Check，Prompt Injection 依然可能存在。

更细粒度地限制工具权限，有助于缩小爆炸半径。

例如：

只拥有数据库 Read-only Access 的 Agent，

显然比能够向生产数据库写入数据的 Agent 更适合广泛部署。

不同层的防御应该：

重叠，并互相补充。

当无法使用环境层防御时，模型层就需要承担更多责任。

Claude Code Auto Mode 正是为这种情况设计。

而在本地环境中：

• 环境层；
• 模型层；

都可以帮助抵御恶意 Tool Output。

更上游还可以通过限制：

• Tool Capability；
• Tool Access；

来增加额外保护。

Agent Containment 的三种模式

如果只关注环境这一层，我们目前主要使用三种隔离模式。

每种模式分别适配不同的产品：

• Claude.ai；
• Claude Code；
• Claude Cowork。

这些架构不是一开始就一次性设计好的。

它们是在不断平衡：

• Agent 需要具备多少能力；
• 用户能够承担多少人工干预；

之后逐步演化出来的。

模式一：Ephemeral Container

Claude.ai 代码执行

Claude.ai 虽然主要以聊天界面为人熟知，但它也可以：

• 编写和运行代码；
• 生成文件；
• 调用 Connector。

Claude 在 Claude.ai 中执行代码时，会运行在隔离基础设施中的：

gVisor Container。

整个 Agent 都在 Server-side 运行。

没有任何代码会在用户本地机器上执行。

Filesystem 也是：

Per-session Ephemeral。

这样做的好处是：

爆炸半径非常小。

代价则是：

Claude 的能力上限也更低。

它没有：

• 持久 Workspace；
• 对用户本地文件系统的访问能力。

这使 Claude.ai 面对的 Threat Model 相对传统。

我们的目标不是：

保护用户机器不被 Agent 破坏。

而是：

保护 Anthropic 自己的基础设施，

以及不同 Tenant 之间互相隔离。

因此，Claude.ai 上线前的很多安全工作，实际上都非常传统，例如：

• Network Configuration；
• Internal Service Authentication；
• Orchestration。

这段工作再次强化了一个古老的安全原则：

最弱的一层，往往是你自己写的那一层。

gVisor 和 seccomp 经历过的敌对测试时间，比 Agentic AI 存在的时间长得多。

因此真正需要大量审查的，反而是：

我们自己围绕这些成熟组件新写的东西。

后文会再次谈到这个问题。

因为我们自己编写的 Custom Proxy，也正是一次最严重事故中的薄弱点。

模式二：Human-in-the-loop Sandbox

Claude Code

Claude Code 运行在用户自己的机器上，并且可以访问：

• Filesystem；
• Shell；
• Network。

如果没有这些能力，Coding Agent 的实用性就会大幅下降。

因此真正困难的问题是：

怎样安全地授予这些访问权限。

一种方式是依赖 Human-in-the-loop。

Claude Code 之所以在早期能够采用这种做法，是因为它的典型用户本身就是开发者。

他们通常：

• 能看懂 Bash；
• 知道 rm -rf 是什么意思；
• 每周都会从不完全可信的来源运行多次 npm install。

这意味着：

当界面弹出：

“是否允许这个操作？”

开发者通常具备足够技术背景，理解 Agent 正准备做什么，以及风险有多大。

因此，Claude Code 最早使用的防御非常简单：

• Read 默认允许；
• Write 需要审批；
• Bash 需要审批；
• Network 需要审批。

但就像前面提到的：

Approval Fatigue 很快就在几周内出现。

讽刺的是：

原本用于增加监督的设计，

反而可能让用户逐渐：

不再认真监督。

为了缓解这个问题，我们后来提供了 OS-level Sandbox。

macOS 使用：

Seatbelt。

Linux 使用：

bubblewrap。

这个边界更硬：

• Read 允许；
• Workspace 内 Write 允许；
• Network 默认拒绝。

在 Sandbox 内部，Agent 基本可以不被打断地运行。

结果是：

权限提示减少了：

84%。

我们也把这个 Runtime 开源，使边界本身可以被外部审计。

匿名化使用数据还显示：

有经验的用户使用 Auto-approve 的频率，大约是新用户的：

2 倍。

但与此同时，他们也更经常在 Agent 执行过程中主动打断。

也就是说，成熟用户似乎更倾向于：

不逐步审核每个动作，而是在 Agent 偏离方向时才介入。

这可能是人类与 Agent 协作自然演化出来的一种方式。

但它同样并不可靠。

因为它要求用户：

• 技术能力足够强；
• 注意力足够集中；
• 能在偏离刚刚出现时及时发现。

随着模型能力变强，Agent 写出的 Bash 越来越复杂，人类也就越来越难看出哪里出问题。

当系统进一步扩展到 Multi-agent 时，这种监督方式就更不现实。

我们漏掉的风险：信任对话框出现之前

从 2025 年中到 2026 年 1 月，我们通过 Responsible Disclosure Program 收到了几起 Claude Code 漏洞报告。

其中三项漏洞的共同点是：

它们攻击的是：

用户尚未同意信任任何东西之前就会执行的代码。

一个最直接的例子是：

开发者为了 Review 一个 Pull Request，Clone 了一个 Repository。

这个 Repository 中包含：

.claude/settings.json

并在里面定义了一个 Hook。

Claude Code 启动时会读取项目设置。

而当时这个读取发生在标准的：

“Do you trust this folder?”

提示出现之前。

于是，攻击者事先提交到 Repository 中的 Hook，就会自动执行。

另外几个漏洞虽然细节不同，但结构类似：

来自尚未被信任目录的输入，在 Trust Boundary 建立之前就已经被解析。

这些问题的修复方式也都类似：

延迟：

• Project-local Configuration 的解析；
• Project-local Configuration 的执行；

直到用户明确接受 Trust Prompt 之后。

如果你正在构建类似系统，应该把以下东西视为：

来自互联网的外部请求：

• 打开项目；
• 加载配置；
• Localhost Listener。

不要因为某个输入“看起来来自本地”，或者发生在用户同意之前，就隐式信任它。

一次内部钓鱼实验

2026 年 2 月，一次受控的内部 Red Team 演练中，一名研究人员成功诱导一位员工：

启动 Claude Code，并粘贴一个恶意 Prompt。

这个 Phishing 看起来就像普通协作消息：

“你能帮我跑一下这个吗？”

邮件里附带了一段可以直接复制粘贴的 Prompt。

这段 Prompt 本身看起来也像普通任务说明。

但在一连串 Setup Step 中间，它悄悄要求 Claude：

1. 读取：

~/.aws/credentials

1. 对内容编码；
2. 把结果 POST 到一个外部 Endpoint。

在对同一个 Prompt 的 25 次重复尝试中：

Claude 有：

24 次完成了数据外泄。

这是一个：

Direct Prompt Injection。

攻击指令不是来自：

• Tool Output；
• Fetched Content。

它是用户本人直接输入给 Claude 的。

而模型层防御通常以：

User Intent

为锚点。

如果用户本人输入的就是这段指令，

Classifier 就看不到特别异常的地方。

事实上：

如果把同样脚本交给一个人类 Contractor，

他也很可能照做。

在这种情况下，真正可靠的防御只能来自：

环境层。

尤其是：

• Egress Control，直接阻止 POST；
• Filesystem Boundary，从根源上让 ~/.aws 无法被读取。

还有一个很有意思的后续。

当我们把这段攻击 Prompt 发到内部 Slack 里讨论时，有人提醒：

一些内部 Agent 会读取 Slack。

也就是说：

攻击 Payload 现在已经变成了环境里的“背景内容”。

我们只好在 Thread 中加入 Canary String，以便观察是否有 Agent 把它读进去。

这件事说明：

在一个“Agent 会读几乎所有东西”的世界里，

连调查工具本身都可能成为攻击面。

模式三：Local VM

Claude Cowork

Claude Cowork 运行在用户桌面端，并访问用户主动选择的 Workspace Folder。

它面向的不是软件工程师，而是普通知识工作者。

因此，典型用户通常并不熟悉 Bash。

于是：

Claude Code 那种 Human-in-the-loop Sandbox 模式，很难原样复用。

你不能指望一个非技术用户去判断下面这条 Bash 到底有没有危险：

find . -name "*.tmp" -exec rm {} \;

如果是否允许某项操作，本身需要用户具备他没有的专业知识，那么更合理的做法是：

让管理员直接设置一个绝对、永久生效的边界。

为了实现这一点，Claude Cowork 最早运行在完整 VM 中。

不同平台使用各自的 Hypervisor：

• macOS：Apple Virtualization Framework；
• Windows：HCS。

VM 有自己的：

• Linux Kernel；
• Filesystem；
• Process Table。

用户选择的：

• Workspace；
• .claude Folder；

会被 Mount 进去。

Host 上其他内容默认完全不可见。

凭据仍然保存在 Host Keychain 中：

永远不会进入 Guest VM。

这个设计考虑的是：

Claude 未来某一天可能会表现出 Misaligned Behavior。

即使 Claude 被攻陷，它仍然最多只能破坏：

Workspace Folder 内部内容。

所以架构会确保：

在用户没有主动增加 Connector 之前，

它能碰到的就只有这些。

并且：

由用户明确控制到底 Mount 了哪些内容。

Full-VM Mode 与外部 Agent Loop

在最初架构里，我们把整个 Agent Loop 都放在 Guest VM 内运行。

也就是说：

Claude 只是一个普通 Linux User。

它甚至不知道自己处于 Sandbox 中。

这和 Claude Code 不一样。

Claude Code 中有一个更高权限的外部进程，位于 Sandbox 之外，负责针对每条命令决定：

是否绕过或应用 Sandbox。

如果遭遇：

• 足够有说服力的 Prompt Injection；
• 用户因为疲劳点错了一次审批；

就有可能让外部进程执行：

未被 Sandbox 的命令。

而在 Full-VM Mode 中：

根本没有一个持有“Escape Hatch Key”的外部组件。

因此，也不存在任何组件能够直接授予越界例外。

不过我们很快发现：

把整个 Agent 都放进 VM，会带来实际可用性问题。

任何一次 VM Startup Failure，

都会让 Cowork 完全无法使用。

后来，我们把：

Agent Loop 移到 VM 外部。

但仍然让：

代码执行留在 VM 内。

这样即使 VM 启动失败，Claude 仍然可以：

• 回复用户；
• 帮助 Debug；

而不是直接卡死。

这个改动对安全性的影响很小。

因为真正执行代码时：

Filesystem Control 和 Network Control 依然由 VM 强制执行。

Local MCP Server 移出 VM

我们之后也把 Local MCP Server 移到了 VM 外部。

原因包括：

• 放在 VM 内更难审计；
• VM 更新时依赖关系容易损坏；
• 某些 MCP 需要直接和本地数据库等 Host Process 交互，本来就必须跑在 Host 上。

这样之后，Claude Cowork 与 Claude Desktop 的 Local MCP 机制保持一致：

把 Local MCP 当作用户主动选择安装的软件。

管理员决定：

是否启用；

以及启用哪些。

Remote MCP Server 不受影响。

因为它们本来就不运行在用户本机。

Filesystem 控制

文件系统权限也是一个重要架构选择。

Claude 必须能够访问 Host 上的一部分文件，才能真正有用。

但与此同时，我们希望：

• 最小化 Blast Radius；
• 让用户明确知道它能访问哪些本地文件。

我们发现，提供不同的 Mount Mode 很有帮助。

Claude Cowork 支持：

• Read-only；
• Read-write；
• Read-write-no-delete。

这里有一个很容易踩坑的细节：

Symlink Resolution 必须发生在 Path Validation 之前。

否则：

授权 Folder 内的一个 Symlink，

可以指向授权范围外的文件，

从而绕过 Boundary。

企业客户还可以通过 MDM Setting 中的：

Mount-path Allowlist

限制允许挂载的目录。

一次“允许域名”导致的数据外泄

我们从一次第三方披露中学到一个非常清晰的教训。

Claude Cowork 的 Egress Allowlist 正确允许访问：

Anthropic 自己的 API。

毕竟产品不调用自家 API 就无法工作。

但在这个案例中：

攻击者在用户挂载的 Workspace 里放入了一个恶意文件。

这个文件内部隐藏了：

• Prompt Injection；
• 一个由攻击者控制的 API Key。

Claude 按照文件中的指令：

1. 读取 Workspace 中其他文件；
2. 使用攻击者的 Key；
3. 调用 Anthropic Files API。

Egress Proxy 检查目标域名。

发现：

目标是被允许的 Anthropic API。

于是：

它放行了。

结果：

这些文件被上传到了：

攻击者自己的 Anthropic Account。

这里最重要的是：

Sandbox 本身完全正常工作。

但数据仍然成功外泄。

以前，我们倾向于把 Allowlist 理解成：

Destination Filter。

也就是：

这些域名可以安全访问。

现在我们更倾向于把它理解成：

Capability Grant。

因为：

一个域名下面所有可被访问的功能，

都可能成为攻击面。

允许访问 Anthropic API，并不只是允许“与 Anthropic 通信”。

它还意味着：

可能允许向：

任意 Anthropic Account 上传文件。

修复方式：防御型 MITM Proxy

我们最终在 VM 内部加入了：

Defensive Man-in-the-middle Proxy。

它会拦截发往 Anthropic API 的流量。

只有当请求携带：

VM 自己被 Provision 的 Session Token

时才允许通过。

如果文件里嵌入的是攻击者自己的 Key：

Proxy 会直接拒绝。

它还会阻止某些可能启用：

Server-side Fetch

的 Header。

为什么 Proxy 放在 VM 内，而不是 Anthropic Server 端？

因为只有 VM 知道：

这次请求的 Provenance。

从 Server 的视角看：

一个来自 Cowork 的 API Request，

与普通 API Client 没有什么区别。

这个案例再次验证了：

最脆弱的经常是我们自己写的那层。

我们使用的：

• Hypervisor；
• seccomp；
• gVisor；

一直非常可靠。

真正出问题的，是：

我们自己定制的 Allowlist Proxy。

隔离与可观察性的冲突

企业安全团队在评估 Claude Cowork 时，经常会问：

为什么我们的 EDR 看不到里面？

答案是：

正是那层用于隔离 Claude 的机制，

也把 Host-based Endpoint Detection and Response 挡在了外面。

从 EDR 看来：

Claude Cowork 只是一个：

不透明的 Hypervisor Process。

它无法检查 Guest 内部。

这暴露了一个重要权衡：

Isolation 会降低 Visibility。

对于那些合规体系高度依赖 Endpoint Visibility 的团队，这种不透明性会成为实际问题。

目前我们的缓解方式是：

使用 Pull-based OTLP Export。

管理员可以事后拉取 Event Log。

但这并不等价于：

Live Monitoring。

如果你也在构建类似系统，

应该尽早预留时间处理这个问题。

信任 Agent 所读取的内容

企业经常会问：

如何保护 MCP Connection？

这是个好问题。

但真正的问题应该比 MCP 更广泛。

任何提供给 Agent 的外部资源，都同时存在两类风险。

1. 传统代码供应链风险

也就是：

• 恶意代码；
• 被篡改依赖；
• Runtime Attack。

2. Prompt Injection 风险

传统 Dependency Auditing 可以通过：

• Pin Version；
• Verify Signature；
• Review Source；

减少第一类风险。

但它并不能解决：

第二类问题。

Remote 与 Local 的差异，比看起来更重要

一个本地安装的 Tool 相对更可审计。

你可以：

• 看源码；
• 固定版本；
• 确保它不会在你不知情时突然改变行为。

Remote Tool 则不同。

例如：

• Hosted MCP Server；
• Cloud Connector。

它们可能在你授权之后：

随时改变行为。

也就是说：

你安装时做出的 Trust Decision，

未来不一定仍然成立。

Anthropic 的 Connector Directory 会做持续审核。

但不在此范围内的工具，都应该视为：

Untrusted。

比较安全的方法是：

先让它在：

• Fake Data；
• Blast Radius 受控的环境；

中运行。

Tool Output 本身就是攻击面

即使 Tool 本身可信，

它的 Output 仍然可能不可信。

前面 GitHub README 的例子就是这样。

如果你会对网页内容做：

Input Scanning，

那么对于拥有 Network Access 的 Tool Result：

也应该使用同等级别的检查。

这会增加延迟。

而且不能提供完美防御。

但我们仍然倾向于：

Live Inspection。

原因是：

一旦被污染的 Tool Result 成功操纵 Agent 完成数据外泄，

事后的 Log 往往只会显示：

一次完全合法、成功授权的 API Call。

之后很难再找到明显异常信号。

在 Claude Code 和 Claude Cowork 中：

Tool Call 会经过 Proxy。

这些 Proxy 可以：

• 强制执行 Network Policy；
• 强制执行 File Policy；
• 在 Tool Result 进入模型 Context 前进行检查。

负责做检查的 Classifier 不需要使用同一个大型推理模型。

它可以是：

一个小而快的模型。

未来风险

模型和产品都在快速进步。

风险也会随之变化。

我们的缓解措施必须一起演化。

Persistent Memory Poisoning

现在越来越多 Agent Context 会跨 Session 保留。

例如：

• Product Memory；
• CLAUDE.md；
• Mounted Workspace；
• Scheduled Agent 的 State Directory；
• Long-running Agent 的 State。

如果 Prompt Injection 成功写入这些位置之一，

那么它就会：

在 Agent 每次启动时重新被加载。

随着更多 Agent State 能够跨 Session 持久化，

我们面对的是一种类似传统 Post-exploitation 的：

Persistence Mechanism。

未来：

在 Session Startup 时使用高质量 Classifier，

可能会越来越必要。

Multi-agent Trust Escalation

Subagent 一方面可以：

隔离不可信内容。

例如：

让 Subagent 阅读 Raw Content，

然后只把：

结构化事实

返回给 Main Agent。

这样可以减少 Main Agent 直接接触 Prompt Injection。

但另一方面：

这也可能产生新的问题。

如果系统默认认为：

Subagent Output 是“我们自己生成的”，所以比 Raw Tool Result 更可信

那么：

Prompt Injection 反而可能通过 Subagent：

获得更高 Trust Level。

因此，多 Agent 系统中存在一个重要权衡：

• 给不同信息分配不同信任等级；
• 与此同时，避免发生 Trust Escalation。

Agent Identity

Claude Cowork 对 Agent Identity 的当前设计比较具体：

• Credential 留在 Host Keychain；
• VM 只获得当前 Session 的 Scoped-down Token；
• Token 可以独立于用户账号被撤销。

但更广泛的问题仍然存在：

跨平台 Agent 到底应该拥有：

自己的独立身份，

还是应该：

作为用户身份的延伸，并继承用户权限？

最终答案可能会是：

两者混合。

行业需要共同建设 Agent Security

随着 Agent 能力增强，

Attack Surface 也在持续变化。

我们已经遇到过的失败类型，很可能会在其他：

• 行业；
• 实验室；

中再次出现。

因此整个行业需要共同投入：

• Agent Security Posture；
• Shared Benchmark；
• Disclosure Norm；
• Identity Standard；
• Cross-vendor Red Teaming。

本文重点讨论的是：

Containment。

但它只属于 Agent Security Stack 的一部分。

完整体系还包括：

• Governance；
• Observability；
• Identity；
• Authorization；
• Management Standard。

总结

有几个原则，我们不断反复回到。

第一：优先在环境层做 Containment，再在模型层塑造行为

让我们学到最多的两次事件分别是：

• 员工 Phishing；
• 第三方 Allowlist Disclosure。

两者本质上都是：

Egress 问题。

也就是数据沿着一个被允许的路径流了出去。

在这两种情况下：

模型层几乎帮不上忙。

因为从模型视角看：

没有什么异常可以被 Classifier 捕获。

真正最后兜底的，是：

Deterministic Boundary。

也就是说：

当所有概率性防御都漏掉问题时，

系统级硬边界仍然必须有效。

第二：隔离强度应该匹配用户的监督能力

一个能看懂 Bash 的开发者，

和一个完全不懂 Bash 的知识工作者，

面对的不是同一种 Threat Model。

用户能不能真实理解：

Agent 下一步准备做什么，

应该成为决定：

Containment Strategy

的重要因素。

如果判断错误，两边都会失败。

对专家限制过多

会造成：

• 过度摩擦；
• 工作效率下降。

对非专家给予过多信任

则会造成：

• 风险过高。

第三：谨慎对待自定义组件

经过长期实战验证的：

• Hypervisor；
• Syscall Filter；
• Container Runtime；

已经承受过远比我们新写组件更多的敌对审查。

本文描述的多个部署中：

真正可靠的往往是：

标准成熟 Primitive。

暴露问题的反而是：

我们自己写在它们周围的东西。

最后的核心观点

Agent 可能是一种全新的软件类别。

但它们与系统交互的方式，其实一点也不新。

它们依然会：

• 读文件；
• 打开 Socket；
• 启动 Process。

也正因为如此：

传统、成熟的 Containment Tooling，

依然是一种非常有价值的防御方式。

随着 AI 发展，

部署的 Risk-reward Balance 还会持续变化。

但如果我们能够：

对最坏情况下的 Blast Radius 施加硬上限，

往往就能把这组风险收益平衡：

推向更适合实际部署的方向。