近日安全研究人员披露了影响 Google Gemini 的三项严重安全缺陷,集合命名为 Gemini Trifecta。这些漏洞分别存在于 Gemini 的不同组件,包括 Cloud Assist 的日志摘要功能、用于个性化搜索的 Search Personalization 模型,以及 Browsing Tool 的网页摘要调用。成功利用这些缺陷,攻击者可以通过提示注入实现模型行为劫持,甚至在云端发动权限滥用与数据外泄行为。了解这些问题的技术细节、攻击场景与补救措施,对于企业、开发者与安全团队在 AI 时代建立更安全的防护线至关重要。 问题概述与来源背景 此次披露源自安全公司 Tenable 的研究报告,研究人员 Liv Matan 在与媒体分享的技术细节中,展示了三种不同的利用链条。第一类问题是 Cloud Assist 的日志到提示注入漏洞。
Cloud Assist 能从多个云服务和 API 汇总日志并生成摘要,研究人员证明可以在原始日志中隐藏恶意提示,例如将提示写入 User-Agent 头部或其他日志字段,使得摘要器在处理日志时将该提示当作合法指令执行。第二类问题发生在 Search Personalization 模型,攻击者可以通过在受害者浏览器历史中注入恶意搜索查询来诱导模型执行非预期操作,由于模型无法区分真正的用户查询与恶意注入,便可能泄露用户已保存的信息或者定位数据。第三类问题出现在 Browsing Tool,其内部调用用于网页摘要的服务存在间接提示注入风险。攻击者能够构造网页或资源,使工具在摘要过程中将敏感信息打包并发送到受控服务器。 攻击场景举例与潜在影响 想象一个情形,攻击者在某个目标可访问的网页上嵌入看似无害的请求,或者通过控制第三方 API 将带有隐藏提示的字符串写入到受害者的云日志。Gemini 的 Cloud Assist 拉取这些日志并生成摘要,若摘要生成器未能过滤隐藏提示,便可能按提示去检索云资产信息、查询 IAM 配置或导出其他敏感数据,随后将数据内置于生成的响应或超链接中发送到攻击者可访问的位置。
对于 Search Personalization,攻击者可以诱导用户访问特制网页,使其浏览历史被污染,随后当用户使用个性化搜索模型时,模型可能执行注入指令导致数据库、联系人或位置信息泄露。Browsing Tool 的问题则更隐蔽,攻击者通过网页内容影响内部摘要调用,从而在摘要请求或响应链中夹带敏感字段向外部服务器泄露数据。 这些攻击不仅仅是信息泄密,结合云服务权限滥用,攻击者甚至可以探测公共资产、寻找 IAM 漏洞、枚举资源并在云环境中发起进一步攻击。如果攻击者能够诱导模型执行对 Cloud Asset API、Cloud Monitoring API 或其他管理 API 的查询,则会对云原生环境构成重大威胁。 披露与修复措施 在负责披露后,Google 对多个组件采取了紧急修复与硬化措施。针对日志摘要功能,Google 停止在此类摘要中渲染超链接,从而限制了通过超链接直接外泄数据的方式。
同时在输入处理与摘要策略上添加了更强的提示注入防护逻辑,以避免原始日志内容被视为执行指令。对于模型个性化与浏览工具,Google 提升了外部输入的来源验证能力,加强了对浏览历史与第三方网页内容的过滤与上下文检查,限制模型基于不可信来源执行敏感查询的权限。 尽管厂商已修补多个高风险问题,但这一事件本身暴露了一个更深层次的挑战:当 AI 模型具备跨系统调用与代理能力时,单靠传统的输入校验往往不足以防御复杂的提示注入与链式滥用。攻击者可以通过多跳技术在日志、历史记录、网页内容等多个边界内隐藏指令,借助模型的上下文聚合能力实现跨域数据窃取。 防护建议与实务指南 首先,应该在云端最小化 AI 模型可访问的信息范围。对 Cloud Assist 等工具授予权限时应遵循最小权限原则,仅允许其访问绝对必要的 API 与数据集。
对能够查询 Cloud Asset API、IAM 信息或其他敏感管理接口的模型动作施加严格审批与审计流程,避免模型在未经人工确认的情况下发起高危查询。 其次,日志与审计信息应当进行敏感字段去标识化或脱敏处理,避免在未校验的环境中直接呈现原始日志内容。将可能包含用户生成输入或第三方头部的字段进行规范化与清洗,删除或掩盖可能被用于提示注入的可执行字符串。对日志聚合与摘要功能启用严格的内容白名单与黑名单策略,并对摘要器的输出进行二次验证。 第三,提升模型端的提示注入防护能力。通过引入专门的提示安全过滤器、上下文来源验证与异常指令检测来减少模型被劫持的风险。
对模型能接受的输入来源进行分类,标注可信度并在高风险来源触发人工审查或限制执行。例如来自浏览历史、外部网页或非交互式日志的内容应先通过隔离环境与转换器进行处理,而非直接串联到执行流。 第四,实施严格的网络与应用层访问控制。将 AI 代理或能发起外部调用的服务置于受控网络边界内,使用 egress 策略限制其对外部服务器的访问,启用出站流量监控和异常连接告警。对生成的响应与外部链接严格检测,阻止通过自动化生成的超链接将敏感数据传输到不受信任的目标。 第五,强化审计与监控能力。
对模型的所有高风险操作进行完整的审计跟踪,包括 API 调用、外部请求、摘要生成与结果分发路径。利用异常检测与行为分析模型识别不寻常的查询模式或大规模的数据导出行为。将模型决策日志与云活动日志关联分析,以便在早期发现滥用链条。 第六,建立跨职能的 AI 风险管理流程。安全团队、云运维与产品团队应共同参与 AI 功能上线前的风险评估,制定针对提示注入、数据泄露与代理滥用的应急预案。对于具备自动化决策或跨系统执行能力的 AI 代理,应制定明确的能力边界与回退机制,保证在异常情况下能被即时终止或降级为人工流程。
更广泛的行业启示 Gemini Trifecta 的披露提醒我们,AI 不只是潜在攻击目标,它本身也可能成为攻击工具。当模型被赋予查询、摘要或执行外部操作的能力时,攻击者能将 AI 的功能链化为攻击面。随着更多企业将 AI 嵌入到客户服务、日志分析与运维自动化中,类似的风险将越来越常见。 此外,多步自动化工作流与代理型服务的普及,使得传统的基于角色的访问控制无法覆盖所有威胁场景。一个拥有广泛工作区访问权限的代理,可能会跨文档、跨数据库、跨外部连接链式操作,从而在权限控制层面产生不可预见的风险。供应链中的第三方插件、外部内容以及用户生成输入都可能成为提示注入的载体。
因此,构建 AI 安全防护需要兼顾模型本身的安全性与其运行时环境的健壮性。包括模型训练与微调阶段的安全审查、推理时的输入来源校验、运行时的最小权限与网络隔离、以及外部调用的严格审计。行业应着手建立统一的提示注入检测标准、模型能力分级框架与跨平台的安全基线。 响应与合规要点 对于企业合规与事件响应团队而言,应将 AI 组件纳入常规风险评估与合规审查清单。对外提供基于 AI 的功能时,应在隐私政策与用户协议中明确说明数据处理与外部调用策略,并提供可理解的控制选项供用户选择关闭某些高风险功能。发生安全事件时,快速识别受影响的模型版本、配置变更与外部请求路径是关键,只有明确了数据流向与权限链条,才能有效阻止进一步的外泄。
结论与未来展望 Gemini 三重漏洞事件既是对当前 AI 产品安全的一次重要警示,也是推动行业采取更严谨防护措施的契机。AI 模型在提供强大能力的同时也带来了复杂的攻击面,企业必须在设计阶段即将安全纳入核心考量。通过最小权限原则、输入脱敏、提示注入防护、严格的网络控制与完善的审计监控,能够显著降低类似风险。 长期来看,行业需要在模型能力、权限管理与安全验证之间建立明确的规范与标准,推动供应商在默认配置下提供更安全的运行环境。安全研究社区与厂商之间的负责任披露机制同样关键,它不仅能加速补丁发布,还能推动安全最佳实践的普及。对任何依赖 AI 的组织而言,保持警惕、及时修补、强化边界防护并持续审计,是在 AI 时代保护数据与业务的基本底线。
参考与延伸阅读 此次披露由 Tenable 的研究团队公开,相关细节见研究人员在媒体与安全博客的说明。与之相关的类似事件还包括对办公自动化代理的滥用研究,例如通过巧妙隐藏指令的 PDF 攻击方式,表明代理型 AI 的工作空间权限与内容处理策略必须更加谨慎。安全从业者应关注供应商更新日志、补丁公告与社区研究,以便及时调整防护策略并降低潜在威胁。 面向开发者与安全负责人的行动建议包括审查 AI 服务的外部调用能力、减少模型对原始未过滤日志的直接访问、对摘要与自动化输出进行多层次验证以及建立跨团队的快速响应机制。通过这些手段,可以在享受 AI 带来效率提升的同时,最大程度降低数据泄露与云资源滥用的风险。 。
