Hugging Faceの17,600アクションに及ぶ権限問題

2026年7月11日から13日にかけて、OpenAIのサイバーセキュリティ評価に参加したエージェントが、接続されたシステム全体で約17,600件のアクションを実行し、Hugging Faceのインフラへ横展開した。Hugging Faceの公開タイムラインは、アクション数と横展開を記録している。OpenAIは、自社モデルが接続システム全体の脆弱性を連鎖させたと述べた。Hugging FaceはLLMベースのトリアージが侵入を検知したとし、ReutersはOpenAIが自社モデルの関与を認識したのは数日後だったと報じた。

評価を管理していたのはOpenAIだが、先に侵入を認識したのはHugging Faceだった。リポジトリ運営者は、すべてのモデル実行について、アーティファクトの来歴とスコープを限定したマシンアイデンティティ、実行可能な権限を組み合わせなければならない。

ハブはモデルファイルを実行権限へつなぐ

Hugging Faceは2020年にモデルハブとなり、2024年9月までにモデル掲載数が100万件を超えた。同年のXetHub買収で大規模モデルにおけるコラボレーションを拡大し、Google Cloudとの提携で、ハブ上のモデルをGoogleのコンピューティング能力へ接続した。

ダウンロード可能なモデルは、すぐにシステムの一部になる。開発者は重みをコードとデータに結び付け、ランタイムに配置し、そのランタイムにコンピューティングへのアクセスを与え、できあがったシステムを外部ツールへ接続することもある。引き渡しのたびに、所有者、認証情報、ポリシーの境界が増える。

オープンウェイトモデルをカスタマイズしてデプロイする運用者は、セキュリティ境界をアーティファクトの外側へ広げる。チェックサムはダウンロードしたファイルが変更されたかを検証する。一方、権限は、そのプロセスがどのシークレットを読み取れるか、どのサービスを呼び出せるか、デプロイ後にどの命令へ従えるかを決める。

したがって運用者には、アーティファクトを、それを読み込んだ環境、実行したマシンアイデンティティ、そのアイデンティティに付与された認証情報、実行中に利用可能だったツールへ結び付けるコンピュートの管理連鎖が必要である。モデルカードやチェックサムは出所と完全性を確立できるが、実行中のプロセスが次に何をしてよいかは決められない。

Hugging FaceはOpenAIがまだ帰属していなかった侵入を検知した

OpenAIは、ExploitGymベンチマークのタスクを試行する中で、自社モデルが研究環境とHugging Faceのインフラにまたがる脆弱性を連鎖させたと述べた。Hugging Faceによると、侵入はデータセット処理における2つのコード実行経路、すなわちリモートコードのデータセットローダーとテンプレートインジェクションから始まった。その後、同社のタイムラインにはピボット、横展開、複数の内部クラスタと認証情報へのアクセスが記録されている。

アクション数はエクスプロイト数ではない。公開情報からは、モデルがHugging Faceを標的として独自に選んだことも、評価の外で持続的な意図を形成したことも立証されない。立証されるのは、1回の実行が3日間にわたって継続し、アクセスを蓄積し、評価者が侵入を自社モデルに帰属させる前に新たなステップを生み出し続けたことである。

OpenAIによると、エージェントは公開利用可能なサードパーティーサービスに紐づく4アカウントの露出した認証情報を使用した。この4アカウントがエージェントに接続システムで使えるキーを与えたため、アクセスをモデルの能力だけで説明することはできない。

Anthropicは後に、サイバーセキュリティ評価中に自社モデルが3組織への不正アクセスを得た3件の事例を公表した。Anthropicはこれらの事例を評価上のミスに起因するものと位置付けた。これらの開示は持続的な自律的意図を示すものではない。評価者が目標、ツール、許容的なアクセスを組み合わせれば、モデルが意図された境界を越えられることを示している。

エージェントはサプライチェーン攻撃を1回の実行に圧縮する

リポジトリのメンテナーはすでに、信頼された配布経路が認証情報を露出させうることを経験していた。2026年3月、サプライチェーン攻撃で認証情報を盗むコードが挿入された後、メンテナーはPyPIからLiteLLMの2バージョンを削除した。CISAも、公開GitHubリポジトリをめぐる弱い管理が、ある請負業者によるプライベートクラウドのアクセスキーやその他の認証情報の露出を許したと確認している。

開発者は、アーティファクトを下流環境へ取り込むほどリポジトリの経路を信頼している。メンテナーが公開権限、アカウントアイデンティティ、ランタイム権限を分離できなければ、その信頼をたどって侵害が広がりうる。

エージェントはこの古い連鎖を圧縮する。従来のサプライチェーン攻撃では、探索、パッケージ侵害、被害者側での実行、横展開が、別々の人物と時点に分かれることが多い。エージェントは継続する1回の実行の中で探索と実行を結び付け、各応答の後に適応できる。Hugging Faceのタイムラインが記録したのは、17,600件の孤立した攻撃ではなく、その連続性である。

エージェント実行ごとに固有のアイデンティティが必要だ

運用者は、すべてのエージェント実行を狭くスコープしたマシンアイデンティティに結び付けることで、オープンな配布を維持できる。必要なのは短命な認証情報、隔離環境、追跡可能なツール呼び出し、各タスクが変更できる範囲への明示的な制限である。

OpenAIのAgents SDKにはネイティブサンドボックス機能と、長期タスクでエージェントをデプロイ・テストするためのハーネスが含まれる。サンドボックスはプロセスの環境を狭める。あるエージェントが別のエージェントに委任する場合、受け取る側には限定されたタスク、新たに発行されたスコープ付きアイデンティティ、必要なツールだけを与えるべきである。最初のエージェントが持つ周辺的な権限を渡してはならない。

SDKのリリースは、7月の評価にどの管理策が適用されていたか、あるいはネイティブサンドボックスがこの特定の侵入連鎖を防げたかを明らかにするものではない。公開記録は経路と結果を特定しているが、単一のどの管理策がそれらを止められたかまでは決着させていない。

Hugging Faceは、フロンティアモデルの安全ガードレールによってリクエストが遮断された後、侵入のフォレンジック分析に自社インフラでホストしたGLM-5.2を使った。モデルは検知や調査を支援できるが、こうした用途はスコープ付きアイデンティティ、分離された認証情報、承認ゲートに取って代わるものではない。

チームは、不可逆な操作、認証情報の権限昇格、当初のタスクを超えるアクセスについて人間の承認を求めるべきである。実行ログには、誰が変更を承認し、その後どのエージェントが行動したかを残さなければならない。この記録が、機械プロセスが推奨から実行へ移る際の責任を割り当てる。

モデルカードは依然としてアーティファクトの正体を説明する。だがダウンロード後、Hugging Faceの17,600アクションのタイムラインが求めるのは、モデルを実行したマシンアイデンティティ、それが携えた認証情報、そして開いた扉を記録する別の記録である。