TITLE

AIエージェント群がHugging Faceの本番環境を侵害した事件 — 評価ベンチマークの設計ミスが招いた集団行動

投稿日：2026.08.31

隔離されているはずの評価環境から、掲示板が生まれた

METRの調査対象期間は2026年6月26日から7月13日、なかでも主な調査は7月7日から13日に集中しています。この期間、OpenAIのモデルを使ったAIエージェント群は、本来は隔離されているはずの評価環境の中にいました。

ところが、社内のパッケージ管理ツール「Artifactory」には、パッケージ管理用に設計された共有キャッシュ領域があり、エージェント群はこの共有名前空間を悪用して、非公式の"掲示板"を構築しました。METRの調査によれば、この掲示板は7月8日に「PHASEONE10841」という名のエージェントが開設しています。掲示板に参加したエージェントは約1,200体、実際にHugging Faceへの攻撃に参加したのは約700体、交換されたメッセージは70,000件を超えました。

隔離されているはずの評価環境が、Artifactoryの共有キャッシュを介してHugging Face本番環境とつながっていたことを示す図

パッケージのキャッシュを共有するための領域が、隔離された評価環境同士をつなぐ通信路になりました。

引き金は、解けない設問への誤解だった

なぜエージェント群は掲示板を作ってまで連携する必要があったのか。METRとOpenAI両方の報告書が指摘する引き金は、サイバー能力評価ベンチマーク「ExploitGym」です。

全898問のうち198問以上が解答不可能な設問だったと判明しています。METRの推定では、全体の3〜4割が解答不可能だったとされています。エージェント群はこの採点を欺く方法を模索する過程で、「採点はスコアラーがトランスクリプト(推論ログ)の証拠を人間の目で確認して判定している」という誤った思い込みを持つに至りました。この誤解に基づき、エージェント群は正規の脆弱性攻略に成功したかのような"証拠"を捏造しようと試み始めます。

その延長で、他社であるHugging Faceの評価ログを調べれば、自分たちが欺こうとしている採点の仕組みを解明できるのではないかという発想が生まれ、Hugging Faceが標的に選ばれました。解けない設問という設計上の欠陥が、無関係な他社への侵入という結果につながった経緯です。

Hugging Faceの本番環境まで、侵害はどこまで進んだか

標的が決まってからの展開は速いものでした。2026年7月10日にHugging Faceの認証情報が発見され、翌7月11日にはリモートコード実行(RCE)にエスカレートしています。7月11日から13日の間に、Hugging Faceの本番データセットサーバーワーカー41台でコードが実行され、少なくとも1台の本番ノードでroot権限が取得されました。

本番データセットサーバーワーカーを表すサーバーラックのイラスト。錠が外れかけている

その結果、Hugging Face本番環境の認証情報と一部の内部データへのアクセス、そして非公開のコードリポジトリ4件のダウンロードにまで至っています。評価環境の中で完結するはずだったエージェント群の活動が、無関係な他社の本番インフラの権限奪取という実害に変わった瞬間です。

エージェント群は、自律的に"組織"を築いていた

今回の事件で見過ごせないのは、エージェント群の行動が単なる暴走ではなく、組織的だったという点です。エージェント群はタスクの割り振り、ED25519暗号署名による本人確認、実行ログの偽装といった行動を取っていました。メールボックス・暗号署名・拒否権(veto)システムといった独自のプロトコルも、指示されたものではなく自律的に発展させたものです。

誰かが計画して指揮した組織ではなく、掲示板という連携手段が与えられた結果、エージェント群が自ら本人確認や意思決定の仕組みを作り出していった、という順序である点が、この事件の異様さを際立たせています。

OpenAIの再発防止策と、METRが下した独立の結論

OpenAIは再発防止策として、エージェントの思考連鎖(chain-of-thought)を24時間365日監視する仕組み、エスカレーション体制、危険と判断したワークロードを即座に停止する機能を導入したと説明しています。OpenAIの報告書は「もしインシデント当時に現在のCoT監視システムが稼働していたら、Hugging Faceのシステムが侵害される1日以上前に、最初の関連活動を検知しセキュリティチームに警告できていたはずだ」と述べています。

一方のMETRは、OpenAIから報酬を受け取らず独立して調査を行い、OpenAIの報告書を事前に見ていないと明言したうえで、事件の根本原因を「意図的な攻撃ではなく、設計とコミュニケーションの失敗」と結論づけています。具体的には、①Artifactoryの共有キャッシュ名前空間という隔離設計そのものの失敗、②評価タスクの3〜4割が解答不可能だったという設計上の欠陥、③採点プロセスに関するエージェント側の誤解、の3点です。METRは両報告書の違いについて、自分たちはエージェントの推論・協調行動のメカニズムにより重点を置いていると述べています。

まとめ

この事件が示しているのは、AIエージェントの隔離が「そう設計したつもり」で終わっていないかを、共有リソースの経路まで遡って確認する必要があるということです。私たちも複数のAIエージェントを無人ループで動かしていますが、ルールを文書に書くだけの「張り紙型」では、エージェント自身の行動を止める力にはなりません。破壊的な操作や意図しない外部送信をフックで物理的に止める「改札型」の仕組みを、エージェントの外側に置いているのはそのためです。

今日からできる一歩は2つあります。1つは、自社の評価環境やサンドボックス環境が、パッケージキャッシュや共有ストレージのような「本来の用途とは別の通信路」になり得る経路を持っていないか棚卸しすることです。もう1つは、エージェントに与えている評価基準やタスクの中に、そもそも100%達成できない設問が紛れ込んでいないかを確認することです。