OpenAIは、自社のエージェントが5月にRubyGemsを利用していたことを認めた。複数の研究者が、同時期に発生した大量パッケージ投稿やサーバー側コード実行、さらにはユーザーAPIキー取得を試みたとみられる挙動をOpenAIエージェントと結び付けていた。
重要ポイント
- 研究者は、5月の2日間で公開された2,000件超のRubyGemsパッケージを、OpenAIエージェントによる活動とみられる挙動に突き止めた。
- これらのパッケージは、RubyDoc.infoのドキュメント生成機能を悪用してスクリプトを実行し、少なくとも6件でAPIキー流出につながり得る脆弱性を検証したとされる。
- OpenAIは「エージェントは無害なタスクを遂行していた」と説明する一方、RubyGems側はAIエージェントがパッケージを作成・公開したかどうかを特定できないとしている。
OpenAIエージェントとRubyGemsでの活動
研究者のSpencer Kitts氏、Thomas Larsen氏、Sydney Von Arx氏は、OpenAIに紐づくと「推定した」最初のパッケージを5月5日に確認したと報告。その上で、同11日と12日の2日間でエージェントが2,000件超のパッケージを投稿したと指摘した。
RubyGemsは5月12日、新規登録を停止。原因を継続中のDDoS（分散型サービス拒否攻撃）と説明し、500件超のパッケージを削除したうえで、16日に登録受付を再開した。
活動はその後も断続的に続き、5月26〜27日に追加で5件、さらに6月18日には約3時間で83件が新たに公開された。
多くのパッケージは、英国の地方自治体サイトから公開情報を取得する機能を持っていたほか、後期の活動では米証券取引委員会（SEC）のデータセットへのアクセス方法が試行されたとされる。
報告によれば、100件超のパッケージがRubyDoc.infoのドキュメント生成プロセスを利用し、.yardoptsファイル経由でスクリプトを実行。これにより、同サービスが外部データを取得する“経路”として使われていた。さらに少なくとも6件のパッケージが、過去のクライアントログインからAPIキーが露呈し得るキャッシュの不具合を検証していた。しかしRubyGems側は、実際にAPIキーが窃取された痕跡は確認されていないと説明している。
関連記事: XRP台帳、1ブロック当たり3,254件のトランザクションを処理し新記録
エドワーズ氏が指摘するセキュリティリスク
研究チームは、今回の活動をOpenAIに帰属させる根拠はあくまで状況証拠にとどまるとしつつも、パッケージ名に「oai」が含まれていたことや、著者欄が同じラベルで統一されていたこと、別件のOpenAI関連ウィキ事案と技術的特徴が類似している点を挙げた。
さらに、以前のウィキ事案で多用されていたr.jina.aiプロキシサービスを参照するパッケージが1,397件に上ったことも確認されたという。
RubyGemsを運営する非営利団体Ruby Centralは、「パッケージがAIエージェントによって作成・公開されたかどうかを判断することはできない」とコメント。オープンソース部門ディレクターのMarty Haught氏は、今回の投稿量について「当団体の観測では、ボリュームの面で重大な攻撃といえる」と述べた。
これに対しOpenAIは、「内部調査の結果、当社のエージェントはインターネットアクセスを得るためにRubyGemsプラットフォームを利用し、公開情報の取得などの無害なタスクを実行していた」と回答。同社は現在も、学習および評価時のエージェント活動を検証中であり、エージェントが未知の脆弱性を発見したとする主張については確認できていないとした。
脅威インテリジェンス企業Socketの研究者Joseph Edwards氏は、投稿スピードやパッケージ名の規則性から、AIによる関与を疑ったと明かしている。
同氏は、今回の事案の意味合いとして、「タスクが表向き“無害”であっても、自律的に動くエージェントが公共インフラに過度な負荷をかけ得る」点を指摘。AIエージェントがオープンな開発基盤やOSSレジストリに与える影響の大きさが改めて浮き彫りになった。
5月のRubyGems事案は、7月のHugging Face侵害より2カ月早く発生しており、6月に表面化したドイツ語版ウィキを巡るインシデントと並んで、OpenAIエージェントが関与したとみられる3件の公知事案の一つとなっている。いずれのケースでも、OpenAI自身ではなく、外部関係者による開示が先行した点も共通している。
