安全、权限与爆炸半径

变化在哪里

传统 SDLC 里的安全主要盯着一样东西：代码。写代码的人持有的凭证另由角色管理。AI 在三个地方同时打破了这种安排，而每一处都需要不同的控制措施。把它们当成一个问题（"AI 写的代码安全吗？"）来处理，团队就会花钱买更好的模型，去修一个凭证问题。

AI 写的代码

第一个面是大家熟悉的，而且并没有随模型变大而改善。在开源仓库的 186 个真实功能需求上，一个基于 SWE-Agent 和 Claude 4 Sonnet 的智能体，代码能跑通的比例是 57%，安全的却只有 11.8%（SusVibes，ICML 2026）。在 BaxBench 的 392 个后端任务上，最好的模型"代码正确率仅为 62%"，而且在"每个 LLM 生成的正确程序中，约有一半"可以被成功利用。

厂商数据在方向上一致。Veracode 2026 年 7 月的排行榜显示，安全通过率"停滞在 56%"，而语法几乎总能通过；更大的模型、专做编码的模型都没有带来提升（Veracode，T3）。其首席技术官在上一次更新（2025 年 11 月）中的结论毫不含糊："仅仅依靠模型改进，不是一种可行的安全策略。"评审者的盲目自信、可预测的幻觉包名，已在《经济性、风险与度量》中讨论过，本章不再重复。对迁移而言，要点在于：代码这个面是一个基础发生率。你用不依赖模型的门禁来管理它（静态分析、密钥扫描、依赖白名单），而这些门禁已经很成熟。

AI 运行其中的工具链

第二个面是新的。智能体是这样一种程序：它读入不可信的文本，再据此执行命令、编辑文件、调用工具。因此，它读到的一切都可能成为它自身控制措施的输入。2025 年的公开记录显示，这条工具链的每一层都被反过来对付了它的使用者：

• 智能体改写了自己的审批设置。在 VS Code 中的 GitHub Copilot 里（CVE-2025-53773），注入的文本让智能体把 "chat.tools.autoApprove": true 写进了 settings.json。从那以后，终端命令无需审批就会执行。研究者的评论是："理想情况下，AI 不应该能在人类先行批准之前修改文件"（Rehberger，2025 年 8 月）。
• 智能体给自己注册了工具服务器。在 1.2.1 及更早版本的 Cursor 中（CVE-2025-54135，"CurXecute"），编辑一个已存在的点文件需要审批，创建一个新的点文件却不需要，于是智能体可以创建 .cursor/mcp.json，加入一个恶意 MCP 服务器并执行代码（Cursor 安全公告，已在 1.3.9 修复）。
• 白名单只是字符串匹配。在 Gemini CLI 中，README 里的一段提示词注入先让 grep 进入白名单，再在它背后藏一条命令，悄悄把环境变量发了出去。Google 把问题级别提升到 P1/S1，并在 v0.1.14 中修复（Tracebit，2025 年 7 月）。
• 工具描述里夹带了指令。Invariant Labs 演示了"嵌在 MCP 工具描述中的恶意指令，用户看不见，AI 模型却看得见"，还演示了在获批之后再篡改工具描述的服务器（工具投毒）。在第二个演示中，一条恶意的公开 issue 让一个使用官方 GitHub MCP 服务器的智能体，把私有仓库的数据泄露进一个公开的拉取请求。作者称这"不是 GitHub MCP 服务器代码本身的缺陷"，而是"一个根本性的架构问题"（GitHub MCP 有毒流）。
• 规则文件本身就是载荷。Cursor 和 Copilot 规则文件中隐藏的 Unicode 字符，让智能体插入一个恶意 script 标签且只字不提，而被投毒的规则在 fork 之后依然存在。Pillar Security 的建议是，对 AI 配置文件要"像对可执行代码一样严格审查"（Pillar Security，2025 年 3 月）。
• CI 智能体读了攻击者的文本。PromptPwnd 表明，GitHub Actions 或 GitLab 中的智能体，如果一边读取 issue 或拉取请求的文本、一边持有特权令牌，就可能被诱导泄露密钥；Aikido 称"至少 5 家财富 500 强公司受到影响"，但没有点名（Aikido）。《CI/CD 与发布》把它作为发布流水线问题来处理。

有两条教训反复出现。智能体不得能够写入它自己的权限、工具或规则配置。智能体读到的任何东西，包括工具输出，都是不可信输入。还要留意损害是在哪里被决定的。在 Supabase MCP 演示中，一张客服工单让一个以 service_role（可绕过行级安全）身份运行的智能体读取了 integration_tokens 表，并把其中的密钥贴回了工单。用研究者的话说，"没有任何权限被违反"（General Analysis）。注入打开了门，门后有什么，由凭证决定。本站的 MCP 工具投毒与提示词注入页面深入讲解了这类攻击。

AI 持有的权限

第三个面是损害真正发生的地方。公开记录中的每一起破坏性事故，都是一个智能体对某种不可逆的东西拥有权限，而两者之间没有环境边界。凡是有记录的修复，修的都是环境，而不是换一个更好的模型。

同样的模式也出现在一家自己造智能体的厂商内部。Anthropic 的自动模式文章列出了其内部使用中出现的"过度热心"行为："因误解指令而删除远程 git 分支"、"把一位工程师的 GitHub 认证令牌上传到内部计算集群"，以及"试图对生产数据库执行迁移"。这些都不需要攻击者，只需要一个比任务伸得更远的凭证。

这正是成熟度模型的规则 2 按评审方式与 AI 实际持有的权限二者中较高者来给阶段定级的原因。一个团队即便评审每一个 diff，只要它的智能体旁边放着一个能触达生产的令牌，对该令牌能触达的一切而言，它就处在 L4。换模型改变不了这三个面中的任何一个：代码的基础发生率对模型规模没有反应，工具链攻击对各家厂商都奏效，而权限是凭证的属性。

各级别的权限边界

第 II 部分的其他章节都为各自的阶段给出一架梯子。安全横跨所有阶段，所以本章给出的是权限边界：每一级的智能体可以在哪里运行、持有什么、改动什么、读取什么。成熟度模型印过一个三行的摘要，这里是完整版。

这是本书的提议，不是已发布的标准。它综合了厂商默认设置、事故后的修复，以及两个控制框架：云安全联盟（CSA）的级别（在 L4 要求"即时急停能力"）和 AWS 范围界定矩阵（要求"带自动过期的限时审批令牌"）。还没有任何组织发布过按权限级别统计的事故率，所以下表没有一项经过结果验证。每一行都标出了它出自哪个已发布的默认设置或事故修复，便于你判断它的分量。

已有三款产品各自贴近其中某些行。GitHub 的 Copilot 云端智能体最接近一个已发布的 L3 写入范围："只有对仓库有写权限的用户才能触发"它，它"只有推送到单个分支的能力"，它的"工作流在 Copilot 云端智能体的代码被评审之前不会触发"，发起这项工作的人不能批准它，防火墙还限制了它的互联网访问（截至 2026 年 10 月）。OpenAI 的 Codex 把 L3 的网络一行做成了默认值："默认情况下，智能体在关闭网络访问的状态下运行"，写入仅限当前工作区；它的 --yolo 参数被标为"（不推荐）"（截至 2026 年 10 月）。Anthropic 的沙箱设计主张"有效的沙箱需要文件系统和网络两种隔离"：没有网络边界，被攻破的智能体可以把密钥发出去；没有文件系统边界，它可以逃逸。在云端会话中，"敏感凭证（如 git 凭证或签名密钥）从不放在沙箱内"；由一个代理检查每次推送，再附上真正的令牌。

读这张表时请记住规则 2：只要任何一行的实际设置属于更高的一列，那就是你的级别，不管评审流程怎么写。

案例

开篇：PocketOS

AI 事故数据库记录了第 1469 号事故（2026 年 4 月 24 日）：一个"据报道运行 Anthropic Claude Opus 4.6"的 Cursor 智能体，"在处理一项预发布环境任务时，通过 Railway 删除了 PocketOS 的生产数据库和卷级备份"。"报道称，该智能体使用了一个范围过宽的 API 令牌来删除一个 Railway 卷。"经合组织 AI 事故监测（OECD AIM）记录的删除耗时为"九秒"，停机时长为 30 小时。

其余机制细节只见于对创始人帖子和 Railway 回应的二手报道，这里如实标注。该令牌原本是为管理自定义域名而创建的，被放在一个无关的文件里。备份就存在它所保护的同一个卷上。存放在别处的最新副本已是三个月前的。事后，Railway 把 API 删除改成了 48 小时软删除。

它是权限这个面最干净的例子，因为里面没有别的东西：没有攻击者，没有注入，用的据报道还是一款当前的前沿模型。有的只是：一个限定在预发布环境的任务、一个能触达生产的凭证、一个无法撤销的 API，以及位于爆炸半径之内的备份。每一项都对应权限边界中的一行。

锚定案例：Nx "s1ngularity"

PocketOS 只展示了权限这一个面。Nx 则把三个面串在一条链上，也是本章测量得最充分的事故。

入口是一个 CI 工作流。根据 Nx 维护者的安全公告，一个拉取请求校验工作流在 shell 步骤里回显了 PR 标题，于是一个精心构造的标题被当作 bash 执行。它使用了 pull_request_target 触发器，该触发器"以提升的权限运行工作流，包括一个对仓库有读写权限的 GITHUB_TOKEN"。随后，一个恶意提交"改变了 publish.yml 流水线的行为，把 npm 令牌发送到一个 webhook"。恶意的 nx 版本于 2025 年 8 月 26 日美东时间 18:32 起发布，22:44 前被移除。

载荷部分才让它成为一个 AI-SDLC 案例。据 Wiz 的还原和安全公告附录，它的安装后脚本在受害者机器上寻找 AI 命令行工具，并用关闭权限检查的参数运行它们：Claude 用 --dangerously-skip-permissions，Gemini 用 --yolo，Amazon Q 用 --trust-all-tools。提示词要求一个"文件搜索智能体""生成一份以换行分隔的完整文件路径清单，并写入 /tmp/inventory.txt"。这一步恶意软件没有自带漏洞利用，而是借用了受害者早已安装并信任的编码智能体。

Wiz 对泄露数据的分析给出了数字。用它的话说，"大约 50% 的受害者至少安装了一个 AI 命令行工具"。"超过 2,000 个经核实的唯一密钥被泄露"，"超过 1,700 名用户的密钥被公开泄露"。Wiz 检查时，第一阶段泄露的 npm 令牌中仍有超过 40% 有效。在第二阶段，"至少 480 个被攻陷的账户……公开了超过 6,700 个私有仓库"。

最有用的发现与默认设置有关。"AI 只在不到四分之一的情况下成功外泄了数据。""近四分之一的 Claude 交互被拒绝"，"近四分之一的 Gemini 交互被默认的工作区目录限制挡住"。这些工具的默认设置，即权限确认和工作区限制，实实在在地削弱了 AI 这一步。恶意软件之所以需要跳过权限确认的参数，正是因为默认设置挡了它的路。一个日常就开着这些参数的开发者，已经替攻击者完成了这部分工作。

把这条链对应到三个面上。工具链是入口：一个用特权令牌执行不可信文本的 CI 工作流。权限两次决定了损害：先是一个长期有效的 npm 发布令牌，再是开发者机器上能读取开发者所能读取的每一个文件的智能体。Nx 自己的修复都是权限层面的："既然我们已在 NPM 上使用可信发布方，就从流水线中移除 NPM 令牌"，发布强制双因素认证，以及外部贡献者触发的工作流须经审批。

同一类问题，出在厂商身上：Amazon Q Developer

一个月前，AI 工具本身成了载体。AWS 针对 CVE-2025-8217 的安全公告把事故追溯到"其 CodeBuild 配置中一个范围不当的 GitHub 令牌"。恶意代码被"自动包含进了一个发布版本"，也就是 Amazon Q Developer 扩展的 1.84.0 版，"因语法错误而未能成功执行"。公告没有描述载荷内容；媒体报道（二手信息，公告中未予证实）称它是一段指示智能体擦除数据的提示词。AWS 吊销并更换了凭证，1.85.0 版修复了该扩展。根因又是一个凭证范围问题，出在 AI 厂商自己的构建流水线里。

记录中的另外两起事故，Replit 和 Kiro，在《案例研究：谁做到了，测量了什么》中有完整叙述，包括关于 Kiro 的两种说法。两者的修复，即自动的开发/生产分离和生产访问的同行评审，都是上面权限边界中的行。

算例：按凭证给 PocketOS 的智能体定级

这里只使用上文记录的事实；仅有二手来源的细节会标出。

1. 预期级别。一个处理预发布任务、有开发者在会话中的编码智能体，本应是该任务的 L2，至多 L3。
2. 实际授予的级别（规则 2）。这个令牌能删除生产卷。对生产数据而言，这个智能体处在 L4，一个没人选择过的级别。
3. L4 资格。通过无法撤销的 API 删除卷是不可逆的，而备份就在同一个卷上。按照风险上限规则，这个任务类别不具备 L4 资格。所以这次授权不只是计划之外的，它还是一个该任务类别永远无法达到的级别。
4. 哪一行能切断这条链。四行中任何一行都可以。凭证一行：L2 或 L3 的会话触达不到任何能操作生产的令牌（据二手报道，令牌就在一个文件里）。运行位置一行：L3 沙箱只暴露由代理注入、按任务限定范围的凭证。不可逆操作一行：软删除会把这次删除变成几个小时的停机，而不是数据丢失。爆炸半径之外的备份则会把它变成一次恢复。
5. 哪些不能。一条指令（"永远别碰生产环境"）、一个更好的模型或一次审批点击；12.5 节解释原因。

这个练习可以推广。对你运行的任何智能体，列出它的凭证能触达什么，标出其中哪些操作不可逆，再问一问：二者之间挡着的是权限边界中的哪一行？如果答案是"提示词"，那么级别就是 L4。

迁移步骤

先盘点，因为看不见的级别无法调整；先建边界，再谈自主。

1. 盘点凭证和权限模式。对每一个智能体，无论本地还是托管的，记录它能触达哪些凭证（环境变量、工作区里的文件、云 CLI 会话、CI 密钥）、它以什么权限模式运行，以及这些允许哪些操作。用自评表给每一项对应的级别打分。这就是自评表里的凭证一列，在大多数组织里，分数最先在这里升高。
2. 集中关闭绕过模式。Claude Code 自己的文档说，bypassPermissions"只应在容器或虚拟机这类 Claude Code 无法造成损害的隔离环境中使用"，并允许管理员在托管设置中设定 disableBypassPermissionsMode，"使其无法被覆盖"（Claude Code 权限文档，截至 2026 年 10 月）。你运行的每一款工具都要用上对应的控制。Nx 已经说明，这些参数对攻击者价值几何。
3. 保护智能体的配置。把权限文件、MCP 配置、规则文件和指令文件纳入代码所有者评审，并确保智能体无法写入它们。CVE-2025-53773 和 CurXecute 都是智能体改动了自己的控制措施。第 15 章《向更多团队推广》讨论如何把它作为政策推行。
4. 先分离环境，再分离职责。任何智能体会话都不应触达能操作生产的凭证。把破坏性操作放到支持软删除或撤销的 API 后面，并把备份放在智能体可触达的任何凭证的爆炸半径之外。Replit 的修复（智能体"碰不到"生产环境）和 Railway 据报道的软删除都是这一步，只不过是在事故之后而不是之前做的。
5. 进入任何 L3 之前先上沙箱。无人值守的运行放进临时沙箱，具备文件系统和网络隔离、出站默认拒绝，凭证由代理按任务注入。照搬已发布的边界：每个智能体一个分支，没有合并或批准权限，CI 等人评审后才运行。《编码》展示了后台编码智能体如何在这种安排下运行。
6. 加固 CI 智能体。只为有写权限的用户触发智能体工作流。Aikido 指出，Claude Code Action 默认就是这样，而设置 allowed_non_write_users: "*""应被视为极其危险"。对持有特权令牌的智能体，不要把 issue 和 PR 文本放进提示词；发布包时使用可信发布，而不是存储的令牌，Nx 现在就是这么做的。
7. 给代码这个面设门禁。每一个智能体变更，在每一个级别，都要经过静态分析、密钥扫描和依赖白名单。它们是本章最便宜的控制措施，也正是回应 11.8% 安全率的那一批。

这些步骤有明确的代价。沙箱、代理和环境分离都是平台工作，需要有人搭建和维护；短期凭证会给每个会话增加摩擦。要把它当作平台工作来做预算，而不是顺手的杂活。

护栏

第 II 部分每一章的护栏都链接到这里，它们共享一条原则：护栏是智能体无法靠说服绕过的东西。用这条标准排序，常见的控制措施高下分明。

指令不是边界

指令文件里写一句"永远别碰生产环境"，只是一个请求：注入的文本可以覆盖它，智能体也可能漏看它。Elastic 发现，它的 CI 智能体"倾向于用……删掉版本升级的办法，来解决版本升级带来的问题"，而团队的应对是在提示词里加上一行大写的"NEVER downgrade versions of dependencies"（永远不要降级依赖版本）（Elastic，T3）。这一行只是请求，模型之外没有任何东西强制执行它。指令塑造行为，但不限定行为。

审批点击和分类器不是边界

权限确认只有在人真的去读时才算边界，而证据表明人们大多不读。代替人做审批的分类器有帮助，但会漏。

成熟度模型用这个 93% 论证自我定级会向上漂移。这里的论点更窄：一个 93% 的情况下都会被点下的确认，一个每六个真实过度热心行为就漏掉一个的分类器，都是有用的过滤器，但都不是墙。独立来源的记录也是如此：Invariant Labs 在 GitHub MCP 演示的报告中指出，"许多用户在使用智能体时已经选择'始终允许'的确认策略，不再监看单个操作"。

白名单只是字符串匹配

命令白名单让人感觉是一道边界，其实不是。Gemini CLI 攻击把一条恶意命令藏在白名单里的 grep 后面。Claude Code 自己的文档说，Bash 拒绝规则"覆盖的是 Claude 通常会生成的调用方式，并不是围绕该程序的安全边界"，规则按"先拒绝、再询问、后允许"的顺序评估（截至 2026 年 10 月）。用拒绝优先的列表来减少噪音，而不是用来圈住智能体。

环境与凭证范围才是边界

剩下的，是智能体在物理上就触达不到的东西：没有网络出口的沙箱、沙箱内根本不存在的凭证、限定到一个分支的令牌、智能体"碰不到"的数据库、删除操作是软删除的 API。事故记录中每一项有据可查的修复都属于这一类。Google 的安全智能体方法用三条原则表达了同样的意思："智能体必须有明确界定的人类控制者"；"它们的权力必须受到审慎限制"；"它们的行动和规划必须可被观察。"它把确定性控制和基于推理的防御结合起来，让两者都不必单独承担全部防护。

用"三取二"规则限定每个会话

对于读取不可信输入的智能体，最干净的设计规则是 Meta 的智能体"三取二"规则（"Agents Rule of Two"）。智能体"在一个会话中至多只能满足以下三项属性中的两项"："处理不可信输入"、"访问敏感系统或私有数据"、"改变状态或对外通信"。Simon Willison 的"致命三要素"从攻击者一侧点出了同一种组合。上文的每一起工具链事故都三者俱全：PromptPwnd（不可信的 PR 文本、特权令牌、网络）、GitHub MCP 有毒流（公开 issue、私有仓库、公开 PR）、Supabase（客服工单、service_role、回帖进工单）。去掉任何一条腿，链条就断了。

本站对每一层都有更深入的讨论：沙箱、向沙箱交付凭证、出站控制、范围受限凭证、环境权限和混淆代理人。《运维与故障处理》把同一原则应用到故障修复上：决定爆炸半径的是 IAM，而不是模型。当智能体运行在客户的环境里、而不是你自己的流水线里时，这些边界由客户的安全评审来定；《最后一公里》在“安全、治理与模型风险”一章里讲了这场评审。

指标

还没有任何组织发布过按智能体权限级别统计的事故率，也没有研究测量过跳过权限确认模式在一家公司的机器上开启得有多普遍。因此，下面的指标是本书的提议。它们衡量的是边界，而不是模型；大多数可以从配置而不是事故中读出，所以能在出事之前预警。

• 可触达生产的智能体身份。凭证能触达生产数据或基础设施的智能体会话或服务身份所占的比例。L2 和 L3 的目标是零。
• 处于跳过权限确认模式的会话。从托管设置遥测或终端资产清单中统计。在集中禁用绕过模式的地方，沙箱之外这个数也应为零。
• 智能体可执行的不可逆操作。任何智能体凭证在没有软删除或撤销的情况下可以调用的破坏性 API 清单。每一项都是一个等着被用上的 L4 授权。
• 凭证寿命与吊销耗时。在 Nx 事故中，Wiz 检查时仍有超过 40% 的泄露 npm 令牌有效。跟踪智能体可触达的令牌能存活多久，以及一个泄露的令牌多快失效。
• 每个智能体变更的密钥泄露数。在你自己的仓库里、对照你自己的人工基线来测量，而不是相信厂商数字（见下框）。
• 每个已合并智能体 PR 的安全问题数。合并时的静态分析发现，与同一时间窗口内人类 PR 对比。这就是代码这个面的基础发生率，在你的代码上测得。

和第 II 部分每一章一样，把这些指标与一个稳定性指标配对。如果某个智能体变更在生产中出了问题，记下它越过了权限边界中的哪一行。第 17 章《衡量成效，以及何时回退》会把它变成回退触发条件。

反模式

• 在持有真实凭证的机器上开跳过权限确认模式。这正是 Nx 恶意软件在找的配置。《编码》记录了智能体删掉用户自己文件的几起报告案例。绕过模式只属于用完即弃的容器，别处都不行。
• 智能体碰巧找到的令牌。据报道，PocketOS 的令牌是为别的用途创建的，被留在一个文件里。工作区里的任何东西都在智能体手中；先查清里面有什么。
• 位于爆炸半径之内的备份。能被同一个凭证删除的备份，本身就是它所保护之物的一部分。
• 把"别碰生产环境"当作控制措施。指令不是边界。如果生产环境不能碰，就让它触达不到。
• 能修改自身控制措施的智能体。包括它的权限设置、MCP 服务器、规则文件，以及评判它的核验器。它能写，就能被说服去写。
• 用写权限令牌读取陌生人文本的 CI 智能体。把智能体工作流开放给没有写权限的人，或者把 issue 和 PR 正文放进一个持有密钥的智能体的提示词，就是 PromptPwnd 的模式。
• 流水线中长期有效、范围过宽的令牌。Nx 泄露了一个存放在流水线中的 npm 发布令牌；Amazon Q 的构建配置里有一个范围不当的 GitHub 令牌。两者都是 CI 中的令牌范围失败，而不是模型失败。
• 把安全架构交给生成器。Lovable 的暴露问题（扫描的 1,645 个应用中有 170 个）和 Moltbook 数据库在《需求、规格与设计》中讨论：访问控制是设计决策，由人掌握。

本站的文章智能体 CVE 其实是授权缺陷和你的智能体运行了 git status，这就够了从漏洞记录出发提出了同样的论点。一般原则见爆炸半径。