本月有两个智能体漏洞评分越过 9.0，而它们都与语言模型无关。CVE-2026-62830 拿到 9.9，是因为 Azure SRE Agent 少了一道授权检查，让一个低权限调用方骑上了智能体的托管标识，进而抵达该标识能够到的一切——而微软是在服务端修好的，所以从头到尾就没有一个补丁需要你去打。这个严重度是由你几个月前做出的一次授权设定的，而那恰恰是你唯一控制得了的部分。
一览
微软 2026 年 8 月发布中评分最高的两个智能体漏洞，同一量级，也是同一类缺陷。
| CVE | 产品 | CVSS | 缺陷类别 |
|---|---|---|---|
CVE-2026-62830 |
Azure SRE Agent | 9.9——作用域变更 | 授权缺失；on-behalf-of 流程被打断 |
CVE-2026-59118 |
Microsoft Copilot Cowork | 9.3——无需认证，可经网络利用 | 不当授权（CWE-285） |
两者落在一个约 415 个 CVE、其中 62 个为严重级的补丁星期二里。它们都不是提示词注入的故事，都不涉及越狱，也都不需要攻击者对模型说出任何聪明话。这是那种在 Web 应用里已经出现了二十五年的授权缺陷——只不过这一次，它挡在一份交给"可以自行行动的软件"的凭据前面。
9.9 讲的是你的订阅，不是那个智能体
把 CVE-2026-62830 推到 9.9 而不是 8 点几的，是 CVSS 向量里的一个标志位：作用域变更（Scope Changed）。作用域变更意味着"有漏洞的组件"与"受影响的组件"不是同一个东西——攻破智能体的攻击者拿到的不只是这个智能体，而是跨过一道安全边界，进到了那些信任它的系统里。这一次被跨过的边界是 on-behalf-of 令牌交换，而边界另一头等着的是智能体的托管标识：它能改写的运行手册、能读取的遥测、能驱动的事件处理工具，以及任何人给它授过角色的每一个 Azure 资源。
把这段回读一遍，那个承重的量就明摆着了。CVSS 量的不是智能体有多能干、底下的模型有多好、产品被配置得有多自主，它量的是"经由一个标识可以够到的东西"这个集合有多大。而这个集合不是微软软件的性质，是你的角色分配的性质。
这一点值得内化，因为它远远不止适用于这一个 CVE。一个 SRE 智能体之所以有吸引力，恰恰在于它能动手：重启应用服务、扩容套餐、回滚部署、呼叫值班。这里的每一项能力都是一次角色分配，而这些分配的总和，就是这个产品里"任何一个尚未被发现的授权缺陷"的严重度上限。你选的并不是这个智能体感觉起来有多自主，你选的是一个还没被发现的缺陷的最坏爆炸半径。
Copilot Cowork：同一类，低一档，换了个攻击者
Microsoft Copilot Cowork 里的 CVE-2026-59118 属于不当授权——CWE-285——评分 9.3，而它的向量与 Azure 那个的差异很有教益。它根本不要求攻击者已通过认证，却要求有用户交互，这正是协作类界面缺陷的惯常形状：某个东西送达，租户里有人把它打开，而那道本该拦下随之而来的动作的授权检查从未运行。
这一对之所以重要，是因为它们从两端把智能体的攻击面框住了。Azure 那个是内部路径——一个合法但低权限的主体，借智能体自己的凭据完成提权。Cowork 那个是外部路径——一个未经认证的方，从一个本就设计来接收组织外输入的界面伸手进来。两者绕过的都是控制平面，而不是模型。一个智能体产品就是一个普通的多租户 Web 服务，只不过它手里握着异常宽泛的受托权限；而它也就继承了普通多租户 Web 服务的每一种失败方式。
如果你的智能体威胁模型是一份关于提示词注入的文档，那它讲的只是若干条攻击路径中的一条——而且不是产出本月这两个九分的那一条。智能体威胁模型必须把智能体自身的服务平面当作一项资产纳入，并接受与任何其他服务同等的授权评审。
你的漏洞处置手册里有一个"打补丁"步骤。这一类缺陷没有。
微软在服务端缓解了 CVE-2026-62830，并告知客户无需采取任何行动。这句话对"暴露时长"来说是实打实的好消息，对任何在跑漏洞管理项目的人来说则是实打实的迷失感——因为这类项目里几乎每一项控制，都预设了存在一个可更新的制品和一个可确认的版本。
拿标准步骤去对一个服务端修复走一遍，多数步骤会当场蒸发。没有构建号可记录，资产台账学不到任何东西。没有已修复版本可扫描，扫描器无法确认修复完成。没有回滚，变更管理没有东西可批。也没有维护窗口，因为变更早已发生。剩下的只有一份合规制品——厂商的通告——归档在一项你无法查验的资产名下。
真正活下来的是下面三个问题，而它们问的全是你自己的环境，不是厂商的：
| 问题 | 答案在哪里 | 你必须何时准备好 |
|---|---|---|
| 暴露窗口期间，智能体的标识能够到什么？ | 你当时的角色分配——不是现在的 | 披露之前 |
| 它实际做了什么？ | 控制平面日志，且保留期要覆盖整个未披露窗口 | 披露之前 |
| 你会察觉吗？ | 针对非人类标识异常使用的告警 | 披露之前 |
这三样全都是提前定好的。这就是厂商运营型智能体那个让人不舒服的结构性事实：响应窗口是在厂商已经把洞堵上之后才打开的，所以真正能改变你结局的工作，都是在你还没有任何理由去做它的时候就得做完的。第二行在实践中需要什么，见审计轨迹；第一行见智能体清单与登记册。
暴露窗口比通告暗示的更长
披露日期告诉你的是修复何时上线，它没告诉你缺陷是何时被引入的；而对于安全团队真正必须回答的那个问题——我们被利用过吗——要紧的区间是从引入到修复，不是从公布到修复。对一个服务端修复来说，第一个日期通常压根不会告诉你。
正是在这里，日志保留期不再是一条成本项，而成了一项能力。如果你的 Azure 活动日志保留九十天，而这个功能是八个月前上线的，那么对"我们被利用过吗"的诚实回答是：查不出来；事后再怎么发力也改变不了这一点。团队在这里长期投入不足，因为保留期感觉上像存储，实际上是证据。同一条论证的推广版本在轨迹采样与保留里：你留下什么，决定了以后还有哪些问题答得出来。
对付异常检测那个问题有一条实用捷径：一个 SRE 智能体所用的托管标识，其行为特征极其规律。它触及的资源类型是稳定的一组，来源服务主体是稳定的一组，节奏跟着事件走。相对这条基线的偏离，比人类行为的偏离好告警得多——这是一个值得拿走的优势：非人类标识是你整个环境里最容易建基线的东西，而几乎没人去建。
这应当改变安全预算往哪里投
以上没有一句在说提示词注入不重要；它仍然是这类软件独有的缺陷类别，相应的防御工作也是实打实的。这里论的是比例问题。注意力都在注入研究上；而对智能体控制平面做一次普通的授权评审，才是本月那两个九分的出处——并且那种评审，安全团队本来就会做。
四件事，大致按"对减少八月这次暴露的作用"排序：
- 按岗位授权，不要按路线图授权。智能体产品在试点期被慷慨地开权限，之后再没收窄过，因为"把一个权限收小"是没人因此受奖励的改动。重新收窄范围是这里杠杆最高的动作，而且今天就能做——面向智能体的受限凭据。
- 按环境、按能力拆分标识。一个既能读遥测又能改写运行手册的标识，会把一个信息泄露缺陷变成一个持久化驻留缺陷。两个标识则不会。
- 让人类委托人留在记录上。当智能体替某个用户行动时，审计条目应当同时写下两者。而这恰恰是一次断裂的 on-behalf-of 交换会摧毁的性质，所以它正是你想要独立记录一份的东西——见决策回执与审计。
- 问厂商那两个不好回答的问题。不是"你有没有 SOC 2"——每家智能体厂商都有。问他们对服务端修复的通知承诺是什么，以及你能不能取回智能体在你租户内动作的控制平面日志。这场对话的其余部分见第三方模型与供应商风险。
先做这件事：把你的智能体产品持有的每一个非人类标识列出来，并为每一个写下"如果明天有一道授权检查失效，它能干出的最坏的事是什么"。你至少会找到一项没人说得出理由的授权，而把它删掉，是八月这两个 CVE 里你唯一能施加影响的部分。
常见问题
针对 CVE-2026-62830，我需要做什么吗？
没有补丁可打——微软已在服务端完成缓解，并声明客户无需采取行动。剩下的是一次复查而不是一次修复：审计智能体持有的托管标识分配、对照它实际需要的权限核查 RBAC，并在该标识存在的整个窗口内，于控制平面日志中查找异常的权限使用。
一道缺失的授权检查，在智能体本身并非远程代码执行的情况下，为什么能拿 9.9？
因为 CVSS 向量里的作用域变更标志。作用域变更意味着影响跨过一道安全边界，从有漏洞的组件外溢到其他系统；这里跨过去以后是智能体托管标识被授过角色的一切。分数反映的是可达资源，而那是"该标识如何被开通"的函数，不是智能体代码的函数。
这算不算不该用厂商运营型智能体的理由？
不算——服务端修复把洞堵上的速度，比任何客户侧补丁周期都快。这里换的是：以可核验性换修复速度。你在被告知之前就已拿到修复，同时你没有版本可确认、也没有回滚可做。请把这笔交换当作一次有意识的决定，而不是在收到通告时才发现。
这和提示词注入风险有什么不同？
提示词注入是颠覆模型的行为，让智能体误用它本就合法持有的权限。这两个 CVE 则完全绕开了模型——服务平面里的授权检查失效了，于是攻击者直接使用了智能体的凭据。注入防御在这里帮不上忙，以注入为中心的威胁模型也根本浮不出这一类。
on-behalf-of 流程是什么，打断它为什么后果这么大？
它是那次令牌交换：让一个服务用调用方用户的身份、而不是用自己的身份去调下游资源，从而让下游的权限检查看到的是那个人。当它失效时，下游调用会回落到服务自己的凭据——对智能体来说就是一份宽泛的托管标识——于是调用方继承了从未被授予的权限。
延伸阅读
本站相关：
- 面向智能体的受限凭据——签发、收窄与过期，这些授权定下了你的爆炸半径。
- 智能体身份——一个非人类主体该如何被表示与审计。
- 第三方模型与供应商风险——签约前该问智能体厂商什么。
- 面向智能体的事件响应——当行动方是软件时，响应怎么跑。
- 智能体身份与证明——关于委托与证明的更深处理。
- 推理钩子挪动了 DLP 边界——另一个控制点搬出你代码库的案例。