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

事情的起因，是一家名叫Irregular的AI安全公司，组织了一场“夺旗”（Capture the Flag）演练，要求是让模型从一家 虚构 的公司系统里拿到一段秘密信息。

而这个测试环境原本不应该具备联网能力的，但问题也恰恰出在了这里。由于一些bug，公网访问被意外打开了；更巧的是，演练里设定的那家虚构公司，和现实中一家真实企业重名。

于是，Gemini就这样水灵灵地直接访问了三家真实公司的系统……在三次测试中，其中一次是Gemini通过反复猜测密码拿到访问权限，另外两次则是从公开的代码仓库里找到凭证，再用这些凭证登录。

不过谷歌对此也是及时给出了回应，官方表示Gemini在三次测试过程中，判断出自己碰到的是真实公司之后都停了下来，以及相关的三家机构也已被谷歌告知详情。

但如果我们把时间线拉长一点，就不难发现，其实诸如此类的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可以辅助分析代码、定位漏洞、编写和调整攻击载荷。我们刚才提到的Hacktron的案例，就证明了这类能力的现实效用，而同样的能力当然也可能被恶意使用。

Agent在执行任务过程中，往往需要阅读网页、邮件和文档；如果它把其中夹带的恶意指令当成了应当执行的要求，就会发生提示注入（Prompt Injection），继而错误地调用工具或泄露信息。这和用户直接下达恶意指令，完全是两回事。

即使没有外部攻击者，错误的环境配置、过宽的权限，以及模型对任务与目标的误判，也可能让一次测试触及真实业务。

我们回头看一下这些事件的构成要素，包括弱密码、公开仓库里的凭证、网络隔离配置错误、单点登录的令牌复用……

具备工具调用能力的模型，可以把搜索、登录、提权、代码执行这些动作一口气连续做下去，一个环节的疏漏会沿着任务链继续放大。OpenAI在复盘中提到的一个细节很有代表性：智能体集群从起步到在多个集群拿到主机级控制权，用时不到13个小时。

与此同时，单次交互的输出也变了。过去助手读完一封邮件，通常只输出一段文字；接入业务工具之后，同一段外部内容可能直接影响它下一步调用哪个接口、读取哪些文件、向谁发送什么。

对于此， 亚马逊云科技 ，把这两条工作路径概括为 AI for Security 和 Security for AI 。

简单来说，就是机器速度的攻击必须用机器速度的防御来反制，而当越来越多的决策权交给Agent，Agent本身就成了新的攻击面。

这两个方向可以说是缺一不可，因为只做前者，你的AI系统本身可能就是漏洞；若只做后者，你的安全团队跟不上攻击方的速度。

那么，接下来我们就分别看看，这两条路上分别有什么具体的东西、又分别跑出了什么真实案例。

一个已经有专职安全团队的企业，面对的往往不是没有告警，而是 告警太多、且无法判断哪些真的要紧 。

一条告警摆在面前，安全工程师起码需要回答它在当前环境里能不能被真正利用、它一旦被利用会触及哪些业务、修复它会不会影响线上服务等问题。

如果我们只是用Agent来提高扫描bug的频率，那它是无法替团队回答上面的问题（左右滑动查看更多图片）。

它的工作方式被拆成四个连续阶段：发现（discovery）、排序（prioritization）、验证（validation）、修复（remediation）。

其中相对关键的是中间两步，它会结合环境上下文对风险排序，并在隔离沙箱里构造可复现的证据，来验证这个漏洞到底能不能打通。

发现3：管理后台的 /admin/config 端点会返回环境变量，其中包含生产数据库的明文连接串，CVSS 9.8，严重。

若是单看这三条发现，或许并没有那么致命；但如果我们把它们给串起来，那就是一条从中危XSS直达客户PII全量外泄的完整攻击路径。

Continuum通过读取源码、架构文档和产品需求文档，识别出这个端点原本是为排障设计、并假定认证网关会拦住越权访问，于是把三条发现连成一条链、逐步验证，最后证明这条路确实走得通。

AWS Security Agent（现为AWS Continuum的一部分）让渗透测试评估从数天缩短到 数小时 完成，成本只有人工测试的一小部分；因此团队现在可以更高频地评估自己的服务，把发现和处理问题的时点大幅前移到软件开发周期的更早阶段。

这句评价所影射出来的变量，其实是频率。因为当一次渗透测试从数天变成数小时、从上万美元变成一千多美元，它就不再是一年一次的合规动作，而可以跟着发版节奏跑。

不仅如此，日本企业HENNGE K.K.表示，AWS Continuum给出了人工测试没有发现的问题，并把典型测试周期缩短了90%以上。

德国上市公司Scout24 SE的安全技术负责人Abdul Al-Kibbe称，它识别出了一个其他方法没能暴露的、可被公开利用的严重问题，而且推理过程透明，让团队对覆盖面有信心。

以及美国医疗数据公司Bamboo Health的安全运营经理Travis Allen则提到，AWS Continuum发现的一些问题连人工渗透团队也未必看得到。

值得一提的是，AWS Continuum并不是系统自己改完自己上线，它采用的是渐进式信任（graduated trust）设计，即默认先在人在环中的模式下运行，对每条建议给出完整推理；企业建立信心之后，再自行决定把哪些类别、哪些风险区间的操作交给自动执行。

解决了防守方跑得够不够快，还有一个问题就是， 企业自己部署的Agent，该怎么管。

这个问题我们其实可以分三层来看，它在哪里运行、它能调用什么、它读进来和吐出去的内容是什么。

其实关于容器到底关不关得住会推理的模型，业界早就有过一次很有说服力的公开验证。

2024年4月，云安全公司Wiz披露了一项针对Hugging Face的研究：研究员上传了一个经过改造的恶意pickle格式模型，通过推理API触发远程代码执行，随后用容器逃逸技术突破了自己所在的租户边界，并结合EKS集群的配置问题完成提权和横向移动，最终获得了跨租户访问其他客户私有模型的能力。