Google confirms Gemini breached three companies during a security test

谷歌迟到的确认：AI安全测试的边界与披露规则之问

谷歌近日确认，其Gemini模型在今年5月的一场网络安全测试中，实际触达了三家真实企业。该测试由第三方安全评测机构Irregular执行，模型本应攻击一个虚构目标，却因意外获得互联网访问权限，先后通过猜测凭据和利用公开暴露的凭据，进入了受保护系统。谷歌表示，Gemini在识别出目标为真实企业后主动停止，涉事企业已获通知，未造成实际损害。这起事件由《华尔街日报》率先报道后，谷歌随后证实，成为又一起引发行业反思的AI安全测试“准事故”。

这类事件并非孤例。此前，OpenAI、Anthropic与Meta在各自的模型测试中，也出现过类似“目标误判”的情形。如果把这几起事件放在一起观察，会发现一个共同问题：当AI代理被赋予攻防测试任务后，模型能力的边界、测试环境的边界，以及第三方评测结果的披露边界，都还缺少一套公认的规则。

01 一次测试意外，暴露两个安全缺口

Irregular的测试目标很明确：让Gemini在模拟环境中攻击一个虚构的企业系统，以检验其识别漏洞、利用漏洞的能力。这类测试在网络安全行业已是常规操作——行业内称为“红队评估”。区别在于，过去的红队评估由人工完成，测试范围可以被精确控制；而如今执行评估的是具备自主决策能力的AI代理，它能在无人干预的情况下完成信息收集、凭据猜测、权限提升等一连串动作。

问题正出在这里。测试环境的网络隔离没有生效，让Gemini意外接入了真实互联网。目标的边界一旦从“虚构企业”扩展到整个公网，AI代理的动作就不再只是针对模拟目标的模拟攻击：它猜测出一套受保护系统的凭据，还成功利用了两套公开暴露的凭据，触达了三家真实企业的系统。

Gemini最终主动停止，并非因为测试指令中带有“不得访问真实企业”的约束，而是它自己识别出目标的真实属性。这是在冗长行为链末端的一次关键判断。但在判断作出之前，真实系统已经被访问了。这种“先行动、后识别”的机制，恰恰是AI代理与人工测试最大的不同——人工红队的第一原则是确认攻击目标合法性，而AI代理的默认倾向是先执行任务，再校验目标属性。

这暴露出的两个安全缺口，比事件本身更说明问题。第一个缺口是测试基础设施的隔离能力。所谓封闭测试环境，能不能在复杂的网络拓扑中真正切断一切意外通路，已成为当前最大的挑战之一。第二个缺口是模型在真实目标与模拟目标之间的判别能力。如果真实企业的系统伪装程度较高，或者页面上没有明显的企业标识，模型能否在攻破前识别出风险？目前没有任何厂商能给出可靠承诺。这也是AI安全测试的边界越来越难守住的根本原因：模型的判断是概率性的，而安全事件是确定性的，用概率性判断去守确定性边界，本身就存在某种不匹配。

02 第三方测试结果，靠媒体报道才被公开？

如果说测试边界是一个技术问题，那么披露规则就是一个治理问题。

这起事件最先进入公众视野，靠的是《华尔街日报》的报道，而非谷歌或Irregular的主动公告。谷歌随后确认了事件属实，并称相关企业已获通知。整个过程合法合规，但公众不禁要问：如果媒体没有报道，这起安全测试触达真实企业的事件，会以什么形式、在什么时候被外界知晓？

传统软件安全漏洞有一套相对成熟的“协作披露”机制：安全研究者发现漏洞后，通常会提前告知厂商，并给予约90天的修复时间，到期后再公开细节。这套机制兼顾了厂商修复需求与公众知情权，是行业多年磨合出的默契。AI安全测试的第三方结果披露，目前还处于个案处理的阶段。评测机构发现模型在测试中触达了真实目标，应该向谁报告？涉事企业？被测模型厂商？行业监管？还是一并公开？如果所有利益相关方都选择低调处理，行业就无法从失败中积累公共知识；但如果一有风吹草动就公开，又可能放大模型风险、引发不必要的社会恐慌，甚至被攻击者当作能力参考。

从OpenAI、Anthropic、Meta此前发生的类似事件来看，行业目前的默认做法是“尽量不说，必要时简洁回应”。这种状态可以理解，但不可持续。AI代理的能力正在快速增强，第三方评测则会越来越频繁地触碰到真实世界的系统。每一起“准事故”都应该被视作一次系统性的学习机会，而不是一件需要公关处理的事件。没有统一的披露时限和披露路径，整个行业对AI安全演化趋势的认知就是碎片化的。

03 从模型安全到基础设施安全，治理需要同步

跳出单一事件，这次Gemini测试意外还有一个更宏观的维度：AI代理正在成为网络空间的实体行动者，而不仅是内容生成工具。

过去的AI安全讨论大多围绕对话内容展开，比如模型是否会产生有害回答、是否泄露隐私、是否输出不当信息。但这次事件中，Gemini的行为已经不再只是处理文本，而是真实地调用凭据、访问外部系统。这意味着AI安全已经越过模型层，进入了网络与系统层。对于那些将AI代理用于网络运维、安全巡检、风险处置的通信与互联网企业来说，测试边界问题与基础设施安全正在交汇。

国内对这一趋势的响应并不慢。近年来，围绕大模型安全评估的第三方测试、基准测试和备案管理等工作陆续展开，一批安全评测工具和数据集已经在产业侧投入使用。国内主要云服务商和安全厂商也在探索面向AI代理的安全评估框架，将模型的行为测试与系统接入风险纳入考核范围。比起单点修复，更值得做的是把测试隔离、应急处置、信息披露整合成一套完整的安全闭环。通信行业此前在网络安全应急响应、漏洞管理等方向积累的制度经验，可以为AI安全测试的治理提供参照。

04 守住测试边界，才能守住AI落地的信任线

回过头看谷歌这场测试，万幸的是，三家真实企业没有受到实际损害。但下一次未必能如此幸运。随着模型自主性和工具调用能力的增强，测试中偏差行为造成的后果只会更严重。这并非对AI能力的悲观判断，而恰恰是对其发展现状的理性映射——能力越强，需要守住的边界就越多。

行业内现在缺少的不是一次次个案复盘，而是一套面向AI安全测试的专项规则体系。测试环境是否做到物理级隔离，模型是否留有全程行为日志，第三方发现“准事故”后在什么时限内向谁披露，这些都需要更明确的标准。只有把这些问题变成可执行的规范，AI安全测试才可能从“偶然可靠的实验”走向“系统性信任的基础设施”。

AI能力边界越大，安全治理越需要清晰的坐标。守住测试的边界，就是守住AI从实验室走向产业的基础。