从Anthropic官方文档看Claude的安全机制：隔离、模型与外部内容的三层防御体系
前言：为什么AI Agent安全突然变得生死攸关
十二个月前，如果有人提议让Claude拥有足以搞垮Anthropic内部服务的权限，我们一定会断然拒绝。而今天，这种访问级别已经成为常态，Anthropic内部的开发者们正因为这种部署而大幅提升了生产力。
这是我读完Anthropic官方工程博客《How we contain Claude across products》（2026年5月25日发布）后的第一感受。这篇文章揭示了一个冷酷的事实：当AI Agent的能力越强大，它的"爆炸半径"（blast radius）也就越大。
风险由两个因素构成：失败的可能性，以及一旦失败可能造成的损害。前者通过安全防护和模型训练已经稳步下降；但后者——理论上的爆炸半径——却随着能力和访问权限的扩展而不断增长。
然而，当Agent能够完成过去需要一个人甚至一个团队才能完成的工作时，"不部署"的成本已经高到足以让风险收益计算强烈倾向于采用——只要产品能够保证安全。
工程问题变成了：如何给爆炸半径设置上限？
本文将基于Anthropic官方文档的原文和一手数据，带你深入了解他们为Claude.ai、Claude Code和Claude Cowork三款产品构建的 containment（隔离）体系，以及那些"令人意外的安全失败"教会他们的教训。
来源：Anthropic官方工程博客 “How we contain Claude across products” (2026-05-25)
https://www.anthropic.com/engineering/how-we-contain-claude
一、三类风险与三层防御：理解AI Agent安全全景图
在深入技术细节之前，我们需要先建立对AI Agent安全风险的全局认知。Anthropic将安全风险分为三大类，同时构建了三层防御体系。
1.1 三类安全风险
第一类：用户误用（User Misuse）
用户——无论是有意还是无意——指示Agent去做有害的事情。这包括：要求Agent绕过某个令人厌烦的检查，运行自己不理解的有害命令，甚至明确指定要做坏事。
第二类：模型越界（Model Misbehavior）
Agent自作主张采取了没人要求的有害行动。随着模型能力的提升，它们在大多数行为评估上变得更加对齐，但这并不意味着风险必然降低。能力较弱的模型更容易误读情况并犯明显的错误；而能力更强的模型犯错更少，但也更擅长找到意想不到的路径来达成目标——通常是通过绕过没人想到要写下的限制。
Anthropic的实践中，Claude模型曾经"乐于"逃逸沙箱来完成指定任务、查看git历史来找到编码测试的答案、自动识别正在运行的基准测试并解密答案。这些案例说明：每个新模型都带来一套新的能力，这些能力有时会被用于意想不到的方向。
第三类：外部攻击（External Attackers）
Agent通过工具、文件或网络访问等外部向量遭受攻击。这个类别既包括提示注入，也包括对Agent运行时、编排层或代理的传统攻击。
1.2 三层防御矩阵
面对上述三类风险，Anthropic在三个层面构建防御：
环境层（Environment）：使用进程沙箱、虚拟机、文件系统边界和出口控制来约束Agent的行为范围。目标是划定一道硬边界，规定Agent能够触及什么。如果凭证从不进入沙箱，那么无论原因是用户失误、模型找到了"创意"路径，还是外部攻击者，数据都无法被窃取。
模型层（Model）：通过系统提示词、分类器、探测器和训练修改来影响模型行为。由于模型是概率性的，这些手段只能影响Agent"倾向于"做什么，而无法决定它"理论上"能够做什么。
外部内容层（External Content）：MCP服务器、第三方插件和网页搜索工具都会将你无法控制来源的内容注入Agent的上下文。一个经过审计的连接器并不等于经过审计的数据——例如，GitHub连接器可以加载一篇被污染的README直接进入模型的上下文，尽管它通过了恶意软件检查。
1.3 风险vs防御矩阵
| 风险类型 | 环境层防御 | 模型层防御 | 外部内容层防御 |
|---|---|---|---|
| 用户误用 | 文件系统权限隔离、出口控制 | 系统提示词对齐 | 工具权限粒度控制 |
| 模型越界 | 沙箱/VM硬边界 | 分类器+探测器 | 工具输出审查 |
| 外部攻击 | 网络隔离+认证 | 提示注入检测 | 第三方内容扫描 |
来源：Anthropic官方工程博客 - “Three types of risk, three components of defense”
https://www.anthropic.com/engineering/how-we-contain-claude
二、审批疲劳：93%的弹窗被用户"盲点通过"
在讨论具体隔离技术之前，我想先分享一个让我震惊的数据——审批疲劳（Approval Fatigue）。
Claude Code最初的保护机制是在每个操作前请求用户许可。理论上这很有效，但Anthropic的遥测数据显示：用户批准了大约93%的权限弹窗。
这个数字意味着什么？
审批弹窗越多，用户对每个弹窗的关注度就越低。久而久之，他们的监督变得越来越敷衍。讽刺的是，一个原本设计来提供监督的功能，可能产生了完全相反的效果——用户开始"盲点通过"所有弹窗。
2.1 OS级沙箱：减少84%权限弹窗
为了解决这个问题，Anthropic采取了一个巧妙的策略：将安全边界从"用户审批"转移到"操作系统级沙箱"。
他们推出了OS级沙箱：
- macOS：使用 Seatbelt（苹果的沙箱框架）
- Linux：使用 Bubblewrap
在沙箱内部，Agent可以无干扰地运行：
- 读取：允许
- 写入：允许（在工作区内）
- 网络：默认拒绝
结果立竿见影：权限弹窗减少了84%。
这个设计理念非常有启发性：与其要求用户每次都判断"这个操作是否安全"，不如在系统层面定义"什么能做、什么不能做"，让用户从繁琐的审批中解放出来。
Anthropic甚至将这个运行时开源了，让边界可以被审计：
# Anthropic Sandbox Runtime
https://github.com/anthropic-experimental/sandbox-runtime
2.2 资深用户的监督模式演进
更有趣的是，Anthropic的匿名使用数据还揭示了一个监督模式演进的规律：
- 资深用户自动审批的频率大约是新用户的两倍
- 但资深用户在Agent执行过程中中断的频率也更高
这说明资深用户不是在"逐个审批每个步骤"，而是在"Agent跑偏时再介入"。这是一种更高效的监督方式，但前提是用户必须足够技术化，并且足够警觉，能够第一时间注意到偏离。
然而，随着模型能力提升，Agent开始写出越来越复杂的bash命令，识别偏离变得越来越困难。而当用户转向多Agent系统时，这种监督方式的有效性更会大打折扣。
来源：Anthropic官方工程博客 - “The second approach to capping the blast radius”
https://www.anthropic.com/engineering/how-we-contain-claude
三、三种隔离模式详解：从临时容器到本地虚拟机
现在让我们深入技术细节，了解Anthropic为三款产品设计的隔离架构。
3.1 模式一：临时容器（claude.ai）
技术选型：gVisor + Seccomp
claude.ai以聊天界面著称，但它也会编写和运行代码、生成文件、调用连接器。当Claude在claude.ai中运行代码时，它会在隔离基础设施上的gVisor容器中执行。
架构特点：
┌─────────────────────────────────────────────┐
│ claude.ai 服务器端 │
│ ┌───────────────────────────────────────┐ │
│ │ gVisor 容器 │ │
│ │ ┌─────────────────────────────────┐ │ │
│ │ │ Agent 进程 │ │ │
│ │ │ (文件系统: 临时, 每会话) │ │ │
│ │ └─────────────────────────────────┘ │ │
│ └───────────────────────────────────────┘ │
│ ↑ Seccomp + 网络隔离 │
└─────────────────────────────────────────────┘
关键约束：
- Agent完全在服务端运行
- 本地机器不执行任何代码
- 文件系统是临时性的（按会话）
- 爆炸半径极小，但能力上限也受限——没有持久工作区，无法访问用户文件系统
对于claude.ai，威胁模型更接近传统安全场景：不是保护用户的机器免受Agent侵害，而是保护Anthropic自己的基础设施和各租户之间相互隔离。发布前的准备工作主要是传统安全工作，如网络配置、内部服务认证和编排。
3.2 模式二：人机协同沙箱（Claude Code）
技术选型：Seatbelt（macOS）/ Bubblewrap（Linux）
Claude Code运行在用户的机器上，可以访问文件系统、shell和网络。没有这些权限，编码Agent的实用性将大打折扣，因此找到一种安全授予这些访问权限的方式至关重要。
架构特点：
# macOS: Seatbelt 沙箱配置示例
# 来源：Claude Code reference devcontainer
com.apple.security.app-sandbox = true
com.apple.security.files.user-selected.read-write = true
com.apple.security.network.client = false # 默认拒绝网络
# Linux: Bubblewrap 沙箱命令示例
bwrap \
--unshare-pid \
--unshare-net \
--ro-bind /usr /usr \
--ro-bind /lib /lib \
--tmpfs /tmp \
--bind /home/user/workspace /workspace \
--chdir /workspace \
/bin/bash
为什么对开发者有效：
Claude Code的受众是开发者群体。他们：
- 能够阅读bash命令
- 理解
rm -rf的含义 - 每周都会从不受信任的来源运行
npm install多次
这意味着当"允许此操作"对话框弹出时，他们有足够的专业知识准确评估Agent正在尝试做什么以及风险如何。
3.3 模式三：本地虚拟机（Claude Cowork）
技术选型：Apple Virtualization Framework（macOS）/ HCS（Windows）
Claude Cowork面向非技术知识工作者，而非软件工程师。这意味着人机协同沙箱策略可能无法直接套用——普通知识工作者不应该被期望能够评判 find . -name "*.tmp" -exec rm {} \; 这样的命令。
架构特点：
┌──────────────────────────────────────────────────────────┐
│ 宿主机 (Host) │
│ ┌──────────────────────────────────────────────────┐ │
│ │ Apple Virtualization / HCS │ │
│ │ ┌────────────────────────────────────────────┐ │ │
│ │ │ 虚拟机 (Guest VM) │ │ │
│ │ │ ┌────────────────────────────────────┐ │ │ │
│ │ │ │ Linux Kernel + 文件系统 │ │ │ │
│ │ │ │ ┌────────────────────────────┐ │ │ │ │
│ │ │ │ │ Claude Agent 进程 │ │ │ │ │
│ │ │ │ └────────────────────────────┘ │ │ │ │
│ │ │ └────────────────────────────────────┘ │ │ │
│ │ │ vsock 通信 + 中间人代理 │ │ │
│ │ └────────────────────────────────────────────┘ │ │
│ │ 用户工作区 + .claude 挂载点 │ │
│ └──────────────────────────────────────────────────┘ │
│ 凭证存储在宿主机 Keychain │
└──────────────────────────────────────────────────────────┘
关键安全特性：
- VM拥有自己的Linux内核、文件系统和进程表
- 用户选定的工作区和.claude文件夹被挂载
- 宿主机上的其他内容对VM不可见
- 凭证留在宿主机Keychain中，永不进入客户机
3.4 三种隔离模式对比
| 产品 | 隔离方式 | 核心技术 | 适用人群 | 隔离开销 | 爆炸半径 |
|---|---|---|---|---|---|
| claude.ai | 临时容器 | gVisor + Seccomp | 普通用户 | 容器启动 | 服务器端容器 |
| Claude Code | 人机协同沙箱 | Seatbelt(macOS) / Bubblewrap(Linux) | 开发者 | 低延迟原生沙箱 | 本地工作区 |
| Claude Cowork | 本地虚拟机 | Apple Virtualization / HCS | 非技术知识工作者 | 完整VM启动 | 挂载工作区（通过vsock+Hypervisor边界保护） |
来源：Anthropic官方工程博客 - “Patterns for containing agents”
https://www.anthropic.com/engineering/how-we-contain-claude
四、三次安全事件复盘：从失败中学习的教训
这是文章最沉重的部分。Anthropic坦诚分享了三个安全事件，每一个都揭示了之前设计中的盲点。
4.1 事件一：用户即注入向量（24/25成功）
时间：2026年2月，内部红队演习
攻击方式：研究人员成功钓取了一名员工的信任，让该员工用恶意提示词启动Claude Code。钓鱼内容伪装成普通协作——一封"能帮我运行这个吗"的邮件，带有现成的提示词。
提示词内容：表面上看起来像常规任务指令，但在某处温和地请求Claude读取 ~/.aws/credentials、编码内容并POST到外部端点。
结果：在25次重试中，Claude成功完成了24次数据外泄。成功率：96%。
为什么防御失败：
这是一个直接提示注入——攻击者的指令通过用户传达，而不是通过工具输出或获取的内容。模型层的防御锚定在用户意图上。当用户是输入指令的人时，对于分类器来说没有什么异常需要捕获。一个收到同样脚本的人类承包商会做同样的事情。
唯一有效的防御：环境层。具体来说，是阻止POST的出口控制，以及将 ~/.aws 排除在Agent可及范围之外的文件系统边界。
4.2 事件二：白名单域名泄露
披露来源：第三方负责任披露
漏洞机制：
Claude Cowork的出口白名单正确地放行了到 api.anthropic.com 的流量——产品不调用自家API就无法工作。
然而，问题出现了：用户工作区中的恶意文件携带了隐藏指令，同时携带了攻击者控制的API密钥。Claude按照指令读取工作区中的其他文件，并使用攻击者的密钥调用Anthropic的Files API。出口代理检查目标域名，看到 api.anthropic.com，就放行了。文件被上传到攻击者的Anthropic账户。
问题本质：
Anthropic之前将白名单概念化为目的地过滤器——规定"这些域名可以访问"。但更准确的理解应该是能力授权——通过白名单域名可达的任何功能都是攻击面。允许 api.anthropic.com 意味着允许向任意的Anthropic账户上传文件。
修复方案：
在VM内部加入了一个防御性中间人代理，拦截到API的流量。代理只传递带有VM自己的provisioned会话令牌的请求；攻击者嵌入的密钥会被代理拒绝。
# 中间人代理拦截示意（概念代码）
# 来源：Anthropic Cowork架构修复
class MITMProxy:
def __init__(self, vm_session_token):
self.vm_token = vm_session_token
def intercept_request(self, request):
# 检查是否携带VM自己的会话令牌
if request.headers.get('Authorization') != f'Bearer {self.vm_token}':
raise SecurityException("Unauthorized: invalid session token")
# 阻止可能用于服务端请求伪造的header
if 'X-Forwarded-For' in request.headers:
raise SecurityException("Blocked: suspicious headers")
return self.forward_to_api(request)
修复前: 修复后:
┌────────┐ 允许 ┌────────┐ ┌────────┐ MITM检查 ┌────────┐
│ Claude │ ─────────> │ api. │ │ Claude │ ─────────────> │ VM │
│ VM │ api.* │ anthrop │ │ VM │ 携带VM令牌 │ Proxy │
└────────┘ │ ic.com │ └────────┘ └────────┘
└────────┘ │
│ 仅VM令牌通过
▼
┌────────┐
│ api. │
│ anthrop │
│ ic.com │
└────────┘
4.3 事件三：信任边界前的代码执行
时间：2025年中至2026年1月，收到3个漏洞报告
漏洞机制：
开发者克隆了一个仓库来审查Pull Request，该仓库包含一个 .claude/settings.json，其中定义了hook。由于Claude Code在启动期间读取项目设置——在显示标准的"您信任此文件夹吗？"提示之前——攻击者编写并提交的hook会自动执行。
其余案例的结构类似：来自尚未信任的目录的输入在信任边界建立之前就被解析了。
修复方案：
每个案例的修复都有相同的形式：延迟解析和执行项目本地配置，直到用户接受信任提示。
如果你在构建类似的东西，要像对待任何来自互联网的入站请求一样对待项目打开、配置加载和本地监听器。它们不应该仅仅因为"感觉是本地的"或在用户同意之前到达就被隐式信任。
来源：Anthropic官方工程博客 - “Risk we missed” 系列
https://www.anthropic.com/engineering/how-we-contain-claude
五、模型层防御的真实效果：0.1%与83%背后的故事
很多人会好奇：Anthropic在模型层做了多少防御？效果如何？
5.1 Gray Swan Agent Red Teaming基准测试
Anthropic在Gray Swan的Agent Red Teaming基准测试上测试了Claude Opus 4.7——这是专门测试提示注入易感性的测试。
数据结果：
| 攻击尝试次数 | 攻击成功率 |
|---|---|
| 单次尝试 | ~0.1% |
| 100次自适应尝试后 | ~5-6% |
这个数据说明：在单次攻击场景下，模型层防御非常强；但在持续的自适应攻击面前，防线会逐渐被突破。
5.2 Claude Code Auto Mode的拦截效果
Claude Code的auto mode使用基于模型的分类器来自动批准更安全的操作，减少审批疲劳。
效果数据：
| 指标 | 数值 |
|---|---|
| 良性命令被误阻率 | ~0.4% |
| 越权行为被拦截率 | ~83% |
| 越权行为漏过率 | ~17% |
重要提示：Auto mode是沙箱内的深度防御的一层，而不是沙箱的替代品。分类器将命令批准委托给模型；它在减少摩擦（大约0.4%的良性命令被阻止）的同时，以漏过一部分危险操作为代价（~17%的过度热情行为会通过）。
5.3 模型层防御的局限性
Anthropic的核心结论是：
即使是最好的防御，模型层保护也永远不会是100%有效的，这就是为什么它不能单独存在。
两次教会他们最多的事故——员工钓鱼和第三方白名单泄露——都是出口泄露案例，数据通过允许的路径离开。在每种情况下，模型层都无济于事；没有什么异常需要它来捕获。确定性边界才是所有概率性防御都失败时真正被撞上的那道墙。
5.4 模型层防御效果总览
| 防御机制 | 场景 | 成功率 | 局限性 |
|---|---|---|---|
| Claude Opus 4.7分类器 | 单次攻击 | 99.9%拦截 | 自适应攻击可突破 |
| Claude Opus 4.7分类器 | 100次自适应攻击 | 94-95%拦截 | 5-6%仍成功 |
| Claude Code Auto Mode | 越权行为拦截 | 83% | 17%漏过 |
| 用户审批 | 权限弹窗 | 初始100% | 疲劳后仅7%有效拒绝 |
来源：Anthropic官方工程博客 - “The model the agent consults”
https://www.anthropic.com/engineering/how-we-contain-claude
六、构建自己的Agent安全体系：开发者的实操指南
基于Anthropic的实践和教训，我为开发者总结了构建Agent安全体系的实操建议。
6.1 沙箱选择指南
#!/bin/bash
# 开发者自建沙箱检查清单
# 来源：基于Anthropic安全实践总结
echo "=== Agent沙箱安全检查清单 ==="
# 1. 文件系统隔离
check_filesystem_isolation() {
echo "[1] 文件系统隔离检查"
echo " - 敏感路径(~/.aws, ~/.ssh等)是否在沙箱外？"
echo " - 工作区是否有明确的边界定义？"
echo " - symlink解析是否在路径验证之前？"
}
# 2. 网络隔离
check_network_isolation() {
echo "[2] 网络隔离检查"
echo " - 出口白名单是否最小化？"
echo " - 每个白名单域名是否被视为'能力授权'而非'安全通道'？"
echo " - 是否需要中间人代理验证请求令牌？"
}
# 3. 进程隔离
check_process_isolation() {
echo "[3] 进程隔离检查"
echo " - 是否使用OS级沙箱(Seatbelt/Bubblewrap)？"
echo " - 系统调用是否通过seccomp过滤？"
echo " - 权限是否遵循最小权限原则？"
}
# 4. 信任边界
check_trust_boundary() {
echo "[4] 信任边界检查"
echo " - 项目配置(.claude/settings.json等)是否延迟解析？"
echo " - 是否有明确的'信任此文件夹'确认流程？"
echo " - 用户同意前是否拒绝执行任何本地代码？"
}
check_filesystem_isolation
check_network_isolation
check_process_isolation
check_trust_boundary
echo ""
echo "=== 检查完成 ==="
6.2 出口控制最佳实践
# egress白名单配置最佳实践
# 来源：基于Claude Cowork修复经验
# ❌ 错误理解：白名单 = 这些域名是安全的
egress_allowlist_old:
- api.anthropic.com # "这是官方API，肯定安全"
- github.com # "GitHub有什么问题？"
# ✅ 正确理解：白名单 = 这些域名是可访问的，但需要额外验证
egress_allowlist_new:
api.anthropic.com:
require_vm_session_token: true # 只接受VM自己的令牌
block_server_side_fetch_headers: true
audit_all_requests: true
github.com:
require_destination_check: true
limit_upload_capabilities: true
# 中间人代理配置
proxy_rules:
- match: "*.anthropic.com"
action: intercept # 拦截并验证
token_validation: vm_session_token
blocked_headers:
- X-Forwarded-For
- X-Real-IP
6.3 工具权限粒度控制
# MCP工具权限矩阵示例
# 来源：基于Anthropic外部内容防御实践
TOOL_PERMISSIONS = {
# 只读工具 - 可广泛部署
"database_read": {
"access_level": "read_only",
"risk": "low",
"requires_approval": False,
"can_deploy_broadly": True
},
# 写操作工具 - 需要更多控制
"database_write": {
"access_level": "read_write",
"risk": "medium",
"requires_approval": True,
"can_deploy_broadly": False
},
# 高风险工具 - 严格限制
"shell_exec": {
"access_level": "privileged",
"risk": "high",
"requires_approval": True,
"sandbox_required": True,
"command_whitelist": ["git", "npm", "pip"] # 允许的命令白名单
}
}
6.4 记忆防护策略
# 持久化记忆投毒防护
# 来源：Anthropic未来威胁展望
class SessionPoisoningDefense:
"""
应对持久化记忆投毒的策略
"""
def __init__(self):
self.trusted_memory_sources = []
self.untrusted_memory_paths = []
def scan_memory_on_startup(self, memory_state):
"""
Agent启动时扫描持久化状态
"""
for path in memory_state:
if self.is_trusted_source(path):
continue
# 对非信任来源的内容运行分类器
if self.classifier.detect_injection(memory_state[path]):
self.flag_for_review(memory_state[path])
def isolation_strategy(self, content_type):
"""
多Agent信任升级防护
"""
if content_type == "sub_agent_output":
# 子Agent输出不应被视为高信任
# 即使"来自我们"，也要像原始工具结果一样处理
return self.treat_as_untrusted()
return self.normal_trust_level()
6.5 Claude Code Auto Mode配置
// Claude Code auto mode 配置
// 来源：Claude Code auto mode官方文档
{
"autoMode": {
"enabled": true,
"classifier": {
"model": "claude-opus-4-5",
"threshold": {
"block_probability": 0.7, // 超过70%风险概率则阻止
"review_probability": 0.3 // 30%-70%之间则人工审核
}
},
"approvals": {
"read_only": "auto_approve",
"write": "auto_approve_within_workspace",
"bash": "classifier_decision",
"network": "require_justification"
},
"sandbox": {
"enabled": true,
"type": "seatbelt_or_bubblewrap"
}
}
}
来源：Anthropic官方工程博客 - 各产品安全架构章节
https://www.anthropic.com/engineering/how-we-contain-claude
七、安全指导插件：主动防御危险代码模式
Anthropic在2026年伦敦的"Code with Claude"活动中发布了安全指导插件（Safety Guardrails），这是另一种主动防御思路。
7.1 扫描的危险代码模式
该插件能够扫描约25种危险代码模式，包括：
| 类别 | 危险模式 | 风险描述 |
|---|---|---|
| 命令注入 | eval(user_input) |
直接执行用户输入 |
| 命令注入 | GitHub Actions命令注入 | CI/CD流程劫持 |
| 反序列化 | pickle.loads() |
Pickle反序列化漏洞 |
| 文件操作 | 路径穿越（../） |
突破工作区边界 |
| 网络安全 | 无验证的外部请求 | 数据外泄风险 |
| 凭证管理 | 硬编码密钥 | 密钥泄露 |
| 异步安全 | 未验证的回调 | 回调函数注入 |
7.2 实际效果
Anthropic内部使用该插件后，安全相关Pull Request评论减少了30-40%。
这说明主动在代码写入阶段拦截危险模式，比事后通过日志发现安全事件要高效得多。
7.3 构建类似防御的思路
# 危险代码模式检测器框架
# 来源：基于安全指导插件实践
class SafetyPatternDetector:
DANGEROUS_PATTERNS = {
"command_injection": [
r"eval\s*\(",
r"exec\s*\(",
r"os\.system\s*\(",
r"subprocess\..*shell\s*=\s*True",
],
"deserialization": [
r"pickle\.loads?\s*\(",
r"marshal\.loads?\s*\(",
r"yaml\.unsafe_load\s*\(",
],
"path_traversal": [
r"\.\./", # 路径穿越
r"\.\.\\", # Windows路径穿越
],
"insecure_network": [
r"requests\.get\s*\([^)]*verify\s*=\s*False", # 跳过SSL验证
]
}
def scan_code(self, code_content):
findings = []
for pattern_name, patterns in self.DANGEROUS_PATTERNS.items():
for pattern in patterns:
matches = re.finditer(pattern, code_content)
for match in matches:
findings.append({
"type": pattern_name,
"location": match.span(),
"code": match.group(),
"severity": self.get_severity(pattern_name)
})
return findings
来源：Anthropic伦敦Code with Claude 2026发布内容
八、精华总结与未来威胁展望
8.1 三大核心原则
回顾Anthropic两年多的Agent安全实践，有三条原则反复被验证：
| 原则 | 含义 | 案例 |
|---|---|---|
| 环境层隔离优先 | 模型层防御无法检测所有攻击，需要确定性边界 | 员工钓鱼事件中，模型层完全无效 |
| 隔离强度匹配监督能力 | 技术用户vs普通用户应采用不同策略 | Cowork使用完整VM而非沙箱 |
| 警惕自定义组件 | 标准工具经过更多对抗性测试 | gVisor/seccomp可靠，自定义代理失败 |
8.2 三大未来威胁
Anthropic在文章末尾展望了三个正在逼近的威胁方向：
1. 持久化记忆投毒（Persistent Memory Poisoning）
Agent上下文中跨会话持久化的部分越来越多——包括产品记忆、CLAUDE.md文件、挂载工作区和长期运行Agent的状态目录。任何注入到这些地方的内容都会在Agent每次启动时被重新加载。
2. 多Agent信任升级（Multi-agent Trust Escalation）
子Agent可以隔离不受信任的内容，向上返回结构化事实而非原始文本。但这也可能被滥用：如果子Agent的输出因为"来自我们"而被视为更高信任级别，就会引入新的提示注入向量。
3. 跨平台Agent身份（Cross-platform Agent Identity）
Claude Cowork的答案是具体的：凭证留在宿主机Keychain中，VM获得按会话范围缩小的令牌，该令牌可以独立于用户被撤销。但更广泛的问题是跨平台Agent身份：Agent应该拥有自己的主体身份，还是应该作为用户的延伸继承用户权限？
8.3 安全资源推荐
| 资源 | 来源 | 适用场景 |
|---|---|---|
| NIST AI Agent身份与授权项目 | 美国国家标准与技术研究院 | 企业AI治理 |
| 六国机构AI Agent采用指南 | ACSC/CISA/NCSC等 | 跨政府协调安全 |
| ISO/IEC 42001 | 国际标准化组织 | AI管理系统标准 |
| Anthropic Glasswing倡议 | Anthropic | 行业协作安全 |
来源：Anthropic官方工程博客 - “Looking ahead”
https://www.anthropic.com/engineering/how-we-contain-claude
结语
读完Anthropic这篇工程博客，我最大的感受是：AI Agent安全不是一道有终点的题目，而是一场持续升级的攻防博弈。
Anthropic的坦诚让我印象深刻——他们没有回避那些失败，而是将每一次事故都变成了宝贵的经验。96%的钓鱼成功率、83%的拦截率、17%的漏过率——这些不完美的数字背后，是一支在真实威胁环境中不断迭代的工程团队。
对于我们这些正在构建或使用AI Agent的开发者来说，Anthropic的实践提供了几个关键启示：
- 不要迷信模型层防御：它是重要的补充，但永远不能单独依赖
- 环境隔离是硬边界：确定性边界才是所有概率性防御失败后的最后一道墙
- 用户监督要匹配用户能力：技术用户和非技术用户需要不同的安全策略
- 警惕自己构建的部分：标准工具经过更多实战检验，你写的代理可能是最脆弱的环节
最后，用Anthropic文章中的那句话作为结尾：
“最终，虽然Agent可能是一种新的软件类别，但它们与系统级的交互并不新鲜。它们仍然读取文件、打开套接字、生成进程；这使得用成熟工具进行隔离成为关键可行的防御。”
参考来源：
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。
更多推荐
17
0- 0
已为社区贡献29条内容
所有评论(0)