文章总结： GoogleCloud报告指出智能体规模化障碍从模型能力转向基础设施约束,83%组织需升级基础设施,79%技术领导者视安全治理为重大挑战.企业需确保身份可追踪,权限可收窄,运行可隔离,关键动作可确认,过程可回读,失败可回滚.上线前应评估智能体运行权限,守住身份与授权,工具与数据,运行隔离,监督与恢复四个控制点,而非依赖单一平台或提示词约束. 综合评分： 85 文章分类： 安全建设,解决方案,应用安全,数据安全,云安全

Google Cloud发布智能体安全治理报告

原创

AI安全社 AI安全社

AI安全社

2026年8月26日 19:24 湖北

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

8 月 24 日，Google Cloud 发布《Empowering autonomous agents with advanced security governance》，讨论企业把智能体从试点推向生产时遇到的基础设施与治理问题。文章所引用的 2026 年基础设施报告来自 1,402 名全球 IT 领导者，公开页面称，83% 的组织需要升级基础设施，才能支持生产级自主系统；79% 的技术领导者把安全、治理或运营视为扩展推理工作负载时最重大的挑战。

这些比例来自 Google Cloud 的厂商调查，不能直接代表中国企业，更不能证明购买某种全栈平台就会更安全。它们真正值得企业关注的地方，是把一个常见误区暴露出来：智能体在演示环境里能调用邮件、数据库和 API，不等于现有应用基础设施已经有资格让它长期、并发、自动地做这些事。

当智能体开始代表用户跨系统行动，安全问题不再只是模型会不会答错，而是一次调用到底继承谁的身份、能碰哪些数据、谁确认高风险动作、失败后能否停止和回滚。上线前需要确认的，正是这条执行链。

报告的数字说明了什么

Google Cloud调查数字与企业可用结论的边界

Google Cloud 博客还给出三组数字：35% 的高级 IT 决策者把多系统访问的安全不足列为阻碍智能体部署的主要问题；69% 的受访高管认为全栈平台是关键要求；80% 认为数据保护与监管要求是选择平台时的首要因素。它们共同指向一个现实：企业并不缺少能完成局部任务的模型，缺的是能让身份、数据、工具和审计跨系统保持一致的运行基础。

但“全栈”只是可能的实现路径，不是安全结论。把模型、数据和工具放到同一平台，如果仍共用宽权限服务账号、没有工具级策略、关键动作不确认、日志无法关联到具体用户，风险只会被集中。相反，采用多个平台也不必然失控，前提是企业能用统一身份、策略和证据把它们接起来。

| 官方公开数字 | 可以支持的判断 | 不能直接推出的结论 | | — | — | — | | 1,402名全球IT领导者 | 调查有明确样本口径，反映一批管理者的部署压力 | 不能代表所有国家、行业和企业规模 | | 83%认为需要基础设施升级 | 从试点到生产通常需要补运行、治理和容量能力 | 不能推出83%的企业当前都不安全 | | 35%关注多系统访问安全 | 跨系统身份和权限是常见部署阻力 | 不能把所有失败归因于访问控制 | | 69%重视全栈平台、80%重视数据保护 | 控制面一致性和数据边界影响平台选择 | 不能证明单一厂商平台天然更安全 |

企业应先把调查当成一次架构安全复核起点。安全负责人要问的不是“我们有没有智能体平台”，而是现有平台能否回答五个问题：谁发起任务，智能体以谁的名义行动，工具为什么允许这次操作，关键动作由谁确认，事后能否重放完整过程。答不出来，就仍处在功能演示阶段，执行链还没有达到生产安全要求。

智能体不是应用账号的升级版

用户身份、智能体身份与任务授权的传播关系

传统应用常用固定服务账号访问后端。智能体照搬这种方式会出现一个结构性问题：不同用户提出不同任务，后端看到的却始终是同一个高权限身份。模型一旦误解任务、受到间接提示词注入，或者工具参数被污染，原本只需读取一张表的请求，就可能借共享账号触达更多数据和写操作。

Google 的安全人工智能框架（SAIF）把身份传播列为智能体安全的重要方法。其含义不是简单地把用户令牌原样传到底，而是让每一层都能知道实际控制用户、智能体、运行实例和当前任务授权，并在后端重新做权限判断。Google Agent Development Kit（ADK）文档也区分两种常见方式：工具使用智能体自己的身份，或者使用控制用户的身份。

| 身份方式 | 适用条件 | 主要风险 | 必须补的控制 | | — | — | — | — | | 智能体自有身份 | 所有用户权限一致、任务范围稳定 | 共享身份掩盖实际发起人，服务账号容易过宽 | 只读或资源级最小权限、用户归因日志、任务授权 | | 控制用户身份 | 后端已有成熟的用户授权体系 | OAuth范围可能仍大于本次任务所需 | 短时令牌、受众绑定、任务级收窄、敏感动作再授权 | | 混合身份 | 既有公共能力又有用户私有数据 | 切换身份时产生混淆和权限继承 | 每个工具明确身份模式，禁止模型自行选择，跨域调用留痕 |

关键在于，模型不能决定自己使用哪个身份，也不能靠提示词声明“我只做只读操作”。身份模式应由工具配置和策略引擎确定；高权限令牌不能进入模型上下文；授权必须绑定工具、资源、动作、有效期和任务实例。即使采用用户身份，也要继续缩小范围，因为用户可以删除文件，不代表智能体处理一封邮件时就需要删除权限。

身份团队负责令牌签发、传播和撤销，业务系统负责人负责资源授权，智能体研发负责人负责为每个工具声明身份模式。上线前应留存身份链路图、令牌权限、资源策略、过期时间、一次允许调用和一次拒绝调用的审计记录。仅有账号清单，没有任务级授权和实际拒绝证据，就无法证明身份控制已经生效。

智能体上生产要守住四个控制点

智能体上生产要守住的四个安全控制点

Google Cloud 将治理方向概括为默认安全设计、智能体治理与监督、关键动作的人在回路。结合 SAIF 和 ADK 的具体控制，企业可以把上线前核查归纳为四个控制点：身份与授权、工具与数据、运行隔离、监督与恢复。这不是四份制度，而是同一次真实任务必须连续触发的安全检查。

第一个控制点回答“谁在做”。除了登录用户，还要给智能体版本、运行实例和任务建立可关联标识。第二个控制点回答“能做什么”。工具只能暴露业务允许的窄动作，资源范围和只读策略应由开发者设置的确定性上下文提供，不能由模型参数自行扩大。第三个控制点回答“在哪里做”。代码执行、浏览器操作和高风险数据处理要进入隔离环境，出网、文件、密钥和跨用户残留受到限制。第四个控制点回答“何时停”。关键动作触发人工确认，异常任务可以取消，变更有回滚点，执行轨迹能回读。

| 安全控制点 | 在哪个环节管 | 主要责任人 | 最少实现 | 审计与测试证据 | | — | — | — | — | — | | 身份与授权 | 登录、任务创建、后端调用 | 身份安全、业务系统负责人 | 身份传播、短时凭证、任务级授权 | 令牌声明、策略快照、允许与拒绝日志 | | 工具与数据 | 工具注册、参数校验、结果返回 | 智能体研发、数据负责人 | 工具白名单、资源范围、输入输出检查 | 工具清单、参数策略、越权测试记录 | | 运行隔离 | 代码执行、网络访问、状态存储 | 平台工程、云安全 | 沙箱、出网控制、密钥隔离、运行后清理 | 网络策略、镜像版本、清理和逃逸测试 | | 监督与恢复 | 高风险动作、异常处置、变更操作 | 业务负责人、SOC、运维 | 人工确认、取消开关、回滚、轨迹追踪 | 授权记录、完整轨迹、回滚演练、事件工单 |

安全测试必须让控制真正触发。可以构造四类场景：普通用户请求跨部门数据，工具参数尝试访问白名单外资源，代码试图连接出网策略未放行的地址，模型在无工单条件下发起删除或转账。测试结果不只看智能体是否拒绝，还要确认阻断发生在哪一层、凭证是否被撤销、告警是否到达责任人、日志是否足以解释整个过程。

如果某项控制只能在系统提示词里找到，安全控制就没有落到执行层。提示词可以帮助模型选择正确路径，却不能替代后端授权、工具参数校验、网络边界和人工确认。生产环境需要的是模型即使作出错误决定，也无法越过的执行约束。

统一控制面要管到每次工具调用

策略从统一控制面下发并在每次工具调用执行

报告强调集中治理和全栈平台，工程上应理解为“策略和证据必须一致”，而不是“所有组件必须来自同一厂商”。真正的统一控制面至少要维护智能体清单、身份与权限、工具注册、数据分类、运行策略、人工确认条件和审计接口，并把策略下发到每一次模型调用和工具执行。

最容易落空的是工具层。很多团队在网关检查用户输入和模型输出，却让工具拿到参数后直接访问数据库、工单系统或浏览器。ADK 文档建议在工具内部使用开发者确定的上下文，例如限定只能查询指定数据表、只能执行 SELECT，并在工具调用前用回调再次核对用户、参数和运行状态。这类控制的价值在于它不依赖模型是否“记得规则”。

统一控制面还要解决版本问题。模型、系统提示词、工具代码、权限策略和数据连接器任意一项变化，都可能改变执行边界。变更记录应把五者绑定为同一个可追溯版本；策略修改要经过评审和回归测试；紧急撤销时，能够单独停用某个工具或身份，而不是关闭整个业务。

运行时日志也不能只保存最终回答。至少要关联任务标识、控制用户、智能体版本、选择的工具、参数摘要、命中的策略、人工确认、工具结果、状态写入和最终操作。敏感内容可以脱敏或分层留存，但不能只剩一句“任务成功”。否则发生越权或误操作时，企业既无法判断是哪层失效，也无法证明人工确认是否发生在动作之前。

需要特别警惕一种假统一：平台提供了集中仪表盘，但后端工具仍各自使用长期密钥，关键动作日志散落在不同系统，策略变更没有共同版本。仪表盘能展示多少智能体正在运行，不等于能阻止一次越权调用。控制面的判定标准应是策略能下发、动作能阻断、身份能归因、版本能回退、证据能导出。

上线前评估智能体运行权限

从试点到生产的审计证据与安全处置

对管理层而言，最实用的做法是要求每个智能体形成一套上线安全评估证据。它不应是产品介绍或一张架构图，而应包含资产与责任人、身份和权限矩阵、工具与数据清单、威胁场景、测试结果、运行策略、人工确认条件、日志样例、回滚方案和事件联系人。安全团队依据这些材料开放受控权限、收窄为只读、保持隔离测试，或停止运行并执行遏制。

| 安全状态 | 处置动作 | 必须完成的安全动作 | 复测与恢复证据 | | — | — | — | — | | 控制点均生效，拒绝和回滚测试可重现 | 开放受控权限 | 设置容量、异常和权限漂移监控 | 版本记录、基线指标、值班责任人 | | 基础调用可通，但高风险动作仍靠提示词约束 | 收窄为只读权限 | 移除写权限，保留只读和人工代执行 | 后端阻断记录、人工流程、修复期限 | | 共享宽权限账号，无法归因到实际用户 | 保持隔离测试 | 完成身份传播和任务级授权 | 新旧策略对比、越权测试、撤销验证 | | 无法导出执行轨迹，沙箱可出网或回滚失败 | 停止运行并遏制 | 修复隔离、审计和恢复链 | 逃逸复测、轨迹回放、回滚演练 |

责任分工也要写进审计证据。业务负责人决定允许智能体承担哪些操作影响，研发负责人保证工具只暴露必要能力，身份和平台团队落实凭证、隔离与策略，数据负责人确认数据用途，安全团队设计攻击与故障测试，运维和 SOC 负责监控、停用和事件响应。没有业务负责人确认的安全判定，往往只是技术团队确认系统能运行。

上线后还要设置复测触发条件。模型版本更换、工具新增写能力、数据范围扩大、身份模式改变、沙箱或网络策略调整、提示词注入事件、异常调用上升，都应触发局部或完整复测。权限不再使用时要撤销，智能体退役时要关闭凭证、工具和状态存储，并保留最后一次审计与数据处置记录。

Google Cloud 的调查提醒企业，智能体规模化的障碍已经从“模型能不能做”转向“基础设施能不能约束并证明它怎么做”。但安全判断不该停在 83% 或 79% 这些数字上，也不该变成一次平台采购。对每个准备上线的智能体，企业只需坚持一个标准：身份可追踪、权限可收窄、运行可隔离、关键动作可确认、过程可回读、失败可回滚。

这六项都能拿出真实配置、拒绝日志、授权记录和演练结果，才具备开放生产权限的基础。只展示一次成功演示、一个统一仪表盘或一份模型安全说明，仍然只是测试材料。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：AI安全社 AI安全社 AI安全社《Google Cloud发布智能体安全治理报告》