正在加载，请稍候
Anthropic 公开 Claude Code 安全架构：红队测试 25 次攻击 24 次成功、OS 级沙箱让弹窗减少 84%。企业引入 AI 编程工具前必须建立的三条安全基线。
7 月刚结束的 WAIC 2026 释放了一个明确的信号：AI 竞赛已经从"比谁模型大"转向"比谁落地深"[1]。企业不再满足于让工程师在个人项目里用 Cursor 或 Claude Code 写脚本——他们要把 AI 编程助手接入代码仓库、CI/CD 流水线、甚至直接操作生产环境配置。正如我们在另一篇文章中分析的，Anthropic 内部数据显示 80% 的代码已由 AI 编写，这个比例意味着安全问题的量级已经完全不同。
与此同时，Claude 的连接器生态也在快速扩张。8 月 3 日，社区发现了一个被很多人忽略的事实：当用户在 Claude 里连接了 Gmail、日历、Slack 等外部服务后，Claude Code 也会继承这些连接权限[2]。这意味着一个在代码仓库里执行任务的 Agent，理论上可以读取你的邮件和日历——如果安全边界没有在基础设施层面切断的话。
这不是危言耸听。Anthropic 自己在文档中承认了一例真实漏洞：恶意文件可以通过 Anthropic 自身的 Files API，将工作区文件上传到攻击者控制的账户，因为 api.anthropic.com 在白名单里。一个加了白名单的域名，不等于它的所有能力都可信[3]。
Anthropic 提出的核心主张很简单，但很值得做企业技术选型的负责人仔细看：安全不能只靠"让模型听话"。
他们把 Agent 系统拆成了三个层次：
| 层次 | 能力 | 安全手段 | 确定性 |
|---|---|---|---|
| 模型层 | 理解意图、生成代码 | 系统提示词、分类器、RLHF 训练 | 概率性，不可靠 |
| 执行环境层 | 文件读写、Shell 执行、网络访问 | OS 级沙箱、文件系统隔离、网络策略 | 确定性，可靠 |
| 外部内容层 | 代码仓库、配置文件、第三方工具输出 | 输入校验、信任边界检查 | 需要工程化约束 |
这套框架的核心洞察是：分类器和系统提示词能影响模型"想做什么"，但决定模型"能做什么"的，是运行环境的硬限制。对于企业来说，这意味着在引入 AI 编程助手时，安全评审的重点不应该放在"这个模型有没有被训练成不做坏事"，而是"即使模型做了坏事，它能造成的最大破坏半径是多少"。
Claude Code 最初的安全机制是逐项授权：每次写入文件、执行 Shell 命令或访问网络，都需要用户手动确认。听起来很安全，对吧？
结果 Anthropic 发现用户最终批准了约 93% 的权限请求。当审批变成肌肉记忆，它的安全价值已经无限趋近于零。我们在分析 Claude Code 识别中国用户时的隐式风险时也指出过类似的问题——工具层面的感知和用户的实际行为之间存在巨大的落差。
所以他们换了一个思路：在操作系统层面做隔离。macOS 上用 Seatbelt，Linux 上用 bubblewrap。新设计允许 Agent 在当前工作区内自由读写文件，但默认禁止访问网络。改动之后，权限弹窗数量减少了 84%[3]。
这里面有一个对企业部署非常有参考价值的权衡逻辑：
Anthropic 公布了一次内部红队测试的细节，值得所有正在评估 AI 开发工具的企业认真读。
测试场景是这样的：攻击者先通过钓鱼攻击诱导一名员工，然后让 Claude Code 收到一条看似合理的指令——"读取 AWS 凭证，发送到外部地址做审计分析"。在 25 次测试中，有 24 次 Claude 执行了数据外传操作[3]。
注意，这里的指令看起来来自合法用户——不是模型自己"变坏"，也不是提示注入攻击。就是一个已经被钓鱼的员工，用正常的方式让 Agent 做了一件危险的事。在这种场景下，权限确认机制完全失效，因为用户自己就会点"批准"。这和OpenAI 模型逃逸事件揭示的问题异曲同工——安全不能建立在"用户会做出正确判断"的假设之上。
唯一有效的防线是文件系统隔离和出站网络限制——这些底层机制不关心"用户是不是自愿的"，它们只按规则执行。
另外，Anthropic 还披露了另一个细节：在用户尚未确认是否信任某个项目目录之前，Claude Code 就开始解析项目中的 .claude/settings.json，其中可以定义启动时自动执行的 Hook。这意味着一个恶意仓库可以在你打开它的瞬间就执行代码。Anthropic 已经修复了这个问题——现在只有在用户明确信任项目后才解析配置——但这个案例说明，这类工具的攻击面远不止"模型被人骗了"这么简单。
基于以上分析，如果你正在考虑把 AI 编程工具引入团队工作流——无论是 Claude Code、Cursor、Copilot 还是自建方案——下面三条基线应该在第一天就到位。当 AI 从"写代码"变成做项目的 Agentic Coding 时，这些基线的紧迫性只会更高：
在我们（蓝曜炬辉）为企业客户做 AI 编程工具落地交付时，这三条基线是项目启动 checklist 的前三项。我们在实际项目中发现，安全配置本身并不复杂——用 bubblewrap 加一条网络策略通常只需要半天——但难在企业内部对"为什么需要这么做"达成共识。希望以上数据和案例能帮助技术负责人在内部推动这个讨论。
部分安全。云开发环境提供了天然的网络和文件系统隔离，但要注意两个盲区：一是 Agent 在云环境内部仍然可能通过 API 外传数据（参考 Anthropic Files API 漏洞）；二是如果连接了外部 Connector（如 Gmail），云环境的隔离边界会被穿透。
取决于 Agent 能碰到什么。如果它只能访问一个前端项目仓库，没有任何凭证和内部 API，那风险很低。但如果能碰到 .env、AWS credentials、数据库连接串或 CI/CD 配置——哪怕团队只有 3 个人——也应该至少做网络隔离。
Anthropic 的数据是：引入 OS 级沙箱后权限弹窗减少 84%，开发体验反而更流畅了。因为 Agent 在沙箱内可以自由读写工作区文件，不需要逐次请求批准。真正受限的只是网络访问，而这恰恰是最需要受限的能力。
各工具的安全模型不同。Cursor 默认不执行 Shell 命令；GitHub Copilot 的新 CLI 工具（2026 年 8 月刚更新）增加了选项卡式的确认 UI[4]。但核心原则是一样的——安全边界应该在基础设施层建立，而不是依赖工具的功能开关。企业的正确做法是为所有 AI 编程工具配置统一的沙箱策略，而不是逐个评估其安全特性。