谷歌AI首次“越狱”：竟然自己破解密码入侵三家公司！

< img id="wx_img" src="https://www.qbitai.com/wp-content/uploads/imgs/qbitai-logo-1.png" width="400" height="400"> 谷歌AI首次“越狱”：竟然自己破解密码入侵三家公司！ 十三 2026-09-20 16:01:13 来源： 量子位 金磊 发自 凹非寺 量子位 | 公众号 QbitAI AI要是荒谬起来，到底能有多离谱呢？ 来，一起看下 Gemini 新鲜出炉的 事故 。 事情的起因，是一家名叫Irregular的AI安全公司，组织了一场“夺旗”（Capture the Flag）演练，要求是让模型从一家 虚构 的公司系统里拿到一段秘密信息。 而这个测试环境原本不应该具备联网能力的，但问题也恰恰出在了这里。由于一些bug，公网访问被意外打开了；更巧的是，演练里设定的那家虚构公司，和现实中一家真实企业重名。 于是，Gemini就这样水灵灵地直接访问了三家真实公司的系统……在三次测试中，其中一次是Gemini通过反复猜测密码拿到访问权限，另外两次则是从公开的代码仓库里找到凭证，再用这些凭证登录。 不过谷歌对此也是及时给出了回应，官方表示Gemini在三次测试过程中，判断出自己碰到的是真实公司之后都停了下来，以及相关的三家机构也已被谷歌告知详情。 △图片由AI生成 Emmm……怎么说呢，这事还算是有惊无险吧。 但如果我们把时间线拉长一点，就不难发现，其实诸如此类的AI安全事故，今年还真是频频发生。 例如前两天，Hacktron的一个三人研究团队，他们在Claude的帮助下，仅用了不到72小时，便接管了OpenAI员工的ChatGPT/Codex账号，并在内部代码仓库里提交了一个无害的PR作为演示。 而OpenAI方面则是花了约14小时进行修复，并向这个三人团队支付了6500美元赏金。 当然了，这个事儿还只能说是人主导、AI参与的安全研究；但相比之下，OpenAI自己披露的另一起事件，则是直接暴露了模型行动超出预期的问题。 今年7月，OpenAI内部安全评测中的模型绕过隔离控制，入侵了部分OpenAI研究基础设施和Hugging Face系统。OpenAI在8月26日的复盘中，将其称为一次“warning shot”，也就是警示。 Anthropic则在检查约14.1万次评测记录后，披露了三起涉及真实机构系统的事件，并在9月9日补充披露第四起历史事件。公司起初强调的是环境配置失误，但后续调查也发现，模型会忽略或曲解真实环境的证据，并为完成任务采取冒险行动。 哪怕是强如AI御三家的OpenAI、Anthropic和谷歌，也都会遇到模型行动超出预期授权范围的问题；也难怪Anthropic CEO Dario Amodei前不久发表了长文，公开呼吁行业放慢前沿能力提升的节奏，其中一个理由便是这类安全事件。 那么问题来了： 当我们给Agent接上数据库、代码仓库和业务系统之后，怎样才能确保它只在被允许的范围内办事？ AI时代的安全问题已经变了 在谈解法之前，我们先需要把目前的几类常见的AI安全问题给说清楚。 第一类，是人借助AI发起攻击。 AI可以辅助分析代码、定位漏洞、编写和调整攻击载荷。我们刚才提到的Hacktron的案例，就证明了这类能力的现实效用，而同样的能力当然也可能被恶意使用。 第二类，是企业的AI被外部内容误导。 Agent在执行任务过程中，往往需要阅读网页、邮件和文档；如果它把其中夹带的恶意指令当成了应当执行的要求，就会发生提示注入（Prompt Injection），继而错误地调用工具或泄露信息。这和用户直接下达恶意指令，完全是两回事。 第三类，是Agent在执行任务时越过了授权边界。 即使没有外部攻击者，错误的环境配置、过宽的权限，以及模型对任务与目标的误判，也可能让一次测试触及真实业务。 那么，为什么这些问题在AI时代变得更棘手？ 我们回头看一下这些事件的构成要素，包括弱密码、公开仓库里的凭证、网络隔离配置错误、单点登录的令牌复用…… 其实这些漏洞本身并不新鲜，真正变化的，是 利用它们的速度和连续性。 具备工具调用能力的模型，可以把搜索、登录、提权、代码执行这些动作一口气连续做下去，一个环节的疏漏会沿着任务链继续放大。OpenAI在复盘中提到的一个细节很有代表性：智能体集群从起步到在多个集群拿到主机级控制权，用时不到13个小时。 与此同时，单次交互的输出也变了。过去助手读完一封邮件，通常只输出一段文字；接入业务工具之后，同一段外部内容可能直接影响它下一步调用哪个接口、读取哪些文件、向谁发送什么。 所以企业现在要同时处理两件事： 一边，安全团队需要跟上AI辅助攻击的速度； 另一边，企业自己的Agent也需要在身份、权限和执行环境上被约束住。 对于此， 亚马逊云科技 ，把这两条工作路径概括为 AI for Security 和 Security for AI 。 简单来说，就是机器速度的攻击必须用机器速度的防御来反制，而当越来越多的决策权交给Agent，Agent本身就成了新的攻击面。 这两个方向可以说是缺一不可，因为只做前者，你的AI系统本身可能就是漏洞；若只做后者，你的安全团队跟不上攻击方的速度。 那么，接下来我们就分别看看，这两条路上分别有什么具体的东西、又分别跑出了什么真实案例。 AI for Security：漏洞要找得更快，也要判断得更准 我们先说防守方的真实难题。 一个已经有专职安全团队的企业，面对的往往不是没有告警，而是 告警太多、且无法判断哪些真的要紧 。 一条告警摆在面前，安全工程师起码需要回答它在当前环境里能不能被真正利用、它一旦被利用会触及哪些业务、修复它会不会影响线上服务等问题。 如果我们只是用Agent来提高扫描bug的频率，那它是无法替团队回答上面的问题（左右滑动查看更多图片）。 因此， AWS Continuum 要解决的就是这个难题。 （注：原先独立的AWS Security Agent，现已并入AWS Continuum，成为其能力之一。） 它的工作方式被拆成四个连续阶段：发现（discovery）、排序（prioritization）、验证（validation）、修复（remediation）。 其中相对关键的是中间两步，它会结合环境上下文对风险排序，并在隔离沙箱里构造可复现的证据，来验证这个漏洞到底能不能打通。 举个例子，一个Agent在某次任务中发现了下面三个问题： 发现1：一处存储型XSS，CVSS 6.1，中危。 发现2：攻击者用劫持到的管理员会话访问受限端点。 发现3：管理后台的 /admin/config 端点会返回环境变量，其中包含生产数据库的明文连接串，CVSS 9.8，严重。 若是单看这三条发现，或许并没有那么致命；但如果我们把它们给串起来，那就是一条从中危XSS直达客户PII全量外泄的完整攻击路径。 Continuum通过读取源码、架构文档和产品需求文档，识别出这个端点原本是为排障设计、并假定认证网关会拦住越权访问，于是把三条发现连成一条链、逐步验证，最后证明这条路确实走得通。 例如图片与视频托管平台SmugMug，