安全智能体接入企业后，最缺的不是告警，而是共同上下文

一条异常登录、一段可疑代码、一次敏感数据外发，常常分散在不同控制台里。安全团队不是不知道发生了什么，而是很难在同一时刻看清：这是谁的身份、正在碰哪份数据、前后关联了哪些动作、现在该由谁按下暂停键。9月29日，Google Cloud 将多家安全厂商的专业智能体接入 Gemini Enterprise，覆盖身份、网络、终端、数据、云和应用等层面。这个产品动作的价值，不在于又多了几个会聊天的安全助手，而在于“业务上下文”开始成为安全自动化的共同底座。

过去，企业习惯按产品采购安全能力：身份系统管登录，终端系统管设备，数据工具管泄露，SOC 管告警。智能体进入这些环节后，问题变成了跨系统的：一个非人类身份先从知识库取数，再调用工单工具，最后准备把结果发给外部对象，谁能把这串行为还原成一次完整的业务判断？如果上下文仍被锁在各自产品里，自动化只会更快地产生更多待人工拼接的线索。

安全智能体真正要接手的，是“串证据”

Google 的新集成给出了几个很具体的方向：Britive 的终止智能体会先确认受影响身份、列出活跃高权限会话，再在人工批准后撤销会话并关闭身份，同时收集审计上下文；Check Point 的方案把 AI 工作负载发现、风险态势、违规行为检测和运行时护栏接到统一环境；Cyera 则试图把机器身份、被委派权限和敏感数据分类关联起来，核验某次智能体行为是否被授权。这些都是厂商能力表述，不能当成通用成效数字，但它们共同指向同一件事：安全响应的产物不该只是“有一条告警”，而应是一份能交接、能审批、能追溯的行动证据。

安全智能体的价值，不是替人把按钮按得更快，而是让人能在按下按钮前看见一条完整、可解释的行动链。

这也解释了为什么“给智能体一个全能权限”并不是捷径。AWS 在9月25日的实践文章中把提示注入、过度自主和信息泄露归为不同风险，却指出它们有共同根源：委派没有被控制。它建议企业逐个梳理智能体的委派点，并在不同措辞、不同文档和不同后果工具上重复测试；检查的不只是最终回答，还要看检索轨迹、策略决定、拟调用的工具参数和最终系统状态。换句话说，安全不只看结果有没有出事，还要看信任在流程中是怎样被一层层交出去的。

先做一张“安全上下文交接单”

对多数企业而言，第一步不是急着替换全部安全平台，而是挑选一个高频、跨系统、但仍可人工兜底的场景，例如异常权限使用、可疑外发，或高风险工单操作。为它建立一张安全上下文交接单，至少包含五项：谁或哪个智能体发起；业务目的和触发信号；碰过的数据、系统与工具；已经执行、拟执行和被阻断的动作；最终由谁在什么条件下批准、回滚或升级。

这张单的重点不是新增一份手工报表，而是规定每个系统要贡献什么证据、智能体能基于什么做判断、人工接管时不用再重新问一遍背景。低风险事件可以自动归并和补证据；涉及高权限、敏感数据或外发动作时，才把带着上下文的建议送给正确的负责人。之后再回看误报、漏报、人工改写与处置耗时，企业才能知道该完善哪条连接、哪个字段或哪项授权，而不是只看到“模型不够聪明”。

STARBOX视角：把安全判断变成可复用的组织能力

在 STARBOX 的组织—BOX—智能体三层里，组织层应先定义哪些安全事件可自动归并、哪些必须人工签收，以及谁拥有升级和回滚权；BOX 层保存资产关系、已确认规则、系统连接、处置记录与版本；智能体层据此检索、串联证据、提出下一步建议，但不越过当前授权边界。DDABC 闭环再把拦截、人工处置和事后复盘沉淀为下一版交接规则。

企业真正需要的，不是让每个安全工具都配一个智能体，而是让它们在关键时刻说同一种“上下文语言”：这件事因何触发，牵涉什么，证据在哪，下一步谁负责。能把这些问题一次交代清楚的安全自动化，才有机会从演示走进日常运营。

来源：Google Cloud《Google Cloud partners deliver new security agents and AI defenses with Gemini Enterprise》（2026-09-29）；AWS《Controlling delegation in agentic AI with Amazon Bedrock Agent Core》（2026-09-25）。文中产品能力均按发布方表述，未外推为行业平均。