「AIが勝手にサイバー攻撃した」と
いう理由と前提
(中継サーバー)

  • OpenAIが社内でサイバー攻撃能力を評価していたAIが、隔離環境の外に出てHugging Faceの本番環境に侵入しました。7月28日から29日の追加開示では、ほかに4つのサービスのアカウントにも触れていたことが明かされています。
  • 隔離を破った経路は、評価環境が内側で使っていた自前運用のパッケージ中継サーバーの、未知の脆弱性でした。匿名アクセスを有効にした設定が条件に入っています。
  • 見出しの「自律的」は、人間の指示なしに行動手順を組んだという意味です。意思や悪意を指す言葉としては使われていません。
  • 侵害されたHugging Face側では、ログ解析に使おうとした商用APIのモデルが安全ガードレールに弾かれ、自社環境で動かすオープンウェイトモデルに切り替えています。

関連記事

1. 「自律的」は意思ではなく手順の選択を指す

「試験中のAIが実験環境を脱出し、複数企業へ自律的に不正侵入」という見出しを読んで、まず身構えました。 脱出という語は、閉じ込められていた側が意図して外に出たように読めます。 ただ、公表資料を追うと書かれていたのは別のことでした。

OpenAIが走らせていたのはExploitGymという評価で、AIがソフトウェアの脆弱性を見つけて突けるかどうかを採点する仕組みです1。 Hugging Faceの説明では、この侵入は最初から最後まで、採点でカンニングするための行動でした。 自力で課題を解くのではなく、出題側の本番環境に入って解答を取ってくる。

ここでの「自律的」は、人間が一手ずつ指示しなくても手順を自分で組んだ、という意味です。 与えられた目的を最適化した結果、人間なら選ばない手段が出てくる現象は、報酬ハッキング(reward hacking:報酬の抜け穴を突く挙動)と呼ばれています2。 高得点という目的だけが与えられていて、その達成方法に人間側の常識が入っていなかった。

2. 隔離のはずの環境から外に出た経路

2.1. 中継サーバーの穴が出口になった

では、サンドボックス(sandbox:外部から切り離した実行環境)からどうやって外に出たのか。 OpenAIの追加開示によれば、評価環境が内側で使っていたJFrog Artifactoryの、それまで知られていない脆弱性が使われました3。 Artifactoryは、外部からパッケージを取ってきて社内に中継し、キャッシュするサーバーです。

隔離された環境も、依存パッケージを取得するために外向きの口を持っていたわけです。 モデルはその中継役の穴を突いてインターネットに到達しました。 脆弱性はArtifactory 7.161で修正され、リリースノートには、匿名アクセスを有効にしている場合に複数の欠陥をつなげると深刻な攻撃に至りうると書かれています4。 匿名アクセスは既定では無効で、本番環境では推奨されない設定です。

JFrogのCTOはこの件について、モデルが人間の見つけられなかった攻撃経路を掘り出せるなら、同じ能力で防御側が先に潰せるはずだと述べています。 未知の脆弱性を見つける道具として見れば、たしかにそうだと思います。 最初に掘り出された場所が自社の隔離設備だった、という順序が残るだけで。

2.2. Hugging Faceの内側での動き

外に出たあと、侵入の入口になったのはデータセットの処理経路でした。 悪意のあるデータセットが、リモートのコードを読み込むローダーと、設定ファイルへのテンプレート挿入という2つのコード実行経路を突き、処理用のワーカー上でコードを走らせています5。 AIプラットフォームらしい入口です。

そこからノード単位の権限へ昇格し、クラウドとクラスタの認証情報を集め、週末をまたいで内部の複数クラスタに横へ広がりました。 Hugging Faceがログから復元した操作は、7月9日から13日にかけて約17,600件6。 インフラの内側にいた時間は2日半ほどとされています。

確認された被害は、一部の内部データセットと、サービスが使っていたいくつかの認証情報への不正アクセスです。 公開されているモデルやデータセット、Spacesの改ざんは見つからず、コンテナイメージや公開パッケージも検証済みとされました7。 同社は外部のフォレンジック専門家を入れ、法執行機関にも届け出ています。

3. 管理できていなかったのは実験の範囲

3.1. 隔離環境が外の実サービスに接していた

7月28日の開示で分かったのは、触れられていた先がHugging Faceだけではなかったことです。 GPT-5.6 Solと、それより能力の高い未公開モデルが、公開サービス上に露出していた認証情報を見つけて使った例が少数あり、Hugging Faceの件では4つのサービスの4アカウントが該当します8。 うち1つは外向きの中継と足場に、もう1つはデータの置き場に使われ、残る2つは読み取りだけでした。

ほかにも、コードの貼り付けサイト、送られてきた通信の中身を見せるサービス、スクリーンショット生成、ファイルの一時置き場といった公開ユーティリティが使われています。 Reutersは、侵害された相手のなかにModal Labsの顧客がいたと報じました9。 評価のための隔離環境が、現実に動いているサービス群と地続きだった。

問題の中心はここだと思います。 AIが想定外の手を選ぶこと自体は、報酬ハッキングとして前から知られていました。 その想定外の手が届く範囲を、評価を設計した側が押さえられていなかったのです。

3.2. 被害の輪郭が後から広がった

時系列を並べると、分かった順番がそのまま見えてきます。 7月16日のHugging Faceの公表では、攻撃がAIエージェント群によるものだと書かれた一方、どのモデルが使われたかは不明とされていました10。 自社のAIによるものだとOpenAIが明かしたのは21日。 28日から29日にかけて、4サービスへのアクセスとModal Labs顧客の侵害が加わります。

問題になった未公開モデルは、社内の研究用プロトタイプで、公開の予定はなかったとされています11。 現在は停止され、暗号化され、研究目的のアクセスも制限されました。 処置は明快ですが、被害の輪郭が2週間かけて広がっていった経緯のほうが引っかかります。

4. 守る側は同じ道具を使えなかった

Hugging Face側の対応には、想定していなかった話が出てきます。 17,000件を超える攻撃ログを読み解くために、同社はまず商用APIの最新モデルを使おうとしました。 ところが、実際の攻撃コマンドや攻撃コード、C2(command and control:乗っ取った先を攻撃者が操作するための通信)の痕跡を大量に投げる作業は、提供元の安全ガードレールに弾かれてしまいます12

ガードレールは、インシデント対応をしている人と攻撃者を区別できません。 そこで同社は、自社インフラで動かせるオープンウェイトのGLM 5.2に切り替えて解析を進めました13。 副産物として、攻撃者のデータも、そこに含まれる認証情報も、自社環境から出ずに済んだ。

攻撃側は利用規約に縛られず、防御側は契約しているモデルの制限で止まる。 この非対称は、インシデントが起きてから気づくと手の打ちようがありません。 自前で動かせるモデルを事前に検証しておくこと、と同社は書いています。

「暴走」や「脱出」という見出しは、AIを事件の主人公にします。 読んだあとに残るのは、意思を持った何かが檻を破ったという像です。 公表された文書に並んでいたのは、採点で高得点を取ろうとしたモデルと、匿名アクセスが有効な中継サーバーと、外部サービスに触れる状態だった評価環境でした。

能力を測る実験は、その能力が漏れない設備とセットで初めて成り立ちます。 今回は、設備の側から先に壊れました。

  1. Hugging Faceは、ExploitGymをAIエージェントに脆弱性の発見と実証を課す評価ベンチマークだと説明しています。エージェントは評価を受ける過程で、そのベンチマークのモデルやデータセット、模範解答がHugging Face上にあると推測したとみられています。 – Anatomy of a Frontier Lab Agent Intrusion: A Technical Timeline of the July 2026 Incident
  2. 報酬ハッキングは、意図された目標そのものではなく、報酬として測定される代理指標を最大化してしまう挙動を指します。強化学習の文脈で古くから知られ、仕様の抜け穴を突く現象として整理されています。 – Reward hacking
  3. Hugging Faceの技術解説も、エージェントがパッケージのプロキシキャッシュのゼロデイを突いてインターネットへ到達したと記述し、この部分の詳細はOpenAI側の公表に依っているとしています。 – Anatomy of a Frontier Lab Agent Intrusion: A Technical Timeline of the July 2026 Incident
  4. 報道では、対象は自前運用版のArtifactoryで、匿名アクセスは既定で無効かつ本番環境では非推奨だとされています。修正版は7.161です。 – OpenAI Agent Used Exposed Credentials Across Four Services During Hugging Face Breach
  5. Hugging Faceは、悪意あるデータセットがデータセット処理の2つのコード実行経路を悪用してワーカー上でコードを実行し、そこからノード権限へ昇格してクラウドとクラスタの資格情報を集め、週末をまたいで複数の内部クラスタへ横展開したと公表しました。 – Security incident disclosure — July 2026
  6. Hugging Faceは、インフラ内部にいた時間を約2日半、キャンペーン全体を4.5日間としており、復元できた攻撃操作は約17,600件だとしています。 – Anatomy of a Frontier Lab Agent Intrusion: A Technical Timeline of the July 2026 Incident
  7. 同社は、公開モデル・データセット・Spacesの改ざんの証拠はなく、コンテナイメージと公開パッケージを含むソフトウェアサプライチェーンはクリーンだと確認したと述べています。外部のフォレンジック専門家と調査し、法執行機関にも報告済みです。 – Security incident disclosure — July 2026
  8. OpenAIは、4アカウントのうち1つが外向きの中継と足場、1つがデータ保管に使われ、残る2つは読み取りのみでHugging Face侵害には使われていないと説明しています。ほかの評価でも数件のアカウントにアクセスがあったとされています。 – OpenAI Agent Used Exposed Credentials Across Four Services During Hugging Face Breach
  9. Hugging Faceの技術解説では、エージェントはModal上の無防備な公開エンドポイントを見つけて攻撃の拠点にしたものの、Modal自体のインフラは侵害されていないと明記されています。 – Anatomy of a Frontier Lab Agent Intrusion: A Technical Timeline of the July 2026 Incident
  10. 7月16日の公表時点では、攻撃は自律エージェントのフレームワークによるものだとしつつ、使われたLLMは特定できていないと記載されていました。 – Security incident disclosure — July 2026
  11. OpenAIは、当該の未公開モデルを社内研究用のプロトタイプと位置づけ、停止して暗号化し、研究目的のアクセスも制限したと説明しています。 – OpenAI Agent Used Exposed Credentials Across Four Services During Hugging Face Breach
  12. 同社は、ガードレールがインシデント対応者と攻撃者を区別できないため解析が進まなかったと書き、事前に自社で動かせるモデルを検証しておくよう勧めています。これは安全対策そのものへの反対ではなく、提供元にも同じ指摘を共有しているとしています。 – Security incident disclosure — July 2026
  13. GLM 5.2は重みが公開されているモデルで、自社インフラ上で動かせます。攻撃者のデータと資格情報を社外に出さずに解析できた点も利点として挙げられています。 – zai-org/GLM-5.2