智能体平台的漏洞管理

智能体栈有三套打补丁的机制，不是一套。

标准漏洞管理预设了一个均质的世界：CVE 公布、定位受影响版本、部署已修复版本、核验。而智能体部署打破了这份均质，因为栈的三个层次是按完全不同的时钟修东西的。

• 你自己写的代码——工具实现、提示词、编排，以及那些决定智能体被允许尝试什么的胶水。走你的发布列车。补丁时延以小时计，核验就是一个 commit 加一条测试。
• 你自己托管的组件——网关、MCP 服务器、浏览器运行时、沙箱基础镜像、服务栈。别人发现漏洞，你拉镜像、重新部署。补丁时延以天计，核验就是镜像仓库里的一个 digest。
• 厂商运营的智能体服务——那个在你环境里持有一份凭据的 SaaS 智能体。通告送到你手上时，修复早已上线。补丁时延为零，而核验不可能：没有构建号、没有制品、没有回滚。

多数项目完全是为中间那一层建的，而那恰恰是权限最小的一层。凭据在第三层，而它正是你的工具链看不见的那一层。第一步是写下你的每一项智能体能力落在哪一层——和智能体清单与登记册是同一次普查，只不过按"谁来出修复"重新排序。

去盘点凭据，因为凭据就是严重度。

对一个智能体产品来说，未来某个授权缺陷的 CVSS 分数，在缺陷存在之前就已基本定下。一个作用域变更型漏洞——影响从有漏洞的组件外溢进一切信任它的系统——的得分取决于可达集合有多大，而那个集合是你的角色分配，不是厂商的代码。

• 登记的是标识，不是产品。"我们用了一个 SRE 智能体"不是一条台账记录。"服务主体 sre-agent-prod 在三个订阅上持有 Contributor，并可写入运行手册"才是。
• 按"明天若有一道授权检查失效，它能干出什么"给每个标识打分。每个标识只需五分钟，产出的是一份"没人说得出理由的授权"排序表。删掉排在最前面那一项，是这整个栈上杠杆最高的安全动作。
• 按能力与环境拆分标识。一份既能读遥测又能改动基础设施的凭据，会把一个信息泄露缺陷变成一个持久化驻留缺陷。两份凭据则不会——论证见面向智能体的受限凭据。
• 把试点期的授权默认视为已过期。智能体产品在评估期被慷慨开权限，之后几乎从不重新收窄，因为"把一个权限收小"是没人因此受奖励的活。给授权加上到期时间，让默认结果是回收。

一个服务端修复会删掉你项目的大半。要知道拿什么顶上。

拿标准修复步骤去对"无需客户操作"走一遍，多数步骤会当场蒸发。这不是跳过工单的理由，而是写一张不同工单、提不同问题的理由。

• 资产台账学不到任何东西——没有构建号。替代做法：把通告记在那个标识名下，而不是记在某个版本名下。
• 扫描器无法确认修复完成——没有已修复版本可探测。替代做法：把厂商声明作为合规制品归档，并明确注明你无法独立核验。
• 变更管理没有东西可批——变更早已发生，且没走你的窗口。替代做法：对该窗口期间智能体做过什么，做一次回溯复查。
• 没有回滚——你手上唯一可用的逆转动作是撤销智能体的访问权，而那是一个业务决定，不是运维决定。提前定好谁来拍板、多快拍板，见终止开关。

活下来的是三个问题，全都关于你自己的环境：窗口期间那个标识能够到什么、它实际做了什么、你会不会察觉。请注意：这三个问题没有一个能靠"通告送达之后再行动"来回答。

你要重建的那个窗口，起点在披露日之前。

披露告诉你的是修复何时上线。安全团队真正必须推理的区间，起点是缺陷被引入的时刻——而对服务端修复来说，这个时刻通常永远不会告诉你。在厂商另有说法之前，就按"该功能的整个生命周期"来假设。

• 保留期是一项能力，不是一条成本项。如果控制平面日志保留九十天，而该功能是八个月前上线的，那"我们受影响了吗"就永久无解。这是你在一次存储预算会上做的决定，却要在一次事件中才发现——与轨迹采样与保留是同一条论证，只不过用在安全证据上。
• 独立于厂商记录智能体的动作。云厂商的活动日志、你自己的网关日志、你应用的审计轨迹，这些是你的；厂商控制台是它们的，而且可能根本导不出来。这件事要在签约前问，不是在收到通告时问。
• 让人类委托人留在记录上。当智能体替某个用户行动时，审计条目里两者都该写上。而一次断裂的 on-behalf-of 交换恰恰会摧毁这条链接，所以你要把它记在一个智能体控制不了的地方——决策回执与审计。
• 给非人类标识建基线。智能体的凭据有极其规律的特征：稳定的一组资源类型、稳定的一组调用方、跟着触发条件走的节奏。对服务主体做偏离告警，比对人做要好办得多，而几乎没人去做。

别让自托管那一层在光鲜那一层背后烂掉。

你能打补丁的那一层，恰恰是被遗忘的那一层，因为它看起来像普通基础设施，也不会产出带着智能体名字的通告。而它同时是智能体依赖图异常之宽、异常之新的地方。

• MCP 服务器是持有工具调用权限的依赖。其中不少是年轻的、单一维护者的包，而你的智能体是拿生产凭据去调它们的。钉住版本、复查它们能够到什么，并把它们当作一等供应链来跟踪——智能体供应链安全。
• 沙箱与浏览器镜像老化得很快。一个代码执行沙箱或一个无头浏览器就是一整套操作环境；基础镜像以正常速率累积 CVE，却以"你什么时候想起来"的速率被重建。把它排进定时重建，而不是事件驱动重建。
• 网关看得见每一条提示词和每一条回复。它是一个高价值目标，对你智能体经手的一切拥有明文访问权。它配得上认证服务级别的打补丁节奏，而不是代理级别的。
• 模型与运行时升级并非安全中性。一次模型变更可以同时挪动拒绝行为与工具使用可靠性；把它当作一次需要同样评测的变更来处理，见模型下线与迁移。

趁你还有筹码的时候，把厂商条款写进去。

以上一切的上游，是一次只发生一次的采购对话——在签约之前，在厂商还想要这单生意的时候。两个问题承担了大部分工作，而它们都不在标准安全问卷上。

• 对于无需客户操作即完成的修复，你们的通知承诺是什么？"我们在服务端修复"只有在你被告知的前提下才是好处。要一个明确的时限和一条指名的渠道，并核实它是否覆盖内部发现的漏洞，还是只覆盖有 CVE 编号的那些。
• 我能不能导出智能体在我租户内动作的控制平面日志？如果答案是"一个能看但不能查询的控制台"，那 STEP 4 你就跑不了，这一点现在就该算进价钱里。
• 智能体在下游用的是什么身份，能不能按能力分别限权？一个只支持单一宽泛托管标识的产品，已经替你把严重度上限定死了。
• 退出路径是什么？在事件中途撤销访问权，不该顺手弄停一条没人有手工替代路径的工作流——其余部分见退出托管智能体运行时与第三方模型与供应商风险。

相关：智能体威胁模型看这件事在其他攻击路径中的位置，面向智能体的事件响应看响应本身怎么跑，以及重大事件报告看披露义务反向流动时该怎么办。