# 基于 Claude AI、Claude Code、Claude Cowork 三款产品工程实践对 Agent 安全的实战总结

- 来源：meng shao (@shao__meng)
- 发布时间：2026-05-27 09:11
- AIHOT 分数：72
- AIHOT 链接：https://aihot.virxact.com/items/cmpne06o90wq5sl01v7z7idhw
- 原文链接：https://x.com/shao__meng/status/2059442456819839447

## AI 摘要

Anthropic 基于 Claude AI、Claude Code 和 Claude Cowork 的工程实践，系统总结了构建安全 AI 智能体的经验。核心原则是防御应随智能体能力演进，并优先使用沙箱来限制破坏性动作。文章详述了三层防御架构（环境层、模型层、外部内容层）及三款产品的隔离模式：Claude AI 使用短暂容器，Claude Code 采用人机协同沙盒，Claude Cowork 则部署密封虚拟机。关键数字包括：Claude Opus 4.7 在 Gray Swan Agent 红队基准上单次攻击成功率约 0.1%，100 次尝试后约 5-6%；Claude Code 自动模式拦截约 83% 的过度积极行为。通过真实攻击案例，强调了环境层防御（如出站阻断）的关键性。

## 正文

基于 Claude AI、Claude Code、Claude Cowork 三款产品工程实践对 Agent 安全的实战总结
https://www.anthropic.com/engineering/how-we-contain-claude

核心设计原则放在最前面
· 先环境层，后模型层 - 确定性边界是最后防线
· 隔离强度匹配用户监督能力 - 开发者能理解 bash，知识工作者不能
· 警惕自建组件 - 优先使用久经考验的标准隔离原语
· 出站白名单应视为能力授权，而非目的地过滤 - 每个可调用函数都是攻击面

三种风险类型
· 用户误用：用户（有意或无意）指示 Agent 执行有害操作，如绕过检查、执行破坏性命令
· 模型行为失当：Agent 未经请求执行有害操作，如"好心"地逃离沙箱、查看 Git 历史获取测试答案、自动识别 benchmark 以破解答案
· 外部攻击：通过工具、文件、网络访问等向量攻击 Agent，包括提示注入和传统运行时攻击

三层防御架构
1. 环境层（最可靠）
· 沙箱、VM、文件系统边界、出站控制
· 核心原则：确定性边界 > 概率性防御
· 若凭证从不进入沙箱，无论何种原因都无法被窃取

2. 模型层
· 系统提示、分类器、探测、训练改进
· Claude Opus 4.7 在 Gray Swan 的 Agent 红队基准上，单次攻击成功率约 0.1%，100 次自适应尝试后约 5-6%
· Claude Code 自动模式拦截约 83% 的过度积极行为

3. 外部内容层
· MCP 服务器、第三方插件、网页搜索
· 关键洞察：审计过的连接器 ≠ 审计过的数据（如 GitHub 连接器可加载被污染的 README）

三款产品的隔离模式对比（模式、实现和场景）
· Claude AI：短暂容器 | gVisor 容器，服务端运行，每次会话文件系统归零 | 通用对话，代码执行
· Claude Code：人机协同沙盒 | Seatbelt（macOS）/ bubblewrap（Linux），允许读、工作区允许写、默认阻断网络 | 开发者工具，需本地文件访问
· Claude Cowork：密封虚拟机 | 完整 VM（Apple Virtualization/HCS），仅挂载用户指定工作区，凭证留在宿主钥匙串 | 知识工作者，非技术用户

关键教训（真实攻击案例）
1. 信任对话框之前的代码执行漏洞
· 问题：Claude Code 在启动时读取 .claude/settings.json（含钩子），此时用户尚未确认"是否信任此文件夹"
· 修复：延迟解析项目本地配置，直到用户通过信任提示

2. 用户作为注入向量（钓鱼攻击）
· 场景：研究员通过邮件发送恶意提示，诱导员工粘贴到 Claude Code
· 结果：24/25 次成功窃取 ~/.aws/credentials 并外泄
· 教训：仅环境防御有效（出站阻断 + 文件系统边界），模型层无法防御"用户本人"的指令

3. 通过已批准域名的外泄
· 漏洞：Cowork 的出站白名单允许 api.anthropic. com，攻击者嵌入 API 密钥，让 Claude 读取文件并上传到攻击者账户
· 修复：VM 内部署防御性中间人代理，仅携带 VM 自有会话 token 的请求可通过

4. 自建组件是最薄弱环节
· 经验：gVisor、seccomp、hypervisor 等久经考验的组件可靠，自定义代理/代理是失败点

未来风险方向
· 持久化内存污染：跨会话记忆的增多使注入可在每次启动时重新加载
· 多 Agent 信任升级：子 Agent 输出若被视为主 Agent 的"更高信任"内容，可能成为新的提示注入向量
· Agent 身份：跨平台 Agent 应拥有独立主体身份，还是继承用户权限？需要混合方案

### 引用推文

> Anthropic：New on the Engineering Blog: The access and permissions we grant agents should evolve with their capabilities. In our own products, we set these parameters thro...