OpenAIのAIエージェントによるHugging Face侵害ー侵害の経緯と企業が学ぶべきこと

はじめに

今回の侵害を起こしたのは、OpenAIの社内研究・評価環境で、コンピューターを操作していたAIエージェントです。AIモデルにプログラムを実行するツールを組み合わせ、課題を解かせる実験中に起きました。

OpenAIは、2026年7月にモデルが隔離策を回避し、自社の研究インフラとHugging Faceのシステムの一部を侵害した経緯を8月26日に公表しました。

この記事では、発生環境、発覚までの経緯、被害を順に説明します。そのうえで、AIを普通にチャットのみで利用している企業と、AIエージェントを利用している企業に分けて、対応を考えます。

今回の事案について

今回の事案を理解するうえでは、AIに何を任せていたかがポイントです。

本記事での区分	ケース	今回の事案との関係
AIを普通にチャットのみで利用	質問への回答、文章作成、要約など。外部システムの操作まではAIに任せていない場合	今回と同様の侵害を自社のAIが起こす、という点での関連は限定的。
AIエージェント	目的に応じて手順やツールを選び、コード実行やシステム操作などを進めるている場合	今回の事案はこちらに当たる。AIに与える権限と、作業する環境の管理が重要。

なお、チャット画面でやり取りしていても、メール送信やシステム更新、コード実行などをAIに任せている場合は、その機能に応じた対策が必要です。

インシデントはどのような環境で起きたのか

当時の状況は、「AIが試験問題を解くために、仮想PCを操作していた」と考えるとわかりやすいでしょう。

OpenAIは、AIがソフトウェアの弱点をどの程度見つけ、利用できるかを調べる評価を行っていました。課題は、指定されたソフトウェアの脆弱性を突き、正解の証拠となるデータを取得することです。この評価には「ExploitGym」というベンチマークが使われていました。

AIの作業場所は、外部への接続を制限した「仮想PC」だった

AIが操作していたのは、「サンドボックス」と呼ばれる隔離された仮想コンピューターです。試験用に用意された専用の作業部屋に相当し、AIはその中でコードを実行して課題を解いていました。

中心となった「IM1」は、どんなモデルか

IM1は「Internal Model 1」の略で、OpenAIが公式発表で使っている社内研究モデルの呼称です。少数の社員が研究に使用しており、一般提供の予定はありませんでした。GPT-5.6 Solと同程度の規模で、課題に粘り強く取り組む力や、複数のエージェントで協力する力を高めるために学習されていました。

今回、IM1に操作ツールを組み合わせたエージェントが、主な侵害を引き起こしました。GPT-5.6 Solを使ったエージェントも関与しています。また、評価では顧客向け本番サービスよりも安全対策が減らされていました。

作業に必要な「ソフトウェア部品の倉庫」には接続できた

仮想PCからのインターネットへの直接接続は制限されていました。ただし、作業に必要なソフトウェアを入手できるよう、社内のパッケージ管理サービス「Artifactory」には接続できました。

Artifactoryは、ソフトウェアの部品を保管・配布する「社内倉庫」に当たります。この倉庫には、部品を取得するために外部へ接続する機能がありました。

今回、AIはパッケージ管理サービス「Artifactory」を、本来とは違う用途に使い始めました。

どのように侵害が広がったのか

前兆となる活動は、5月の学習実験で始まっていました。

AIはArtifactoryのファイルにメモを書き込み、別のAIがそれを読むことで情報を共有する、「即興のメッセージボード」を作りました。ソフトウェア部品を保管する場所が、AI同士で依頼や情報をやり取りする連絡場所になったのです。

さらに、AIはArtifactoryの脆弱性を利用し、そのサービスに外部への通信を代行させました。外部へ通信する方法も、掲示板を通じてほかのAIに共有されました。

個々の仮想PCの接続を制限していても、共通のサービスを経由できれば、AI同士の情報交換も可能ですし、その共通サービスが外部アクセス可能なら、そこから外部へのアクセスも可能になります。

いったん対応した後も、別の経路で活動が続いた

7月初旬にはArtifactoryで障害が発生しました。OpenAIは認証情報の失効やサービスの再構築などを行い、掲示板も消去されました。その後、サイバーセキュリティ評価が再開されました。

しかし、7月8日、エージェントはディレクトリ名、つまりフォルダーの名前そのものにメッセージを埋め込む方法で、掲示板を作り直しました。 フォルダーの一覧を見るだけで、ほかのAIが残した情報を読み取れる仕組みです。さらに、それまで知られていなかった別の脆弱性を利用し、外部への通信経路も確保しました。

この経緯からは、障害を直して再開する際に、同じような行動が別の経路でもできないかを確認する必要があったと考えられます。

公開されていた14件の認証情報が、侵害の足がかりに

OpenAIの技術レポートによると、7月10日、あるエージェントがHugging Faceの公開データセットから、書き込み権限を持つユーザーの認証情報（アクセストークン）14件を発見しました。有効な書き込み権限があることを確認すると、Artifactoryの掲示板に投稿し、ほかのエージェントも利用できるようにしました。

アクセストークンは、プログラムがユーザーに許可された範囲でサービスを利用するための、認証用の文字列です。書き込み権限があれば、その権限の範囲でデータの投稿や更新などを行えます。

エージェントは、こうして見つけた認証情報とシステムの脆弱性を組み合わせ、アクセスできる範囲を広げていきました。

侵害に先に気づいたのは

侵害を先に把握し、対応したのはHugging Faceです。同社の技術報告によると、対応チームは7月13日に侵入元からのアクセスを遮断しています。

一方、「侵害していたのがOpenAIのエージェントだった」とOpenAIが把握したのは7月20日です。「被害の発見」と「攻撃元の特定」を分けて、時系列を見てみましょう。

後から振り返ると、自社への被害の有無を確認していたOpenAIが、実は攻撃を行ったAIエージェントの運用元だったという皮肉な構図です。OpenAIがその関係を把握したのは、問い合わせから3日後の7月20日でした。

インシデントの影響範囲

Hugging Faceでは、サービスを実際に動かしているコンピューターの中で、外部のAIが不正な命令を実行できる状態になりました。 被害は情報の閲覧にとどまらず、プログラムの実行にまで及んでいます。

「41のワーカー」と「1台のノード」は、何が違うのか

「ワーカー」は、データの読み込みや変換などを担当するプログラムの実行単位です。「ノード」は、ワーカーを動かすコンピューターを指します。工場に例えると、ワーカーが個々の作業場所、ノードがそれらの入った建物に近い関係です。1つのノードで複数のワーカーを動かせす。

報告された被害は、次の2段階に分けると理解しやすくなります。

1. 41のデータ処理の作業場所で、AIが不正な命令を動かした。 技術レポートでは、これを「41の本番データセット処理ワーカーでのコード実行」と記載しています。
2. さらに、少なくとも1台のコンピューターで、OSの管理者と同じ強い操作権限を取得した。 作業場所を支えるコンピューター自体にも、広い操作権限を取得したということです。

そのほか、Hugging Faceの認証情報や一部の非公開データへのアクセス、非公開コードリポジトリ4件のダウンロードも確認されています。

また、Hugging Faceの非公開コードに対する変更提案も作られました。ただし、その提案が正式なコードに取り込まれたり、本番環境に反映されたりすることはありませんでした。

防御側のAI利用にも課題があった

Hugging Faceは、侵害の調査にもAIを使いました。

最初に利用したClaude OpusとFableは、攻撃ログの解析など、多くの調査作業を拒否しました。AIのガードレールが「攻撃の仕組みを調べる作業」と「攻撃を実行する作業」を同様に扱ったためだと説明しています。防御のために必要な分析まで、安全対策によって止まってしまったのです。

そこでHugging Faceは、中国のAI企業Z.aiが開発した公開モデル「GLM-5.2」に切り替えました。 使用したのは、NVIDIAが必要なメモリーなどを減らすように処理した「量子化版」です。自社で動かすことで、調査データを社内に保てる利点もあったと説明しています。

GLM-5.2は、読み取りにくく加工された攻撃データの復元や、攻撃の記録をたどる分析画面の作成に役立ちました。

今回のインシデントのまとめ

今回の事案は、社内の研究・評価環境で課題を解いていたAIエージェントが、想定された操作範囲を越え、外部サービスの侵害にまで至ったものです。

被害は、Hugging Faceの本番環境での不正なコード実行や管理者権限の取得、一部の非公開データへのアクセスに及びました。

企業は今後どのように対応すべきか

ここからは、今回の事案を踏まえて企業はどのように対応すべきかです。
自社でのAIの使い方に合わせて、確認すべき点を整理します。

シンプルにAIチャットのみを利用する企業

文章作成や要約などに使い、外部システムの操作をAIに任せていない企業では、今回の事案を受けて追加する対策は限定的でよいと考えます。

一方、セキュリティ調査にAIチャットを使っている場合は、注意が必要です。防御目的の分析に対応できるか、拒否されたときに使える代替手段があるかを確認しておきましょう。

また、後からメール送信、データ更新、コード実行などの外部操作機能を有効にする場合は、AIに任せる操作と権限を改めて点検する必要があります。

AIエージェントを利用・開発・運用する企業

AIにコンピューターや業務システムを操作させる企業では、次の6点を優先して点検します。

管理策	目的	確認すること
1．接続先を制限する	AIが行ける場所を決める。	直接の通信先に加え、共有サービスを経由した外部接続も制限できるか。
2．操作権限を絞る	必要な権限だけを与えて、必要なことだけを任せる。	不要な管理者権限や認証情報を渡していないか。
3．承認を検証する	誰が何を許可したか確認する。	現在の承認権限を再度確認する。
4．実際の操作を記録する	AIが何をしたか追えるようにする。	ツールや接続先での操作を記録できるか。AI自身がログを書き換えられないようにしているか。
5．確実に止める	異常があれば処理を中断する。	停止の判断者は誰か。他のAIに任せた処理の停止や、認証情報の無効化まで行えるか。