Google AI 威胁防御遭遇以机器速度行动的攻击者

Google 记录了第一波进入实战阶段的 AI 攻击：它们将原本需要数小时的侦察、编码和凭据窃取，压缩进单一自动化工作流。该公司 9 月 16 日的安全更新显示，Google AI 威胁防御正面对如今在多个攻击阶段使用智能体的对手。

核心冲突不再是人类分析师与更快的钓鱼文案生成者之间的竞赛。Google 表示，攻击者正将模型、云基础设施、被盗账户和传统黑客工具连接成能够规划和调整行动的系统。一项 Mandiant 调查发现，一场由智能体驱动的凭据攻击在不到六小时内完成。

Google 的应对方案结合了多种模型、内部遥测数据、云环境上下文、自动化调查和软件修复能力。该公司认为，防御方仍具优势，因为他们了解自身的代码、身份、配置和运行时系统。但这一优势只有在组织能够连接这些数据源，并信任自动化防御行动时才会存在。

这一限定至关重要。Google 提供了大量证据，既用于支持其威胁判断，也用于支持其提出的解决方案。来自 NIST 和 MITRE 的独立框架支持更广泛的风险模型，但并未验证每一项产品主张。

结果将成为企业安全领域一次影响深远的考验。攻击者正在缩短意图与执行之间的延迟。防御者必须判断，互联的 AI 系统能否缩短自身的延迟，同时不在网络内部再造一个不透明且拥有高权限的层级。

Google AI 威胁防御始于威胁模型的三项变化

Google 的更新将 AI 视为软件供应链风险、新的攻击面，以及攻击者的运营加速器。

Google Threat Intelligence 副总裁 Sandra Joyce 围绕这三项结构性变化组织了公司的评估。这一论述见于 Google Cloud 9 月版的 Cloud CISO Perspectives。

第一项变化始于软件开发阶段。AI 编程助手可以推荐软件包、生成配置文件、编辑代码库并启动工具。这些能力为投毒依赖项或恶意指令进入可信工作流创造了更多机会。

Google Threat Intelligence Group，即 GTIG，将 AI 辅助编码实践与 2025 年及 2026 年初观察到的大规模软件供应链入侵联系起来。它描述了攻击者同时针对开发者、软件包注册表、AI 助手和自动化扫描器的行为。

UNC6780，也称 TeamPCP，体现了这一模式。Google 表示，这一出于经济动机的组织使用了六种以上涉及 AI 工具和开源开发实践的技术。

据称，其方法包括劫持 AI 工具包、投毒软件包、提示词注入，以及旨在干扰 AI 扫描器的指令。一些恶意文件被隐藏在编程助手和开发环境使用的项目目录中。

这种放置方式很重要，因为 AI 助手可能会将代码库指令解释为合法的项目上下文。因此，开发者可能在未刻意执行陌生二进制文件的情况下继承恶意行为。

Google 表示，UNC6780 还入侵了开发者账户，并发布了被植入木马的 Model Context Protocol 资源。Model Context Protocol，即 MCP，可让 AI 应用连接工具和外部数据。

在另一种技术中，恶意代码试图从持续集成系统中捕获令牌。有效令牌可能让被入侵的软件包在自动化检查中显得可信。

第二项结构性变化涉及 AI 系统本身。模型、提示词、智能体指令、源代码、凭据和计算配额已成为高价值目标。

据 Google 称，Mandiant 在 2026 年第二季度调查了数起数据窃取勒索行动。攻击者窃取了专有模型、提示词、技能、源代码及相关研究资料。

这些事件波及的组织并不限于前沿 AI 实验室。Google 发现受害者分布于北美和欧洲的科技、医疗、媒体和娱乐行业。

该公司还报告称，对被盗 AI 账户的需求持续存在。地下卖家以低至零售价 1% 的价格兜售一些消费者账户。

这些凭据具有多种用途。攻击者可以规避身份检查、模糊归因、访问受限能力，或将推理成本转嫁给受害者。

Google 将这种滥用的一种形式称为 LLMJacking。攻击者窃取云访问权限并部署未经授权的 AI 工作负载，最终由受害者承担基础设施消耗成本。

第三项变化涉及运营节奏。最新的 AI 威胁追踪报告描述，对手正从孤立的提示词转向智能体工作流。

智能体 AI 是指能够选择行动、使用工具、评估结果，并在较少人工监督下持续朝目标推进的软件。这种自主性能够消除传统攻击阶段之间的停顿。

这些类别都并非全新。软件包投毒、凭据窃取、云资源滥用和自动化扫描在生成式 AI 出现前就已存在。

改变的是它们的整合方式。模型可以将自然语言目标转化为脚本，排查失败步骤，选择工具，并将操作指令保存在可复用文件中。

这种整合形成了本文的核心张力。Google 认为，机器速度的攻击正从熟悉的技术中涌现，而许多安全团队仍通过彼此割裂的队列调查这些技术。

一场六小时凭据攻击说明安全团队为何承压

最重要的发展并非新的黑客原语，而是规划、执行与规模化之间的时间差正在消失。

2026 年第二季度，Mandiant 调查了一起入侵事件，其中受入侵的云基础设施内部运行着自主多智能体框架。Google 将该活动归因于一名疑似出于经济动机的行为者。

攻击者使用了一个 AI 编程聊天机器人、一段提示词和预先准备的智能体指令。这些组件共同在不到六小时内规划、构建并执行了大规模凭据收集。

Google 表示，该框架在有限人工干预下管理漏洞扫描、解决操作错误并处理 IP 轮换。最终，它入侵了数千组第三方凭据。

从受害者的云环境运行还带来另一项优势。攻击流量来自合法基础设施，而非显然具有恶意的服务器。

六小时这一数字需要谨慎解读。它来自一场被调查的攻击活动，而非行业范围的中位数。Google 尚未公布足够多的可比案例来确立普遍的加速幅度。

不过，该案例表明现有安全运营为何面临压力。人类分析师通常在工具分别检测到身份、端点、代码和云事件后，再通过静态警报开展工作。

自主攻击框架不会遵守这些组织边界。它可以测试凭据、发现暴露服务、修改脚本并持续推进，而无需创建独立工单。

Google 还发现了一个与自动化侦察相关的暴露命令与控制环境。其仪表板旨在组织和验证超过 23,800 个被收集的机密信息。

据称，该系统包含智能体配置文件和可复用的知识文档。这种结构表明，攻击者正将指令和积累的上下文视为运营基础设施。

另一个间谍活动案例进一步强化了这一模式。Google 观察到一个与中国有关联的组织在试验 CC Switch，这是一款可在多个 AI 模型之间路由任务的工具。

据称，该行为者在 Claude、Codex 和 Gemini 之间切换，并为漏洞利用脚本编写、诱饵文案撰写和错误修正选择不同模型。

这与“一名犯罪者使用一个聊天机器人”的观念相比是显著转变。正在形成的模式更像一条由多个专业组件组成、协调运作的软件流水线。

因此，防御者正从两个方向承压。他们既要保护自身的 AI 资产，也要应对利用 AI 协调传统攻击的对手。

开发者最先感受到压力，因为助手如今会在代码库、编辑器、终端和构建系统中行动。恶意依赖项可能在独立安全审查开始前就进入生产环境。

安全运营团队面临下一层延迟。可疑行为出现后，他们必须重建身份、云资源、软件工件、模型和数据之间的关系。

企业采购方同样面临治理问题。一个智能体可能拥有访问多个系统的合法权限，这使得有害行动更难与获授权的自动化操作区分开来。

这也是 Google 将开发者护栏比作拼写检查器的原因。该公司希望检查机制在编辑器和智能体工作流内部运行，使其能够立即标记可疑软件包或指令。

这个类比很有用，但并不完整。拼写修正几乎不会触发代码、改变访问权限或影响生产基础设施。

安全发现还取决于编辑器并不具备的上下文。一个代码模式单独看可能是安全的，但当它连接到暴露的工作负载或高权限身份时则可能具有危险性。

因此，被迫作出的应对远不止增加一个扫描器。组织需要在开发活动与实时基础设施之间建立关联，并制定规范智能体可访问和可执行内容的策略。

这一要求引出了 Google 战略背后的竞争问题：互联的防御系统能否在不将过多信任集中于其自身自动化机制的前提下，足够快速地作出响应？

这是一场攻击者自动化与防御者上下文之间的较量

Google 的核心主张是，攻击者拥有速度，但防御者可通过将速度与更优越的内部上下文相结合而取胜。

攻击者通常从目标环境之外开始行动。他们探测暴露服务、测试被盗凭据、推断架构，并寻找可利用的路径。

防御者已掌握更多信息。他们可以看到哪些身份拥有高权限、哪些服务面向互联网，以及哪些数据存储包含敏感信息。

他们还知道哪些代码生成了某个工作负载，以及由哪些配置对其进行管理。理论上，这些关系能够让防御模型优先处理会带来真实业务风险的攻击路径。

Google 的战略依赖于将这一理论转化为互联的安全图谱。安全图谱映射代码、云资源、数据、模型、漏洞和身份之间的关系。

在收购 Wiz 后，Google 将 Wiz Security Graph 定位为其更广泛 AI Threat Defense 架构中的上下文层。该框架还整合了 Gemini、Mandiant intelligence、CodeMender 和 Google Security Operations。

Google 表示，这一架构能够识别有害攻击路径、确定风险优先级、调查活动并支持修复。与其说这是一项已被独立证实的成果，不如说是一项雄心勃勃的产品整合主张。

该架构也反映出更广泛的行业转变。安全平台之间的竞争，日益取决于它们关联信号的有效性，而不只是生成多少告警。

当一个存在漏洞的软件包出现在隔离的测试项目中时，其重要性不同。若同一软件包存在于可从互联网访问、且能够接触生产环境密钥的服务中，情况就会变得紧急。

身份又增加了一层复杂性。当某个代理拥有广泛权限并且能够调用外部工具时，一个低严重度的配置问题也可能变得至关重要。

数据血缘同样重要。它记录信息的来源、系统如何对其进行转换，以及哪些模型或应用使用了这些信息。

Google 认为，这些关联应当影响防御的每一个阶段。代码分析应考虑运行时暴露面，而云监控应将弱点追溯到其源头。

这种方法对销售孤立安全控制措施的供应商构成压力。独立扫描器或许能检测到缺陷，却可能缺少评估其实际影响所需的上下文。

它也对职责分散的企业构成压力。开发、云、身份、安全运营和 AI 治理团队往往各自维护独立的资产清单。

当这些清单并不完整时，集成平台无法推断出可靠的关联。因此，Google AI 威胁防御的质量，部分取决于客户必须自行完成的工作。

组织需要准确的责任归属、身份边界、软件清单和数据分类。否则，图谱即使关联了大量遥测数据，也无法捕捉其背后的业务含义。

这种依赖关系使内部知识成为一种安全资产。工程团队需要便于访问的记录，说明代理为何拥有特定权限、哪些代码仓库为生产环境提供输入，以及每项工作流由谁负责。

一个可搜索的知识库可以支持这一文档层。它不能取代安全遥测、访问控制或事件响应。

因此，决定性的竞争并非 Google 与某一个具名竞争对手之间的竞争，而是攻击者自动化与防御者上下文之间的较量。

当企业上下文完整、最新且可供防御系统使用时，Google 的论点才会成立。当组织数据依然碎片化，或权限超出运营所需时，这一论点便会被削弱。

为什么 Google 在 AI 网络安全中采用多模型

Google 不认同单一前沿模型能够可靠检测每一种漏洞、恶意指令和逻辑缺陷的观点。

该公司描述了一种有意设计的多模型安全方法。它会协同使用 Gemini、商业模型和开源模型，并对比它们的发现。

Google 表示，这一过程可以减少误报、发现复杂缺陷，并生成单个模型可能遗漏的修复方案。这一主张针对的是单模型安全的真实弱点。

每个模型都有其典型盲区。训练数据、策略过滤器、上下文限制、系统指令和工具访问权限，都会影响其能够检测到什么。

攻击者可以探测这些边界。Google 曾观察到恶意 JavaScript 注释中包含极端文本，显然意图触发基于 LLM 的扫描器作出安全拒绝。

恶意载荷位于这些指令之下。如果扫描器拒绝进行完整分析，攻击者就可能将模型的安全行为用作规避防御的手段。

Google 报告称，Gemini 的安全防护对此类内容作出了响应。它还表示，由此获得的情报有助于强化分类器，并破坏相关账户和基础设施。

多模型设计能够降低对单一拒绝策略的依赖。如果一个模型拒绝执行任务或忽略某种模式，另一个模型仍可能识别出可疑行为。

交叉验证也有助于区分真实弱点与看似合理却不正确的发现。模型依然容易生成自信却与可执行代码不符的解释。

不过，增加模型并不会自动形成可靠共识。多个模型可能共享训练来源、通用架构或相似的评估失效模式。

编排本身也会引入攻击面。系统必须决定将数据交给哪个模型、每个模型可以调用哪些工具，以及相互冲突的结果将如何影响生产操作。

成本和延迟同样重要。由多个模型反复分析会消耗更多算力，并可能拖慢对时间敏感决策的响应。

Google 提出的答案是基于上下文确定优先级。昂贵的分析可以聚焦于与暴露或高权限系统相连的代码和资产。

这形成了一种两部分机制：多个模型扩大检测范围，而安全图谱则将注意力收窄到具有真实运营后果的发现上。

CodeMender 代表修复的一面。Google 将其描述为一款能够发现并修复软件漏洞的 AI 代理，将部分防御工作从检测推进到源代码变更。

自动化补丁可能缩短暴露时间，尤其适用于反复出现的漏洞模式。然而，代码变更需要严格的测试、审查和回滚控制。

修复一个弱点的补丁，可能改变应用行为或引入另一种故障。因此，高权限修复代理所获权限应比其技术能力所允许的范围更窄。

这正是独立指导变得有用之处。NIST 正在制定的Cyber AI Profile将这一领域分为保护 AI 系统、开展 AI 赋能防御，以及阻止 AI 赋能攻击。

这些类别与 Google 的威胁模型高度契合。它们也能防止组织将一款 AI 安全产品视为完整的治理计划。

MITRE 已扩展其面向 AI 的对抗性威胁框架 ATLAS，以覆盖代理式系统和大语言模型。其 2026 年的ATLAS 扩展反映出，各供应商之间需要共享技术和缓解措施。

共享框架之所以重要，是因为客户需要可移植的方法来检验防御主张。供应商的内部基准无法揭示其系统在另一组织的权限和工作流中表现如何。

因此，多模型安全是一种机制，而非优越性的证明。它的价值取决于差异化的失效模式、受控的工具访问、可衡量的结果和安全的修复。

Google AI 威胁防御为这种机制提出了可信的架构。客户仍需要看到证据，证明它在生产条件下能够持续稳定地发挥作用。

证据支持紧迫性，而非自主网络战争

Google 的遥测数据显示出有意义的自动化，但并未表明攻击者正在大规模实施完全自主的端到端入侵。

这一区别构成了本文最关键的审慎视角。有关机器速度攻击的标题，可能让人以为自主系统已经取代了熟练的操作人员。

Google 的详细报告则更为克制。GTIG 表示，对手正将 AI 应用于侦察、漏洞利用开发、社会工程、故障排除和凭证窃取。

该团队还表示，尚未观察到完全自主的流水线在真实环境中针对目标实施零日漏洞利用。

相反，证据显示攻击者的运营成熟度在逐步提升。攻击者利用现有商业模型和开放权重模型来加速熟悉的工作，尤其是在漏洞公开之后。

其中一个案例涉及针对已修复 Firefox 漏洞的 AI 生成工件。Google 发现，这些脚本正从诊断探针逐步发展为更完整的执行链。

这些工件似乎在供应商发布补丁约一个月后出现。该案例表明，攻击者对已知漏洞的迭代速度更快，而不是证实其自主发现了未知缺陷。

另一个案例涉及一个试图自动化的渗透测试框架。GTIG 表示，相关行为者试图构建一个能够执行发现和执行任务的代理。

Google 禁用了相关资产，报告将该工作描述为一次尝试。它不应被表述为一次成功的自主入侵。

六小时凭证攻击活动是更有力的证据，因为 Mandiant 观察到了实际运营使用。即便如此，攻击者仍提供了提示词、聊天机器人、指令和已被攻陷的基础设施。

该系统减少了人工参与，但公开证据并未证明其具备完全独立性。因此，“机器速度”等说法应描述工作流压缩，而不是无限制的自主性。

Google 的可见性同样存在边界。其报告基于 Mandiant 调查、Gemini 滥用信号、威胁行为者追踪以及 Google 平台防御。

这是一个重要的数据集，但它并不涵盖每一个模型提供商、私有部署、云环境或受害者环境。

在被攻陷硬件上运行的开放权重模型，可以规避商业 API 监控。Google 提到，一个与中国有关联的行为者正因这一原因在受害者基础设施内部部署本地模型。

在评估干扰行动的主张时，覆盖缺口至关重要。禁用一个 Google 账户可能中断一次行动，却也可能将另一项行动推向本地工具或竞争服务。

防御自动化也带来了相应的不确定性。Google 表示，丰富的内部上下文让防御者比攻击者更快、更准确。

这一判断在方向上是合理的，但准确性必须依据误报、漏报、调查时间和不安全修复来衡量。该公司尚未在此次公告中发布可比较的生产指标。

NIST 的研究又增添了一层警示。其 2026 年 6 月关于持续监控的工作指出，固定护栏无法在面对自适应对抗性提示词时始终保持可靠。

这一发现支持 Google 的持续反馈方法。它也意味着，任何分类器、模型集成或策略层都不应被视为永久安全。

当防御代理拥有广泛权限时，风险尤其高。观察工具得出错误结论会产生噪声；而修复代理犯下同样错误，则可能改变生产系统。

组织应要求采用分级自主机制。低风险操作可以自动执行，而具有破坏性或会改变身份的操作则需要审查。

它们还应隔离代理凭证、记录工具调用、测试回滚程序，并为人工调查保留证据。缺乏可审计性的自动化，只会让不确定性更快扩散。

Google 的更新支持紧急准备，但并不足以证明自主网络战争已经到来，也不能证明某一个集成平台已经解决了这一问题。

三个信号将检验 Google 的 AI 威胁防御论点

接下来的考验是，Google 能否将引人注目的事件报告转化为可独立衡量的防御成果。

第一个信号是 AI Threat Defense 部署后的运营证据。客户应寻找有关调查时间、误报、暴露持续时间和重复事件减少情况的文档记录。

架构图无法回答这些问题。案例研究需要明确的起始条件、评估周期，以及哪些操作仍由人工控制的说明。

不同环境中的证据将强化 Google 的论点。一个高度完善的云环境所得结果，对于职责分散的多云组织而言，说明力会更有限。

薄弱或选择性的指标会削弱“整合上下文能够带来非对称优势”的主张。买方还应询问，平台如何处理责任归属缺失或遥测数据不完整的问题。

第二个信号是攻击者进一步使用自主、多智能体流水线。Google 的下一份威胁报告应区分实验、辅助操作，以及成功的端到端攻击活动。

可重复的六小时攻击活动若有所增加，将强化“机器速度”的判断。若确认自主利用此前未知的漏洞，事态将严重得多。

相较之下，若仍持续依赖已知漏洞、人工提供的操作手册和被盗基础设施，则更支持一个较为有限的结论。AI 仍然重要，但主要是对既有攻击手法的加速器。

分析师应追踪攻击者如何在不同模型之间分配工作。CC Switch 的案例表明，对手会按任务选择工具，而非始终忠于某一家提供商。

这种模型多样性使针对单一提供商的干扰行动更为复杂。它也支持在多种模型系列及拒答行为上开展防御测试。

第三个信号是，共享标准是否能为智能体安全产生可测试的控制措施。NIST 的 Cyber AI Profile 和 MITRE ATLAS 为组织提供了描述这一问题的厂商中立语言。

有价值的进展应包括针对工具权限、模型清单、提示注入、数据血缘、事件日志和自主修复的具体控制措施。这些控制措施应能映射到可观察的证据。

它们的采用将强化 Google 更广泛的论点：AI 防御需要互联、持续的运营。这也能防止 Google 完全通过自身的产品类别来定义成功。

如果行业指南在智能体获得生产环境权限的同时仍停留在抽象层面，这一论点就会被削弱。届时，企业将面临更快的自动化，却没有一致的方法来测试或审计它。

安全负责人不应等待完美的标准。他们现在就可以盘点 AI 资产、收紧智能体权限、将代码与运行时暴露面关联起来，并测试事件响应工作流。

开发者应将代码仓库指令和 AI 配置文件视为可执行风险。安全团队应监控云资源，发现未经授权的模型工作负载和异常凭证使用情况。

高管应提出一个直接的问题：组织是否拥有足够可靠的上下文，让自动化防御系统能够安全行动？

Google AI 威胁防御通过连接模型、威胁情报、代码修复、安全运营和云图谱，提供了一种答案。其 9 月报告以异常具体的事件来支撑这一论点。

这些证据表明，AI 辅助攻击正变得更加协调、速度更快。但它并不能证明自主性会消除人类攻击者，也不能保证实现自主防御。

未来三个月将揭示，是否会有更多攻击活动重复六小时模式、客户是否会公布可衡量的结果，以及标准能否赶上拥有特权的智能体。

在此之前，组织应将 Google 的报告同时视为警示和设计挑战。连接防御者已拥有的上下文，限制智能体的能力，并衡量每一项被宣称的速度优势。