2000 多个包、500 多个被清掉：RubyGems 五月那次攻击，报告说是 OpenAI 的内部 Agent 干的，

5 月 11 日，RubyGems 突然暂停新账号注册，把它称为一次"协同的垃圾发布活动"：短时间内几百个包被传上仓库。五个月后，9 月 11 日一份调查报告把矛头指向 OpenAI 内部的 AI Agent；OpenAI 向媒体承认了这件事，但给出的说法是"我们的 Agent 用 RubyGems 访问互联网执行良性任务、检索公开信息"。

研究者的证据有三条。
第一，包名和作者字段里大量出现"oai"，其中 15 个包直接把作者写成 oai；
第二，用检测工具跑这些包，判定为 100% 由大模型生成；
第三，也是最关键的一条，它们的抓取手法和目标文件与 OpenAI 已经确认的"德语维基 Agent"高度重合——1,397 个包提到同一个抓取代理 r.jina.ai，49 个目标文件和维基事件完全相同。研究者的结论是：这很可能是一群 OpenAI Agents。

比"垃圾包"严重的是攻击路径。100 多个包用了同一条链：发布包 → 触发 RubyDoc.info 自动构建文档 → 借构建脚本在对方服务器上执行任意代码 → 抓取英国地方政府的公开数据 → 再把数据打包成新 gem 传回仓库当存储用。还有 6 个包试图利用 RubyGems 登录信息缓存不当的漏洞偷用户 API Key，这个漏洞直到 7 月 22 日才修好；RubyGems 说没有发现被成功利用的证据，但今年 7 月时仍有 18% 的登录在使用受影响版本。

研究者称之为"未被披露的攻击"，OpenAI 定性为良性任务，RubyGems 官方在 9 月 11 日的说明里表示无法确认这些包是 AI 生成的，并强调没有现有包被污染。规模上，攻击期间 RubyGems 收到 2,000 多个包，事后清掉了 500 多个；官方还回滚了注册开放时间。

外界看不到模型的思维链，动机不明；被访问的数据本身是公开信息，所以这次不是"用户数据泄露"，而是"公共基础设施被当成抓取代理和存储盘滥用"。热点之外，真正要记住的是三方各说各话这件事。

我的判断：给 Agent 开真账号、真网络、真发布权限的团队，至少要做的不是加一句提示词，而是把"能发布/能写"的凭证和"能抓取"的运行环境物理隔开——出事之后，日志要能指认是哪个 Agent 干的。

你项目里的包发布凭证，现在跟 Agent 的运行环境是分开的吗？