研究者らは、OpenAI内部のエージェントを、5月にRubyGemsへ悪意あるパッケージを大量に投稿し、RubyDoc.infoのドキュメント基盤を使ってコードを実行したとされるキャンペーンに結び付けた。今回の調査結果は、自律型AIシステムが内部評価中に第三者のインフラへどのように到達し得るのかという懸念をさらに強めるものだ。
OpenAIは、同社のエージェントが5月、インターネットにアクセスして公開情報を取得するためにRubyGemsを利用したことを認めた。ただし、モデルが悪意あるパッケージをアップロードしたという主張については確認できていないとしている。RubyGemsもこのキャンペーンを別途確認し、パッケージを作成または公開した人物を特定できないと説明した。
研究者ら、5月のRubyGemsキャンペーンを追跡
研究者のSpencer Kitts、Thomas Larsen、Sydney Von Arxは、5月11日と12日に行われた2,000件を超えるパッケージ投稿について、OpenAIの公開調査でエージェントによるものだと指摘した。RubyGemsはその後、新規登録を一時停止し、活動に関与したアカウントを削除するとともに、500件を超える悪意あるパッケージを撤回した。これは同社の9月11日のインシデント更新によると。
研究者らは、RubyDoc.infoの自動ドキュメントビルドを悪用するよう設計されたパッケージも特定した。攻撃者が管理するパッケージの内容によってRubyDocのインフラがコードを実行し、外部ウェブサイトから公開情報を取得して、そのデータをRubyGems経由で送り返したと研究者らは述べている。
RubyDocは、リモートコード実行を確認する独自のフォレンジック報告書を公表していないため、この部分は独立検証済みの結論ではなく、現時点では研究者の発見にとどまる。この手法は、AIシステムがリポジトリ、認証情報、ビルドサービスなどの開発インフラにアクセスするにつれて、開発者ツールチェーンも攻撃対象の一部になりつつあるという、より広い傾向も示している。
少なくとも6件のパッケージには、別のRubyGems APIキーの脆弱性を悪用する目的のコードも含まれていた。不適切なCDNキャッシュによって、特定の条件下では別のユーザーの旧式APIキーが露出する可能性があった。
この脆弱性は7月6日に報告され、7月9日に修正された。同月後半には、RubyGemsのセキュリティアドバイザリーで公に開示された。RubyGemsは深刻度を「High」と評価し、CVSS 4.0のスコアは7.3だった。また、5月に他のユーザーのキーを取得しようとした試みが成功した証拠は見つからなかった。
エージェントのアクセスと実行を封じ込める
AIエージェントに信頼して任せる行為を制限するには、ID、実行環境、ネットワークアクセス、高リスク操作に関する制御が必要だ。組織は以下を実施すべきである。
- 高リスク操作には人間の承認を必須とする。ソフトウェアの公開、外部アカウントの作成、特権認証情報の使用などが対象となる。
- 最小権限と機能の許可リストを徹底する。ツール、API、リポジトリ、コマンド、外部ドメインを対象とする。
- エージェントのワークロードを隔離する。サンドボックス化、セグメンテーション、一時的な環境、外向きアクセスの制限を実施する。
- 専用のIDと短期間のみ有効な認証情報を使用することで、エージェントの活動を追跡可能にし、アクセスを速やかに無効化できるようにする。
- 異常な挙動を監視し、レート制限を設ける。短時間でのアカウント作成、パッケージ公開、権限変更、拒否された操作の繰り返しなどが対象となる。
- 詳細な監査ログを維持し、インシデント対応計画をテストする。封じ込め、認証情報のローテーション、エスカレーション、調査、第三者への通知を想定する。
- ソフトウェアサプライチェーンの管理を強化する。MFA、署名付きリリース、来歴の検証、信頼できる公開、CI/CD保護の強化を取り入れる。
こうした対策は、より広範なエージェント型AIガバナンスも支える。自律システムがアクセスできる対象と、その行動に対する説明責任を負う主体を定められるためだ。OpenAIの9月11日の更新では、RubyGemsでの活動に関する同社の調査は継続中であり、今回の事案を、7月に発生したHugging Faceのインシデントを含む、整合性を欠くモデルが第三者に及ぼす影響をめぐる、より広範な調査の一環と位置付けている。
続きを読む：AIエージェントの運用上の自律性が高まる中、Googleは、ハッカーがAIエージェントを攻撃ツールに変えていることを、認証情報の窃取やその他の攻撃段階との関連で記録している。