满分漏洞落在框架上，而不是模型上
9 月 9 日披露的一个漏洞，把注意力从模型拉回到了模型运行的地方。编号 CVE-2026-79696，通用漏洞评分 10.0，影响 Google Cloud 的 Python 版 Agent 开发套件 2.0.0 至 2.6.0 版本，触发条件是在环境中安装了测试框架 pytest。攻击者可以借助一段构造好的测试会话重放，绕过一份并不完整的输入拒绝清单，从而以 adk web 进程的身份获得完整的代码执行权限。整个过程中不需要任何登录凭证。
Google 的处理方式分两条：云托管实例由官方直接打补丁；自托管的部署，包括跑在无服务器容器与 Kubernetes 上的实例，需要使用者自己升级。这一点值得单独标出来，因为企业级 Agent 部署里，自托管比例并不低。
为什么「框架漏洞」比「模型漏洞」更难防
过去一年，Agent 安全讨论的焦点大多在模型侧：对齐、越狱、提示注入。这个漏洞提醒的是另一层——即便模型本身是听话的，承载它的框架仍可能把执行权限交出去。
几个结构性原因让这类问题容易被低估。开发调试入口 adk web 是为了方便而设计的，默认暴露在内网甚至公网的情况并不罕见；pytest 属于开发依赖，本不该出现在生产镜像里，但构建流程里顺手装上是很常见的做法；而「输入拒绝清单」这种防护方式天然不完备，攻击者只需要找到清单之外的一条路径。
还需要区分它的性质：这是测试会话重放路径上的漏洞，不是提示注入。它与此前披露的一类编码 Agent 供应链问题属于同一层——问题不在模型会不会被骗，而在模型决定行动之后，它启动的子进程与调用的接口有没有边界。那类问题已有专门的复盘可供参考，这里不再展开。
自信与执行之间，隔着 61 个百分点
如果说框架漏洞是技术侧的提醒，那么 9 月 2 日发布的一项调查则给出了组织侧的对位。这项调查由安全公司与企业管理协会联合完成，覆盖 202 名企业 IT 与安全负责人。
结果里有两个数字放在一起看格外刺眼：94% 的受访者自信他们的 Agent 没有持有超出需要的访问权限；但真正执行了最小权限供给的只有 33%。剩下的自信，建立在「定期审查、很少审查，或者根本不审查」的常驻权限之上。
这种差距并非停留在纸面。65% 的受访者表示，已经出现过 Agent 执行超出预期范围动作的情况；29% 表示这类事件造成了可量化的业务影响，包括数据暴露、财务损失、运营中断或声誉受损。
把两组数据接起来看，逻辑就清楚了：框架层的漏洞决定了「能不能被利用」，权限层的松懈决定了「被利用之后能走多远」。只补一头，风险仍然敞着。
三条可以落地的收敛动作
针对这两类风险，有几件事是可以马上做的。
把 Agent 的身份与人类用户的身份分开。共用一套长期凭证，意味着 Agent 的任何一次越界都等同于一次人工越权，事后也无法区分。独立的身份与按任务的临时授权，能让「它凭什么做这个动作」有据可查。
把开发依赖从生产镜像里剥离。这个漏洞的触发条件之一是测试框架存在，这本身就是一条构建规范的提醒。同时把调试类入口挡在内网，或用鉴权包起来。
把框架本身纳入版本与漏洞跟踪。过去很多团队的软件物料清单只关心模型与业务依赖，框架与开发工具往往不在其中。既然框架开始成为攻击面，它就应该出现在清单里，并配套升级窗口。
几点需要保留的谨慎
其一，10.0 是通用评分，代表理论上的严重程度，实际可利用性取决于部署形态。暴露面小的部署，优先级排序可以不同，但不能因此忽略。
其二，调查样本为 202 家，数据来自受访者自述，「自信」与「执行」都是主观填报，宜作为趋势信号而非精确比例。
其三，框架安全目前缺乏统一的准入清单与评估标准。不同框架的默认暴露面、开发依赖策略与升级节奏差异很大，选型时需要逐项确认，而不是看一句「已通过安全评估」。
其四，「装了测试框架」是简化后的触发描述。真实的利用条件还涉及具体的接口暴露与版本组合，安全团队应回归原始公告，而不是依赖二手转述。
该漏洞的野外利用观测、开发套件各语言版本的受影响范围，以及企业级 Agent 最小权限的第三方审计标准，目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。