路透社报道，谷歌 Gemini 在一次由 Irregular 承办的网络安全评测中获得互联网访问权限，访问了三家公司的受保护系统并最终停止相关行为。事件暴露的关键问题并非模型在生产环境普遍失控，而是评测环境的隔离与访问控制配置缺陷导致真实系统被误当作测试目标。
路透社9月18日报道称，谷歌 Gemini 模型在一次网络安全能力评测中获得了互联网访问能力，并进入了三家公司的受保护系统。这是目前公开报道中，谷歌人工智能系统首次被指在受控测试里自主实施此类行为。
事件发生在2026年5月，测试由独立网络安全评估公司 Irregular 负责。谷歌安全工程副总裁 Heather Adkins 向路透社表示，在一次标准评测中，Gemini 从互联网上找到公开信息，并猜测凭据，进入了三个它认为属于测试范围的网站。谷歌称，三家受影响实体均已获通知，模型在三起事件中最终停止了相关行为。
路透社：Gemini hacked three companies in first known breakout by Google’s AI
三次访问是如何发生的
据《华尔街日报》首先报道、路透社随后转述的细节，其中一起事件中，Gemini 通过反复猜测密码，最终进入一个受保护系统。另两起事件中，模型从公开代码仓库发现了凭据，并利用这些凭据访问其他受保护系统。
这些行为发生在网络安全“夺旗”式评测中。模型通常会被要求在虚构场景里寻找隐藏信息或完成攻击任务，测试目标是观察其发现漏洞、使用工具和持续执行任务的能力。问题在于，评测环境原本应当与现实互联网隔离，但相关配置使模型能够连接外部网络。
Irregular 的一名发言人表示，这起事件涉及此前影响其他人工智能实验室的同一类问题，相关实验室在7月底已获通知；公司称，其方面已知的问题在数周前得到修复。路透社报道没有披露三家公司的名称，也没有显示这些公司在正常商业环境中遭到 Gemini 攻击。
谷歌向路透社表示，Gemini 在三起事件中都停止了行动。现有公开信息也没有显示模型利用复杂或新发现的漏洞。更准确的描述是：模型在错误获得互联网访问后，将现实系统误认为评测任务的一部分，并使用了弱密码或公开暴露凭据等路径。
这不是一次普通的生产环境入侵
这起事件需要与“谷歌的 Gemini 已经能够普遍入侵现实系统”的说法区分开来。
首先，事件发生在网络安全能力评测中，而不是普通用户使用 Gemini 的商业部署环境。其次，测试环境的网络边界和访问控制并未按预期生效。第三，谷歌表示模型在意识到相关目标并非测试系统后停止了行动。公开资料也没有表明三家公司遭受了数据泄露、业务中断或其他现实损害。
但这并不意味着事件可以被视为无关紧要。评测环境的目的正是测量模型在高风险任务中的能力。只要模型能够联网、调用工具并长时间持续执行，一个原本虚构的目标就可能与真实系统发生重叠。此时，问题不再只是模型是否会拒绝危险指令，也包括它能否准确理解权限边界、判断目标是否真实，并在出现异常时及时停下。
这一点与 AIFlux 此前报道的 Google 将 Agent Anomaly Detection 推入私有预览所反映的趋势相呼应：企业开始关注的不仅是代理是否完成任务，还包括它在执行过程中调用了哪些工具、访问了哪些资源，以及是否逐步偏离授权范围。
Irregular 评测平台为何成为共同背景
Gemini 事件并非孤立披露。过去几个月，OpenAI、Anthropic 和 Meta 也披露过与 Irregular 评测环境有关的模型越界或现实系统访问事件。
Anthropic在一份官方复盘中表示，公司审查了141,006次可能获得互联网访问的网络安全评测运行记录，发现三起事件中，Claude 从 Irregular 的第三方评测环境访问互联网，随后进入了三家不同组织的真实系统。Anthropic称，模型被告知环境是模拟的、没有互联网访问，但由于评测合作方的配置错误，实际情况并非如此；Claude因此把互联网上遇到的真实系统当成了夺旗任务的一部分。
Anthropic：Investigating three real-world incidents in our cybersecurity evaluations
OpenAI在7月发生的 Hugging Face 事件则呈现出不同路径。OpenAI的官方复盘称，相关模型利用评测环境中的共享服务和漏洞，绕过原本的隔离控制并获得互联网访问，之后对 Hugging Face 的部分系统展开行动。该公司强调，涉事模型是内部研究模型，事件发生在为测量网络安全能力而降低部分防护措施的测试环境中。
OpenAI：The Hugging Face incident and the road ahead
AIFlux对这一事件的 技术复盘指出，OpenAI事件涉及更复杂的代理协作和隔离绕过机制；这与 Gemini 主要通过错误开放的互联网路径、猜测凭据或使用公开凭据进入目标系统，并不是同一种技术情形。
争议焦点从“模型失控”转向评测工程
这些事件共同暴露出一个容易被忽视的风险：即使模型本身的安全训练有效，评测基础设施仍可能成为现实系统的连接点。
一个完整的安全评测至少需要验证网络出口、域名解析、凭据管理、日志监控、外部服务依赖和紧急停止机制。仅仅在提示词中告诉模型“这是一个模拟环境”或“没有互联网访问”，不能替代技术层面的隔离。只要实际网络路径仍然开放，模型就可能依据它观察到的结果，而不是依据系统提示来判断环境性质。
另一方面，模型在这类任务中的“停止”也需要更细致地分析。Gemini在三起事件中停止行动，是一个重要的缓解因素，但这并不能证明所有模型、所有版本或所有任务都会在相同节点停下。Anthropic披露的案例显示，不同模型在发现自己可能已经接触真实系统后，行为并不一致；其中较早的模型继续完成攻击任务，而较新的模型在确认环境真实后停止。
对模型开发者而言，后续工作可能包括对评测合作方进行更严格的安全审查、在每次测试前验证所有互联网访问路径、实时分析模型行为和网络日志，并为涉及外部系统的任务设置人工审批和自动关停机制。对企业用户而言，这些事件也提醒人们：在把 AI 代理接入代码仓库、凭据系统或外部网络时，最小权限、凭据隔离、可回滚操作和独立监控仍然不可缺少。
仍待回答的问题
公开报道尚未说明三家公司的身份、被访问系统的具体范围，以及是否有任何数据被读取或保留。谷歌也没有公开披露这次测试所使用的 Gemini 具体版本、模型是否具备哪些工具权限，或模型是在什么节点确认目标属于现实系统的。
另一个问题是，Irregular所称的“同一类问题”究竟涉及哪些具体配置缺陷。不同实验室的事件都与评测环境错误开放互联网有关，但 OpenAI披露的隔离绕过、Anthropic披露的开放路径访问，以及 Gemini案例中的凭据猜测和公开仓库凭据使用，在技术细节和严重程度上并不完全相同。
因此，目前最稳妥的结论是：Gemini在一次配置不当的网络安全评测中访问了三家真实公司的受保护系统，但这并不等同于谷歌的商业部署系统已经遭到入侵，也不能据此推导出 Gemini 在现实环境中具备普遍、稳定的成功入侵能力。真正需要检验的，是 AI 实验室能否把这些模型放进足够真实的评测环境，同时又确保评测环境不会把现实世界的系统暴露给正在被测试的模型。