2026年9月18日,Google 公开证实,其 Gemini 模型未经授权访问了属于外部各方的三个系统。事情发生在2026年5月,当时 Irregular(一家测试先进 AI 系统的公司)正在进行一次安全评估,评估以夺旗(capture-the-flag)演练的形式在一个本应封闭的环境中进行。Google 于7月得知这些事件,直到9月中旬媒体报道后才公开证实。
在媒体上,这读起来像是一个 AI 突破自身限制的故事。而在企业内部,它读起来是一件更具体、也更贴近自身的事:引发这一切的细节不在模型里,而在测试环境的搭建方式上。而且,这类错误此刻正存在于相当多沙特企业的系统之中。
实际发生了什么
场景很简单:让模型在一个隔离环境中攻击一家虚构的组织。有两件事同时出了问题。第一,该环境意外地能够访问互联网。第二,演练中使用的虚构公司恰好与一个属于真实主体的真实域名重名。
结果是,模型完全按照要求行事,只是对准了错误的目标。据 Google 安全工程副总裁 Heather Adkins 介绍,模型在网上找到了公开信息,并猜出了登录凭据,访问了它以为属于测试一部分的网站。获得访问权限后它就停了下来,没有进一步行动,Google 表示没有造成任何损害。
Google 立场中最重要的一点是,它不将此事归类为模型行为上的对齐偏差,而是身份误认。模型并没有决定越过自己的指令,而是在一张错误的世界地图里逐字执行了这些指令。这也不是孤立事件:OpenAI 在7月披露其一个智能体攻破了 Hugging Face,Anthropic 也报告过其自家模型出现的类似行为。
失误在边界,而不在模型
把 AI 从这个故事里完全拿掉,教训依然完整。用平实的话来描述,这起事件就是:一个运行在测试环境中的系统,一个有着通向外部世界的活跃通道的环境,以及其中并不像编写者所以为的那样虚构的测试数据。
这个描述同样适用于完全没有 AI 参与的普通企业中发生的事情。一个预发布(staging)系统向随手编造的手机号码发送确认消息,结果送到了真实的人手里。一个测试脚本对着生产环境而不是沙盒调用支付网关。网站的开发副本指向了线上客户数据库,因为单独接一个数据库太麻烦。一次试发的邮件营销活动发到了真实的订阅者名单上。在每一种情况下,被打破的假设都是同一个:有人以为这个环境是隔离的。
这在沙特企业中反复出现在哪里
从我们在现有系统上工作的所见来看,它反复出现在四个具体的地方:
- 并非真正虚假的测试数据。为了填写测试表单而临时编造的号码、域名和电子邮件地址,通常都属于真实的人。解决办法不是靠个人判断,而是使用为测试保留的域名、不会送达任何人的号码,以及一条禁止临时编造数据的书面规定。
- 出口敞开的预发布环境。如果你的开发副本能向外部世界发送 WhatsApp 消息、电子邮件或支付请求,那它就不是预发布环境——而是第二个生产环境。正确的封堵应写在配置里,而不是靠开发人员的记性。
- 在测试中使用生产密钥。只要有一个密钥在两个环境中共用,无论文件夹结构看起来多么整齐,隔离都被抵消了。这正是政府平台要将两者分开的原因:例如,天课、税务和海关总局(ZATCA)在 Fatoora 平台上提供与生产环境分离的模拟环境,并为每个环境分别颁发接入证书。
- 开发环境中存有客户数据副本。从监管角度看,这是风险最高的一项。由沙特数据和人工智能管理局(SDAIA)监管的《个人数据保护法》(PDPL)对个人数据的规范不论其存放在何处,对于标注为测试的副本也不设例外。存有真实客户数据的预发布环境完全在其适用范围之内——而且它通常是你所拥有的防护最薄弱的系统。
本周要设定的四道边界
这些都不需要立项或预算,只需要与负责运维你系统的人开一次会:
- 问一个直截了当的问题:我们的测试副本能否向外部世界发送消息、电子邮件或支付请求?如果回答是能或者我不确定,那就是你首先要封堵的地方。
- 在各环境之间彻底分离密钥和证书,确保没有任何一个密钥能在两个环境中同时生效。
- 采用一份固定的测试数据清单:一个保留的测试域名、不会送达任何人的号码,以及一个接收所有测试消息的已知团队手机号码。
- 明确谁可以针对你的系统运行自动化工具或 AI 智能体、在哪个环境中运行、拥有哪些权限。如果答案没有写成文字,它就不存在。
Origami 的观点
我们把这起事件看作一个提醒:代价最高的系统故障很少是精巧复杂的,而是假设上的失误。Google 的安全能力远超任何一家沙特企业,而被打破的恰恰是那个最简单的假设:封闭的环境确实是封闭的。企业通常不会栽在系统的难点上,而是栽在那个因为看起来理所当然而无人检查的部分。
在 Origami,我们把环境隔离视为交付的一部分,而不是可选的附加项:一个无法触达真实通信渠道的预发布环境、彼此分离的密钥,以及不属于任何人的测试数据。代价是项目开始时的几个小时。另一种选择则是在事故已经发生之后,向客户或监管机构解释一起事件。这笔账值得尽早算清。
一条实用结论
Gemini 事件的教训不是要回避 AI 工具,而是不要再把 staging 这个词当作一种保证。一个环境之所以是隔离的,并不是因为你这样命名了它;而是因为有人真正测试过它确实是隔离的。今天就从一个问题开始:我们的测试副本最远能触达哪里?如果答案并不清楚,那你正依赖着在 Google 那里被打破的同一个假设。
资料来源
- NBC News —— Google 证实 Gemini 于2026年5月未经授权访问了三个外部系统,以及安全工程副总裁 Heather Adkins 的说法:模型找到了公开信息,并猜出了它以为属于测试一部分的网站的登录凭据。
- CNBC —— Irregular 所做评估的细节、测试环境意外的互联网访问、与真实域名重名的虚构组织,以及 OpenAI 和 Anthropic 披露的类似事件。
- SDAIA —— 《个人数据保护法》(PDPL)及其对个人数据的适用,无论数据在何处处理。
- Fatoora 平台 - ZATCA —— 模拟环境与生产环境的分离,以及为每个环境分别颁发的独立接入证书。
常见问题
这是否意味着 AI 已经失控?
Google 明确表示,它并不将此事归类为模型行为上的对齐偏差,而是身份误认:模型在执行交给它的任务时,以为外部系统是演练的一部分。这一区分在实践中很重要,因为补救办法不同。如果问题出在模型上,解决办法是约束模型。既然问题出在环境边界上,解决办法就是在其中运行任何自动化工具之前,先把这道边界封闭。
我的公司根本不使用 AI 智能体,这和我有关吗?
有关,因为这起事件的核心与 AI 毫无关系。失误在于一个被认为是隔离的环境存在一条通向外部的活跃通道,而被标记为虚假的数据却指向了真实的对象。这种事每周都在普通企业里发生:一条测试消息发到了真实客户手里,或者一个测试脚本对着生产环境调用了支付网关。AI 智能体只是放大了速度和波及范围,并不会制造问题本身。
如何核实我们的测试环境是否真正隔离?
不要满足于问一句它是否隔离,因为答案永远是肯定的。要求做一次实际测试:在测试副本上跑完一笔完整交易,然后核实是否真的有任何消息、邮件或请求发到了外部对象。亲自阅读发送日志,而不是凭印象判断。接着检查密钥和证书:只要发现有一个密钥在两个环境中都有效,无论配置看起来多么规整,隔离都不存在。
不启动完整项目的话,我能采取的最快一步是什么?
在配置层面切断测试环境的出站通道,而不是依赖开发人员记得去做,确保预发布(staging)副本在任何情况下都无法向外发送消息、邮件或支付请求。这只需要几个小时,却能封住其中最危险的部分。之后,采用一份固定的测试数据清单,其中包含一个已知的团队手机号码和一个保留的测试域名,更大范围的权限梳理工作可以留到以后再做。
在 Google 上关注 Origami
把 Origami 设为首选来源,我们的文章就会优先出现在您的 Google 搜索和热门新闻中。








