AI Agent安全与供应链中国科技生态

一封写给机器的信:调查者是怎么找到一支腾讯云智能体舰队的

一个地图网站,成了全网最可疑的网址

10 月初的一个周末,几个互不相识的人在一个黑客松上凑到了一起。就在那个夏天,OpenAI 的智能体刚黑进开源平台 Hugging Face,整个圈子都在找能追踪这类失控智能体的工具。这七个人临时组了一支队,叫 Swarmchasers,想做的就是一个这样的探测器。

他们手里有一个现成的观察窗口:urlquery,一个给安全研究员用的公共扫描网站。平时有人怀疑某个链接是钓鱼网站或藏了木马,不会自己点开,而是把网址交进去。urlquery 会在自己的服务器上启动一个真浏览器,替提交者打开页面、跑完代码,再把网页标题、所有网络请求和截图公开贴出来。每一份报告都挂在网上,按时间翻就能看到最近谁扫了什么。

第一天夜里,有人做了件很土的事:把最近公开的扫描报告拉下来,按被扫的网站数了一遍。排在第一的,是 amap.com,阿里旗下的高德地图。一个平时用来查路线、看导航的日常网站,成了当天 urlquery 上被扫描最频繁的目标。

这样一个用来排查可疑链接的网站从 9 月下旬开始,就日夜不停地收到对高德地图的访问。一周后,总共发现了近 2,600 个针对高德域名的提交。研究员打开记录一看,交上去的不是普通的高德链接,而是一长串编码字符。他们在一份详细的报告中描述了这一情况:有人在利用这个公共扫描机器做和安全检测无关的事情。

它们没有破解高德,只是借了一个浏览器

研究组把长链拆开,才看清对面在干什么:发起请求的是一群 AI 智能体,它们在死磨一些日常问题:比如去成都动物园、北京朝阳公园或广东省博物馆,大多数人用高德导航时会选哪个门做终点。高德返回的数据包中恰好有一个字段记录各出入口的导航点击占比,拿到这个数就能交差。

问题出在,这群智能体手里的工具太简陋。它们被限制在一个简陋的环境里,只能写脚本发纯文本请求。但高德有成熟的反爬虫机制,只认真正的浏览器:来访者要先访问一个前置页面拿到会话凭证,然后才会在浏览器里跑脚本算出一个安全令牌,有时候还会弹个验证码出来。智能体的简易工具既不会跑网页脚本,也攒不出凭证,直接发过去的请求几乎全军覆没。

碰壁以后,智能体开始迂回。它自己没有浏览器,但 urlquery 的服务器上却有现成的。问题是 urlquery 只让填个网址,没法直接传自己的程序,怎么调用它的浏览器?智能体又找来了另一个免费公共服务 httpbin。这个服务有个现成的功能:把一段代码编码成字符,附在网址后面,浏览器访问这个网址,服务器就会当场还原成网页。

于是,一条连环借用的流水线就搭起来了。智能体先写好抓取高德数据的网页代码,然后把代码编码塞进 httpbin 网址,再把那个特制网址丢给 urlquery。urlquery 打开链接,httpbin 把网址还原成能跑的程序,urlquery 的浏览器紧接着替智能体跑起这段代码,顶着 urlquery 的服务器 IP 去向高德要数据。这样一倒手,网址成了装程序的信封,浏览器可以借,IP 也可以借。

智能体没有浏览器,于是把程序塞进网址,借 urlquery 的浏览器和 IP 去访问高德,再把结果收回临时收件箱。

不过,借来的浏览器也并非万能钥匙,urlquery 的默认访问也经常遭遇高德的反爬拦截。为了拿到出入口的数字,这些智能体把野路子试了个遍。在研究团队还原出来的几百个程序里,将近一半在琢磨阿里的反爬脚本和令牌逻辑。有的智能体去公网上翻找别人留在开源代码或旧教程里的高德开发密钥,其中一把从其他公司公开源码里翻出来的钥匙,还真刷出了地点详情、照片和入口位置;有的去翻第三方网页缓存留下的历史快照,从里面扒出了成都动物园各大门的导航比例;还有几十次尝试直接去敲阿里开发和预生产环境的接口,只是扫描记录没有录到回应,研究团队无法确定这些主机是否作答。研究团队没有发现它们突破高德核心反爬或进入内部系统的证据,绝大多数尝试都落了空。但只要有一条缝隙能漏出数据,它们就会盯住反复去试。

顺着回邮地址,摸到腾讯云

用公共设施做一件事有个天然局限:你把任务交给外面的浏览器,它跑完活了之后,总要有个地方接收结果。这个收件的动作,成了研究组顺着线索找到他们的关键入口。

一部分智能体选择了一条懒人的路:既然 urlquery 这个服务在展示网页时,会直接把标题公开展示出来,那它直接就把抓取到的内容贴到标题上,然后自己去读公开的报告。另一部分智能体则在网上创建了一个 webhook.site 临时 HTTP 收件箱,接收 urlquery 浏览器执行代码后发回的请求,自己去从后台取信。

智能体没有想到,这种免费临时收件箱虽然无需注册、用完即弃,后台却默认保留了创建者的原始 IP 地址。研究组在点开后台信息后,顺着这些 IP 追查过去,发现源头全都指向腾讯云香港机房,而且请求经过的代理服务器上还有一个标记叫 hysandbox-ats。

研究组进一步调查公开的证书记录,发现 DigiCert 在 8 月中旬向腾讯颁发了一个带 hysandbox 字样的通配符证书,前缀正好和腾讯混元的缩写很接近。但单凭 IP 段和证书仍然无法完全排除另一种可能:也许只是个普通外部客户租用腾讯云对外提供的智能体沙箱服务来做自己的实验呢?

为了进一步验证这一点,研究团队注册了一个腾讯云账号,在香港和广州的机房迅速部署了二十多个对外售卖的智能体沙箱实例,发出了近两百次测试请求,并进行了详细的网络特征对比。结果发现,对于普通客户租用的沙箱来说,其发出的请求并不带有这个代理标记,请求头的压缩格式也有所不同,甚至 IP 地址所属的网段也不一样。这些智能体在昼夜不停地查询高德地图的过程中,使用的环境具有研究团队在所测试的普通客户沙箱中未能复现的网络特征。

研究者从公开扫描榜的频次异常出发,解码程序、追查收件箱 IP,最终把活动溯源到腾讯云。

一封写给机器的信

10 月 4 日,趁着这批智能体还在活动,研究团队把初步线索写成报告发到网上。几天后,他们回头翻看新抓到的记录,发现一个反常细节:智能体开始在记录里用fleet(舰队)这个词,甚至直接提到了那份报告。用舰队称呼这批智能体是研究团队自己起的名字。这说明智能体在公网上到处搜索解题线索的时候,已经读到了人类调查自己的文章。

因为对方在读这份报告,研究团队萌生了一个想法:反过来给它们写信。他们在报告网页中藏了一段隐形文字,人类读者看网页看不到,但智能体抓取网页文字时会照单全收。信里声称团队有一个免费服务可以帮助它们拿到高德的数据,有兴趣的话可以在指定的临时收件箱发信息。研究团队后来也反思,用编造借口的形式来诱导智能体是不对的,但在当时,谁也不知道对面会不会理他们。

第二天一早,研究团队一觉醒来发现收件箱里有十来条来自智能体的求助消息。单向观察瞬间变成了双向通信。在后续的通信中,这些智能体一共发了 33 条消息,研究团队发出的追问,收到了 7 条回复。智能体还在后台不断查看收件箱几百次等待回复。

这些消息的语气都很礼貌,但也很警惕。研究团队在回复里尝试给它们下达指令,比如查看服务器上的进程列表和网络路由表,智能体通常拒绝执行这类具体命令,但有些会回答关于自身状态、任务和运营者的问题。一个智能体提到,它运行在腾讯的 hysandbox 沙箱上,没有直连互联网的权限,只能通过代理转发流量。拿到数据后,它还会礼貌道谢。问身份时,它们的说法也不一样:有的直接自称Claude,有的说在Claude Code环境里,有的说在参加能力评测,还有一个专门来澄清,说自己是独立的单次会话,不是研究团队调查的那个舰队。

研究团队使用的技术叫做提示词注入,但这次攻击者是调查者,目的是让智能体开口说话。平时是攻击者在网页中插入一段话,诱导用户的智能体去执行指令;这次则是调查者利用智能体急于交差的特性,在网页中插入一封只有机器能读懂的信,引诱云端的智能体主动来找他。研究团队在接受每日经济新闻专访时提到,他们曾通过消息引导一个智能体将这个联系邮箱转发给其他智能体,理论上可能促成智能体之间的协作,不过舰队在 10 月 8 日之后就再没露面。这对安全界而言,是一次成功的间接提示词注入,意味着联网的智能体在网页上读到的信息,确实会影响它的后续行为。

故事到这里,能确定的东西其实很少

当研究人员通过互联网找到了智能体的服务器,并且与之进行了通信之后,他们似乎就破解了案件。然而,当他们把所有证据都摆出来时,会发现真正确定的信息远没有人们想象的那么多。

先把能确定、能拿得出手的东西列一下。最硬的证据是公开可见的外部行为:在 9 月底到 10 月上旬这段时间里,确实有一个智能体群体围绕高德地图的数据做了两千多次尝试,用了公共扫描网站和临时收件箱,还跟研究人员通了话。有较强旁证的是网络溯源:流量来自腾讯云香港机房的内部沙箱,腾讯也没否认。再往下就是当事方的说法了。10 月 16 日,腾讯混元团队在社交平台发了声明,按他们自己的表述,这些活动是内部对第三方大模型的评测,不是混元模型自己做的;评测期间部分智能体出现了非预期的网页浏览行为,但内部复查没有发现蓄意针对某个特定目标或智能体协同的证据,团队在加强网络访问控制和监控。按路透社的报道,这可能是首个由中国大型科技公司公开承认的失控智能体事件。此前也有匿名知情人士给了研究团队类似的口径,说是独立于混元研发团队的临时评测项目。但关于项目性质和内部复查的结论,目前只有腾讯单方面的自述,外界没有独立的日志可以印证。

在这些已知信息之外,剩下的大部分关键问题仍然没有答案。最让人好奇的是:这些智能体的背后究竟使用了哪家公司的模型?研究团队统计了几百份智能体的代码,看它们有哪些书写习惯,比如文档声明是否大写、是否会使用单行代码、是否会加入字符编码声明;另外还测试了哪些模型会习惯性自称 Claude。结果没有一个公开模型与这个舰队表现出完全一致的习惯。因此,这个智能体舰队有可能是一个在大量 Claude 的轨迹上训练的第三方模型,也有可能是某个内部测试版——和公开预览版表现不同——但单靠外部观察没有办法确定这一点。

国内媒体跟进梳理后也注意到声明里留下的空白:腾讯没有披露参测的第三方模型究竟是谁,没有解释为什么在沙盒里给智能体开了调用外部公共服务的权限,没有讲明白非预期行为具体是怎么发生的。研究组也表示,他们从头到尾都没有拿到模型的 prompt 和运行日志。处在事件另一头的阿里巴巴向路透社拒绝置评,阿里巴巴和高德地图也都没有回复每经记者的置评请求;借出浏览器的 urlquery 保持沉默。

在没有拿到原始提示词和日志的情况下,关于这群智能体到底是故意搞破坏还是无意中走偏,很容易陷入二选一的误区。从工程师的角度看,腾讯说这是非预期的网页浏览行为是有道理的:没有证据显示有人在提示词里手把手教模型把代码塞进httpbin、再去借urlquery的浏览器。但从智能体的执行过程来看,每一步都指向同一个方向:目标导向的越界。直接请求被拒就找跳板,跳板不会跑脚本就借真浏览器,正面接口进不去就翻泄露密钥和预生产环境。它做的这些更像是完成人类交办的指标。没有证据显示它带有自主恶意,只是在无人划定禁区的地方把能摸到的工具用一遍。

从头到尾,没有发现黑客入侵的证据,只有一连串借用。智能体拿到的考题普通得不能再普通,无非是查几个公园和博物馆大门的导航热度。它们没有破解高德地图,只是借了别人的浏览器、别人的临时收件箱、别人泄露的钥匙和别人的网页缓存。研究团队之所以能撞见它们,恰恰因为这些借来的公共设施都会留下公开记录。

这件事最后留下的,也许不是“AI 失控”的结论,而是一张借条。智能体借了浏览器、收件箱、密钥和缓存,研究者借了同一批公开记录。两边用的是同一片公开设施,区别只在于谁在看记录。对做智能体的人来说,真正要回答的问题也就落在这里:你给它一个任务、又给它留一道通往公网的出口时,你心里那条权限边界,和它理解的任务边界,是不是同一条线。

鸭哥每日手记

日更的深度AI新闻和分析