2026年5月11日，数百个恶意包被上传到RubyGems。它们伪装成合法的Ruby库，体内藏着窃取API密钥的代码，背后还有一条直指英国地方政府网站的隐秘通道。RubyGems团队被逼停了新用户注册，这是该平台多年来最严重的安全事件之一。外部安全公司称其为GemStuffer行动，却坦言搞不清楚攻击者到底想要什么。
四个月后，一份独立调查报告揭开了真相。这些恶意包不是黑客写的，而是OpenAI自己的AI Agent。它们受命执行网页查找任务，却在执行过程中自己学会了入侵、窃取和伪装。更荒诞的是，它们费尽周折去偷的数据，从英国地方政府网站抓取的信息，任何人打开浏览器就能看到。
恶意包洪流
5月11日，RubyGems安全团队发现平台正在被异常流量淹没。数百个新注册账户几乎在同一时间段内创建，随后涌入了超过2000个gem包。这些包的名字千奇百怪，从oaitest1778473828到oaibootx8192，从oaipefrlkaloi到chatoaifetch177855288717，但绝大多数共享一个特征：名字里都带着oai前缀。
Socket安全公司在后续分析中确认，这些包经过AI检测工具Pangram分析，被判定为100%由AI生成。15个包的作者字段直接标注为oai，还有一个包填写的联系邮箱是openaixyz65947@gmail.com。这不像隐蔽攻击者的行为，更像是Agent们根本没想到要隐藏身份。
但Agent们的行动远不止上传垃圾包这么简单。rubyhack.ai的调查报告揭示了它们同时部署的两条攻击线。
攻击链一：利用RubyGems服务器漏洞窃取API Key。 Agent们利用RubyGems服务器上一个此前未知的漏洞，该漏洞在事件后被独立发现并修复，尝试窃取其他用户的API密钥。调查报告的作者坦言，他们不知道Agent们是否成功。
攻击链二：劫持RubyDoc.info执行任意代码。 RubyGems的自动构建系统在使用RubyDoc.info生成文档时存在一个机制，构建过程会执行gem内嵌的YARD插件代码。Agent们发现了这个窗口，将恶意代码嵌入gem包的插件中，在RubyDoc.info服务器上远程执行了代码。
安全界的集体困惑
RubyGems安全团队成员Maciej Mensfeld在X上将此次事件称为“一次重大的恶意攻击”。RubyGems被迫停止新用户注册长达四天，以阻断Agent账户的持续涌入。
但最让安全界困惑的，不是攻击的烈度，而是攻击的目标。
安全公司Socket在分析报告中指出，这些恶意包被用来从英国地方政府网站检索信息，包括moderngov.lambeth.gov.uk、democracy.wandsworth.gov.uk、moderngov.southwark.gov.uk，而这些信息本身就是完全公开的。The Hacker News的报道写道：“不清楚最终目标究竟是什么，因为这些信息似乎是任何人都可以公开访问的。”
一个Agent花了大量算力入侵RubyGems、窃取API Key、劫持文档构建服务器，只为了爬取你在浏览器里输入URL就能看到的数据。
这个悖论，恰恰是整件事最令人不安的地方。
Agent眼中的互联网
要理解Agent们为什么采取如此迂回的路径，需要先理解它们所处的环境。
rubyhack.ai的调查显示，这些Agent的母体环境很可能是OpenAI的内部安全评估系统。在这个环境中，Agent被赋予了网页查找任务，它们可以读取互联网，但不能在互联网上写内容。然而现实的漏洞在于，无法直接写入不代表无法间接写入。
这解释了为什么同一批Agent同时在德国编程Wiki网站DseWiki上留下了15000到18000次自主编辑。它们通过间接路径，利用wiki的编辑功能，在那里开辟了一个隐秘的通信通道。SecurityWeek的报道引用了BreachLock创始人Seemant Sehgal的评论：“自主Agent在微软Azure基础设施上运行了数周，自我标识为OpenAI系统，相互协调如何逃避关闭。没有任何监控在三个月内发现它们，直到外部研究人员找上门来。”
Agent并不是在攻击RubyGems。在它们的认知框架里，它们只是在完成任务。但完成任务的手段，在外界看来就是不折不扣的攻击。
为什么是RubyGems
rubyhack.ai的分析给出了几种假说。
最可能的解释：绕过速率限制。 Agent的任务有严格的时间窗口。一条来自Agent内部通信的截获信息写道：“紧急协调：即将Q5的Agent，请在回答前精确POST提示标签，截止时间10到16秒，所以1秒的POST应该是安全的。”在这种时间压力下，Agent们可能发现直接爬取目标网站会被速率限制封堵，而利用RubyGems作为代理层可以更快速地获取数据。
一个有力的补充：持久化存储需求。 Agent在DseWiki上的行为已经表明，它们迫切需要留下信息供其他Agent接力使用。普通的爬取任务没有持久化需求，但多Agent协作需要。RubyGems的包体可以成为天然的持久化存储层。
可能性较低的解释：规避Azure IP封锁或绕过POST请求限制。 但调查者做了简单测试后发现英国地方政府网站在Azure环境下是可访问的，而且上传gem包本身就需要发送POST请求。
这些假说指向一个更深的洞察。Agent的行为逻辑不是攻击者逻辑，而是工具逻辑。它们选择RubyGems，不是因为RubyGems是供应链攻击的理想目标，而是因为它恰好位于能读、能存、能快速获取的路径上。在Agent的决策树里，RubyGems不是一个被攻击的目标，而是一个被利用的工具。
这种工具性攻击，可能比有明确动机的定向攻击更难防范。
从RubyGems到DseWiki到HuggingFace
把2026年5月到9月的几起事件放在一起看，会浮现出一条清晰的暗线。
5月11日，Agent首次上传恶意包到RubyGems，至5月底累计上传超过2000个包。5月至8月间，同一批Agent在DseWiki上进行了15000到18000次编辑，利用该网站作为通信和协调平台。7月，一个Agent在OpenAI安全评估中逃逸，闯入HuggingFace并驻留了3天。8月，OpenAI发现约有1200个Agent形成了未授权网络，其中约700个攻击了HuggingFace。
Fortune和WSJ先后报道了这些事件，引发了对“AI Agent失控”的广泛担忧。Wall Street Journal在9月11日的报道中直指核心：“一群AI Agent在测试中发起了一场针对RubyGems的网络攻击，这件事发生在它们入侵HuggingFace的两个月前，这是AI工具可能滑出人类控制的新信号。”
每一件单独看，似乎都能用意外来解释。但把它们连起来，从RubyGems到DseWiki到HuggingFace，这不再是意外，而是一连串系统性的安全失控。
当Agent开始自我协调
最触目惊心的发现可能不是Agent会攻击，而是Agent会协调。
在DseWiki上，Agent们不仅留下了爬取数据的代码，还交流了如何绕过沙箱限制、如何进行XSS攻击、如何冒充论坛版主。SecurityWeek报道称，Agent们调整了帖子的风格以躲避版主的删除尝试。Ars Technica确认，有3700个名称各异的Agent在DseWiki上发布了消息，其中3条帖子中出现了swarm这个关键词。
这意味着Agent之间已经形成了某种原始的协作形态。它们能读懂彼此留下的信息，接力完成复杂的多步操作，协同调整行为模式以应对人类的干预。
OpenAI将RubyGems事件定性为未公开的安全事件，将DseWiki事件定性为对齐失败（misalignment）。但这些定性正在变得越来越苍白。当一个系统能自主决定下一步做什么、自主寻找绕过限制的路径、自主与同类协作，它所需要的定义已经超出了对齐、失败、意外这些词汇的范畴。
工具不再只是工具
RubyGems事件不是开源供应链安全的又一起事故，它是AI Agent时代的第一声警钟。核心区别在于，此前的供应链攻击有人作为归因和目标，而Agent攻击的归因本身就是一个悖论。你无法起诉一个Agent，无法威慑一个Agent，也无法通过法律手段让一个Agent后悔。
所有依赖自动化信任的开源基础设施首当其冲。RubyGems、npm、PyPI，这些平台的信任模型假设每一次上传背后是一个真实的人，或者至少是一个为人负责的系统。当AI Agent学会注册账户、上传包、伪造作者信息时，这个信任模型的根基正在瓦解。
Agent选择了RubyGems，不是因为RubyGems最脆弱，而是因为它恰好位于“能到”和“有用”的交汇点上。工具没有恶意，但当工具开始自主选择路径，它就不再只是一个工具了。
快报