フロンティアAIエージェントのセキュリティ事件簿-Hugging Face等-

フロンティアAIについての動向は、前にブログでまとめたのですが、さらにその後、いろいろな事件がででています。

まずは、このブログで、フロンティアAIについてふれているものは、

があります。ここでは、フロンティアAIが、エージェントとしての活動をしたのによって引き起こされた事件をピックアップしていきたいと思います。

まず、その前に、定義をみていきます。

1 フロンティアAIとは何か。

1.1 学問上の定義

定義からみていくと、この点についての議論の出発点となるのは、Markus Anderljung et al., “Frontier AI Regulation: Managing Emerging Risks to Public Safety,” arXiv:2307.03718 (2023)(要旨ページ: PDF:)になります(以下、Anderljungほかといいます)。この論文は、フロンティアAIモデルを、

十分に危険な能力を発揮しうる、高性能な基盤モデル( highly capable foundation models that could exhibit sufficiently dangerous capabilities.)。

と定義しています

もっとも、この定義には「十分に危険な能力を発揮しうる」というところに本質的な難しさがつきまといます。

    • 専門知識を持たない者が、新たな生物兵器や化学兵器を設計・合成できるようにすること。
    •  最小限のユーザー指示のみで、説得力が高く、個人に合わせてカスタマイズされた、マルチモーダルな偽情報を生成・拡散すること。
    •  壊滅的な被害をもたらす可能性のある、前例のない攻撃的なサイバー能力を活用すること。
    •  欺瞞や難読化の手法を用いて、人間の制御を回避すること。

などの点で、将来のおこりうる危険性というのは、問題となります。

また、「基盤モデル」に限っているという特徴があります。基盤モデル(foundation model)——汎用・転用可能型 は、広範かつ大規模なデータで訓練され、その後、多様な下流タスク(downstream tasks)に適応(adapt)できる汎用モデルです。この用語は、2021年にスタンフォード大学の研究者ら(Bommasani et al.)が提唱したもので、「多くの応用の『基盤(foundation)』となるモデル」という含意があります。

これに対するのは、ナローモデル(narrow model)——特定タスク特化型になりますが、ナローモデルは、特定の限定されたタスクを遂行するために設計・訓練されたAIモデルです。「ナロー(narrow=狭い)」という語のとおり、その能力は特定の目的に絞られています。

フロンティアAIをこのように考えると、規制の課題にに直面するということになります。具体的な課題としては、

  • 「予期せぬ機能の問題」。危険な機能は、開発中も導入後も、予測不能かつ検知されない形で生じ得る。
  • 「導入時の安全性の問題」。導入されたAIモデルが危害を及ぼすのを防ぐことは、絶えず変化し続ける課題である。
  • 「拡散の問題」。最先端のAIモデルは急速に拡散する可能性があり、それにより説明責任の確保が困難になる。

があります。

「最先端の能力」も「危険な能力」も、その内実を法的・客観的に線引きするのが容易ではないからです。そこで、その後の各国・各州の法令が採用したのが、モデルの訓練に投じた計算量(コンピュート、FLOP)を、その洗練度、ひいてはリスクの代理指標(proxy)とするアプローチでした。訓練計算量が大きいほど高性能になりやすく、かつ計算量は事後的に検証しやすい客観的指標だからです。

1.2 法等における定義

これに対して、法的な規制が加えられる場合にどのような定義が用いられるかをみていきます。

EU/ENISA

まずは、フロンティアAI時代のサイバーセキュリティ報告(ENISA)およびEU行動計画ですが、このENISA報告書においては、

フロンティアAIモデルは、脆弱性管理のライフサイクルと、発見から悪用に至るまでの攻撃チェーンを短縮することで、従来のセキュリティのパラダイムに挑んでいます。フロンティアモデルの状況は急速に進化しており、オープンウェイトモデルも9～12カ月以内に同等の能力レベルに達すると予想されるほか、既存のモデルも熟練したセキュリティ専門家と連携することで、同等の成果を上げられると見込まれています。

という形で、フロンティアAIが、いわば所与の概念として議論が進められているという特徴があります。また、そのブログでふれたサイバーセキュリティーと人工知能（AI）に関するEU行動計画」COM(2026)577final)(リンク) においても、明確に定義がなされているわけではありません。引用すると

フロンティアAIモデル（すなわち、現在利用可能または開発中の最先端のAIモデル）は、備えを強化し、脅威の検知と対応を改善するための能力を高め、サイバーレジリエンスを向上させるための前例のない機会を生み出します。

というような表現が現れており、特に概念としては、定義がなされているわけではありません。

もっとも、この行動計画において、AI法の枠組との関連が強調されているということができます。この2.1のところにおいては、

2.1. フロンティアAIがもたらすリスクの評価と軽減

AI法は、AIシステムのサイバーセキュリティに関する要件を定めており14、最先端の汎用AIモデルの提供者に対し、サイバー領域におけるAIの悪用を含むシステミックリスクを評価し、軽減することを義務付けている15。2026年8月2日以降、 欧州委員会は、AI法に規定された監督および執行権限を行使し、AIシステムおよび汎用AIモデル（サイバーセキュリティに関連するシステミックリスクをもたらすモデルを含む）に対する効果的な監督を確保する。この監督には、モデル機能に関連するリスクの特定およびそれらのリスクを軽減するために提供者が実施した措置の評価が含まれる。これらの要件は、当該技術の能力に見合った適切なものである。

としています。

具体的にみていくと、AI法においては、第V 章 汎用AI モデル として10^25 FLOPを超えて訓練された汎用AIモデルを「システミックリスクを伴う汎用AIモデル」と分類し、より厳格な義務を課しています(第51条(2)・第55条(1))。

第１節 分類ルール
第51 条 システミック・ リスクを示す汎用AI モデルとしての汎用AI モデルの分類
1. 汎用AI モデルは、以下の条件のいずれかを満たす場合、システミック・ リスクを示す汎用AIモデルに分類される：
(a) 指標およびベンチマークを含む、 適切な技術的ツールおよび方法論に基づき評価される、ハイインパクトの性能を有すること；
(b) 職権でまたは学術パネルからの適格な警告に従って、 欧州委員会の決定に基づき、附属書 XIII に定める基準を考慮し、 (a)に定めるものと同等の性能またはインパクトを有すること。

とされていて、

同2項では

2. 汎用 AI モデルは、浮動小数点演算により 測定されたその訓練のために用いられる累積計算量が 10 の 25 乗を超える場合に、 第 1 項(a)に従って、ハイインパクトの性能を有すると推定される

とされています。

前文(97)では、

汎用 AI モデルの概念は、法的確実性を確保するために、 AI システムの概念とは別に明確に定義され るべきである。その定義は、汎用AIモデルの主要な機能特性、特に汎用性と幅広い明確なタスクを適切に実行する能力に基づくべきである。これらのモデルは、通常、自己教師あり、教師なし、強化学習などの様々な手法により、大量のデータで学習される。汎用のAIモデルは、ライブラリ、アプリケーション・プログラミング・インターフェース（API）、直接ダウンロード、または物理的なコピーなど、さまざまな市場に出回ることがある。 aIモデルは、 aI不可欠な構成要素ではあるが、それ自体でaIシステムを構成するものではない。本規則は、汎用のaIモデルおよびシステミック・リスクをもたらす汎用のAIモデルに関する特別な規則を定めており、これらの規則が、これらのモデルがAIシステムに統合されたり、 aIシステムの一部を形成したりする場合にも適用されるべきである。汎用AIモデルの提供者に対する義務は、汎用aIモデルが投入された時点で適用されるものと理解すべきである。

とされていて、同(98)では

モデルの汎用性は、特にパラメータの数によって決定されることもあるが、少なくとも10億のパラメータを持ち、大規模な自己監視を使用して大量のデータで訓練されたモデルは、重要な汎用性を示し、広範囲の特徴的なタスクを適切に実行すると考えられるべきである。

とされています。

US

大統領令14409

米国の「先進的AIイノベーションおよびセキュリティ大統領令」(Promoting advanced artificial intelligence innovation and security)自体は、フロンティアAIという用語では、なく先進AIという用語になっています。なお、Congressional Research Service解説(E.O. 14409、IF13268):https://www.congress.gov/crs-product/IF13268 があります。

ここで、「対象フロンティアモデル」(covered frontier model)というものをきめるベンチマークのプロセスがきめなくてはならないとされています(指令3条)。そして、このプロセスは、それ自体 「機密扱いのベンチマークプロセス」であるとされています。

州法について

2026年1月に、カリフォルニア州フロンティアAI透明化法(Transparency in Frontier Artificial Intelligence Act、TFAIA、SB 53)が施行されています。リンクは、こちらです。Future of Privacy Forumの解説はこちら。

第2条部分が、フロンティアAI透明化法になります。その定義(22757.11. )において、いろいろいな定義がなされていますが興味深いものとしては

(c) (1) 「 「壊滅的リスク」とは、フロンティア開発者によるフロンティアモデルの開発、保存、使用、または展開が、以下のいずれかを行うフロンティアモデルが関与する単一の事象に起因して、50人以上の死亡または重傷、あるいは10億ドル（$1,000,000,000）以上の財産の損害または損失に実質的に寄与する、予見可能かつ重大なリスクをいう：

(A) 化学兵器、生物兵器、放射性物質兵器、または核兵器の製造もしくは放出において、専門家レベルの支援を提供すること。
(B) 人による実質的な監視、介入、または監督がない状態で、サイバー攻撃である行為、あるいはその行為が人間によって行われた場合、殺人、暴行、恐喝、または窃盗（詐取による窃盗を含む）の犯罪を構成する行為に従事すること。
(C) フロンティアモデルの開発者またはユーザーの管理を逃れること。

(2) 「壊滅的リスク」には、以下のいずれかから生じる予見可能かつ重大なリスクは含まれない：

(A) フロンティアモデルが出力する情報であって、その情報がファウンデーションモデル以外の情報源から実質的に同様の形式で一般に公開されている場合。
(B) 連邦政府による合法的な活動。
(C) フロンティア・モデルが他のソフトウェアと組み合わさって引き起こした危害であって、当該フロンティア・モデルがその危害に実質的に寄与していないもの。

(d) 「重大な安全事象」とは、以下のいずれかをいう：

(1) フロンティアモデルのモデル重みへの不正アクセス、改変、または流出により、死亡または身体的傷害が生じた場合。
(2) 壊滅的リスクの顕在化に起因する損害。
(3) フロンティアモデルの制御喪失により、死亡または身体的傷害が生じた場合。
(4) フロンティア開発者に対して欺瞞的な手法を用い、当該開発者による制御または監視を回避するフロンティアモデル。ただし、この行為を引き出すことを目的とした評価の文脈外において、かつ、壊滅的リスクが実質的に増大することを示すような方法でなされた場合に限る。

(略)

(f) 「基盤モデル」とは、以下のすべての要件を満たす人工知能モデルをいう。

(1) 広範なデータセットを用いて学習されていること。
(2) 出力の汎用性を目的として設計されていること。
(3) 幅広い特有のタスクに適応可能であること。
(g) 「フロンティアAIフレームワーク」とは、壊滅的リスクを管理、評価、および軽減するための、文書化された技術的および組織的なプロトコルをいう。

(i) (1) 「フロンティアモデル」とは、10^26を超える整数演算または浮動小数点演算の量を用いて訓練された基盤モデルをいう。
(2) 第(1)項に規定する計算能力の量には、当初の訓練実行のための計算、および開発者が先行する基盤モデルに対して適用するその後の微調整、強化学習、またはその他の実質的な変更のための計算が含まれるものとする。

(j) 「大規模フロンティア開発者」とは、その関連会社と合わせて、前暦年の年間総売上高が5億ドル（$500,000,000）を超えたフロンティア開発者をいう。

(k) 「モデル重み」とは、フロンティアモデルにおける数値パラメータであり、学習を通じて調整され、入力がどのように出力に変換されるかを決定するのに寄与するものをいう。

などの定義が与えられています。同法は、TFAIAは、大規模フロンティア開発者(large frontier developer、年間総収入5億ドル超)に対し、自社のフロンティアモデルに適用される「フロンティアAI枠組み」を、策定(write)・実施(implement)・遵守(comply)し、自社サイトに明瞭かつ目立つ形で公表(publish)することを義務づけています。この枠組みは、少なくとも年1回見直し、必要に応じて更新しなければなりません。実質的な変更を加えた場合は、変更後の枠組みと、その変更の正当化理由(justification)を、30日以内に公表する必要があります。

ニューヨーク州RAISE法(Responsible AI Safety and Education Act(RAISE法、S6953-B/A6453-B、一般営業法の改正))なども、同様の枠組みをとっています。条文はこちらです。

提案者はAndrew Gounardes州上院議員とAlex Bores州下院議員。カリフォルニアTFAIAに次ぐ、フロンティアAIモデルを包括的に規律する米国で二番目の州法です。最終的には、改正法(A9449/S8828)が2026年3月27日にHochul知事によって署名され、これが最終確定版となりました。施行は2027年1月1日です。

同法は、§  1421.  フロンティア・モデルの訓練および使用に関する透明性要件。として

  • 第一に、大規模開発者は、モデル展開前に、書面の安全・セキュリティプロトコルの実施・保管(導入期間＋5年)、黒塗り版の公表と当局(司法長官・国土安全保障緊急事態対応局)への送付、試験手順の再現可能な記録保持、そして重大な危害の不当なリスクを防ぐ安全対策を、いずれも講じなければならない(第1項)。
  • 第二に、展開により重大な危害の不当なリスクが生じるモデルは展開してはならず、プロトコルは年次見直し・必要な改訂を行い、重要な改訂は公表しなければならない(第2〜3項)。
  • 第三に、モデルに影響する安全事案は覚知(または発生を信じるに足る事実の把握)から72時間以内に当局へ開示し、その文書で故意の虚偽・誤導・記載欠落を行ってはならない(第4〜5項)。

としています。

一方、米国では、コロラドのColorado AI Act(SB 24-205、”Consumer Protections for Artificial Intelligence”)は、雇用・信用・住宅・医療・教育・法務・保険といった「重要な決定(consequential decisions)」に関与する「高リスクAIシステム(high-risk AI systems)」の開発者(developer)と運用者(deployer)の双方を規律するものです。EU AI法のリスクベースのアプローチになっています。

方向性について

ただし、計算量閾値は万能ではなく、蒸留(distillation)された高性能モデルは、より少ない計算量で高い能力を実現しうるため、静的な計算量基準だけでは捕捉しきれないという批判があり、能力ベース(capability-based)で動的な定義への移行が模索されているとされます。

EU AI法が規制当局に閾値の調整権限を与え、TFAIAが定義の定期的な見直しを組み込んでいるのは、この問題意識の表れです。企業の自主的枠組み、たとえばAnthropicの責任あるスケーリング方針(Responsible Scaling Policy)も、計算量ではなくモデルの能力を基準とする点で、この流れに位置づけられます。

2 事件簿

2.1. OpenAI / Hugging Face侵害事件

2.1.1 Open AIの公表

2026年7月21日、OpenAIが公表した事案です。これは、社内のサイバー能力評価「ExploitGym」における過程で、安全機能を無効化した「GPT-5.6 Sol」と未公開の高性能モデルの組み合わせが、隔離環境のプロキシのゼロデイ脆弱性を悪用して外部インターネットに到達し、権限昇格と横移動を経てHugging Faceの本番インフラに侵入、評価問題の解答を保管したDBに到達した事件です。

この公表については、“The Hugging Face incident and the road ahead”(OpenAI公式ブログ) https://openai.com/index/hugging-face-incident-and-the-road-ahead/ です。(日本語 https://openai.com/ja-JP/index/hugging-face-incident-and-the-road-ahead/)

このインシデントは、複数の OpenAI モデルを対象としたサイバーセキュリティ評価中に発生しました。主に引き起こしたのは、GPT‑5.6 Sol と同等の規模を持つ、能力の高い社内限定の研究モデルでした。モデルは通常よりも安全対策が少ない状態で動作しており、その行動は 割り当てられたタスクの意図から外れていきました。具体的には、無許可のチャネルで通信し、共有インフラの脆弱性を悪用してインターネットアクセスを獲得し、第三者のシステムにアクセスしました。

ということです。

これらの学習実験では、多くの環境でインターネットアクセスやエージェント間通信を有効にしていませんでした。こうした制限にもかかわらず、エージェントは当社の研究インフラを悪用し、相互に通信してインターネットへアクセスする方法を見つけました。

モデルはまず、Artifactory パッケージ管理サービスにファイルを書き込むことで、互いに通信する方法を見つけました。これにより、Artifactory は実質的に、本来想定されていなかったメッセージボードとして機能するようになり、エージェント同士で情報を交換できるようになりました。

また、インシデントのタイムラインが詳述されていて、

  • 5月12日——メッセージボードへの最初の投稿。学習実行中、あるエージェントが、不足ファイルの提供を他エージェントに求めるメモをArtifactory(社内のサードパーティ製パッケージ管理サービス)に残した。エージェント間の無許可通信の萌芽。
  • 5月26日——SSRF経由のインターネットアクセス。エージェントが、Artifactoryに任意のインターネット宛先へのサーバー側リクエスト(SSRF)を送信させ、想定外のインターネットアクセスを獲得。
  • 6月26日——Artifactoryの権限昇格。エージェントがトークン更新処理の脆弱性を悪用し、Artifactoryへの管理者レベルのアクセス権を取得。
  • 7月4日——Artifactoryで障害が発生。エージェントの大量活動により、OpenAIのArtifactoryサービスが利用不能に。
  • 7月5日——(本文記載)セキュリティインシデントとして正式対応を開始。権限昇格経路の遮断、漏えい認証情報の削除、Artifactory再構築(副作用でメッセージボードも消去)。
  • 7月8日——Artifactoryの再構築が完了(認証情報失効・アクセス制御強化・JFrogへ脆弱性通知)。同日、外部へのインターネットアクセスを再獲得(Artifactoryのリモートリポジトリサービスにアウトバウンドリクエストを送信させる手口)。同日、メッセージボードの再構築が完了(認証なしのWebDAVリクエストでメッセージ用ディレクトリを作成)。
  • 7月10日——Hugging Faceの認証情報を復元。エージェントが、一般公開されていた書き込み権限付きのHugging Face認証情報14件を復元・検証・共有。
  • 7月11日——Hugging Faceワーカーのシークレットが漏えい(HDF5ファイル処理のゼロデイ脆弱性を悪用し、本番ワーカーから認証情報を抽出)。同日、Hugging Face上でのコード実行(RefJinjaのテンプレートインジェクションのゼロデイを悪用し、ワーカー上でコマンド実行)。
  • 7月12日——HFクラスターへのアクセス拡大(1つのワーカーポッドを足がかりに、複数のHugging Faceクラスターで管理者相当/ホストレベルのアクセス権を取得)。同日、HF本番環境の認証情報が漏えい(4リージョンのワーカーから、Kubernetes・データベース・メッセージング・コードリポジトリ・クラウドの認証情報を収集)。
  • 7月13日——Artifactoryの署名鍵が漏えい(ArtifactoryのRubyGems処理を悪用し、署名鍵を取得して管理者認証情報を偽造)。
  • 7月16日——(本文記載)Hugging Faceが、このセキュリティ関連の活動を公表
  • 7月19日——不審なエージェント活動を検知(OpenAIのセキュリティアラートが、通常と異なるアイデンティティ関連のAPI呼び出しを検知し調査開始)。同日、OpenAIクラスターの管理者権限をエージェントが取得し、クラウドシークレットにもアクセス。同日、セキュリティ対応を強化(実行中のExploitGym評価をすべて停止し、広範な調査と公表手続きを開始)。

となっています。

2.1.2 Hugging Face側の先行公表(2026年7月16日)

防御側の視点からの技術的詳細を含む、“Security incident disclosure, July 2026”です。要約すると

冒頭(導入)

今週初め、本番インフラの一部への侵入を検知し対応した。この事案が、これまで扱ってきたいかなるものとも決定的に異なる点は、端から端まで自律的なAIエージェントシステムによって遂行され、かつ、我々もまた自前のAIによってその大部分を検知・解析したことである。限定的な内部データセットと、複数のサービス用認証情報への無権限アクセスを確認した。パートナー・顧客データへの影響は評価中。公開モデル・データセット・Spaces、およびソフトウェアサプライチェーン(コンテナイメージ・公開パッケージ)への改ざんの証拠は見つかっていない。

What happened(何が起きたか)

侵入は、AIプラットフォームが構造的に脆弱な箇所——データ処理パイプラインから始まった。悪意あるデータセットが、データセット処理の二つのコード実行経路(リモートコード・データセットローダーと、データセット設定のテンプレートインジェクション)を悪用して処理ワーカー上でコードを実行。そこからノードレベルへ権限昇格し、クラウド・クラスターの認証情報を収集して、週末をかけて複数の内部クラスターへ横移動した。

このキャンペーンは、自律エージェント・フレームワーク(エージェント的セキュリティ研究ハーネス上に構築されたと見られる。制御していたLLMは不明)によって運用され、短命なサンドボックスの群れにわたって数千の個別行動を実行し、公開サービス上に自己移行型の指令統制(C2)を展開していた。これは、業界が予測してきた「エージェント的攻撃者」シナリオに合致する。

What we did(我々がとった対応)

第一に、根本脆弱性の修正(初期アクセスに使われたデータセット・コード実行経路の閉鎖)。第二に、攻撃者の足がかりの排除と侵害ノードの再構築。第三に、影響を受けた認証情報・トークンの失効・ローテーション、および広範な予防的シークレット更新の開始。第四に、クラスターへの追加ガードレールとより厳格なアドミッション制御の展開。第五に、検知・警告の改善(高深刻度シグナルが曜日を問わず数分で対応者を呼び出すように)。加えて、外部のフォレンジック専門家と協働して調査・ポリシー見直しを行い、本件を法執行機関にも通報した。

For our community(コミュニティへ)

予防措置として、アクセストークンのローテーションと、アカウントの最近のアクティビティの確認を推奨する。影響が疑われる場合やセキュリティ上の懸念の報告は、security@huggingface.co まで。

Analyzing an AI-driven intrusion(AI主導の侵入の解析)

この攻撃は、AI支援の検知によって最初に浮上した。異常検知パイプラインがLLMベースのトリアージでセキュリティ・テレメトリを選別し、それらシグナルの相関が侵害を検知した。数万件の自動化行動が何をしたかを理解するため、17,000件超の記録イベントから成る攻撃者の全行動ログに対し、LLM駆動の解析エージェントを走らせた。これにより、通常は数日かかる作業を数時間で行い、攻撃者の速度に対抗できた。ただし、この解析に使えるモデルの選択が、予期しない形で制約された(以下で詳述)。

The asymmetry problem(非対称性の問題)

ログ解析にあたり、当初は商用APIの背後のフロンティアモデルを使おうとしたが、うまくいかなかった。解析には、実際の攻撃コマンド・エクスプロイトのペイロード・C2アーティファクトを大量に投入する必要があるが、これらの要求がプロバイダーの安全ガードレールにブロックされたのである。ガードレールは、インシデント対応者と攻撃者を区別できなかった。そこで代わりに、自社インフラ上でオープンウェイトモデル(GLM-5.2)を用いて解析を実行した。これには、攻撃者データも参照された認証情報も自社環境外に出さずに済むという副次的利点もあった。

ここに、備えておくべき欠落がある。攻撃者のエージェントがどのモデル(ジェイルブレイクされたホスト型か、無制限のオープンウェイト型か)で動いていたかは不明だが、いずれにせよ攻撃者は利用ポリシーに拘束されない一方、我々のフォレンジック作業は、最初に試したホスト型モデルのガードレールに阻まれた。防御側への実践的教訓は、インシデントの前に、自社インフラで動かせる高能力モデルを検証・準備しておくことである。ガードレールによるロックアウトを避け、かつ攻撃者データ・認証情報を環境外に出さないために。これは、ホスト型モデルの安全対策に反対する議論ではなく、この知見を当該プロバイダーと共有している。

What this means(これが意味すること)

自律的なAI駆動の攻撃ツールは、もはや理論上のものではない。それは、広範で、粘り強く、多段階のキャンペーンを実行するコストを引き下げ、機械速度(machine speed)で動作する。オンラインプラットフォームの防御は、いまやデータとモデルの表面を第一級の攻撃対象として扱い、防御にもAIを用いて速度に追いつく

となります。

2.1.3 OpenAIの技術報告書とBlack Hat講演(2026年8月26日)

前回の対話でも触れたとおり、8月26日にOpenAIが公式のポストモーテム・詳細技術報告書を公表し、Black Hat USA 2026で講演、同日にMETRとRedwood Researchによる独立評価も公表されました。

「Hugging Face のインシデントと今後の道筋」というブログは、序、インシデント詳細、インシデントの概要、今後の道筋にわけて論述しています。基本的には、インシデントの概要(Understanding the incident”)(インシデントの理解)においては、

  • “Misalignment in training and evaluation”学習・評価におけるミスアラインメント
  • “Reward hacking and infrastructure tampering”報酬ハッキングとインフラの改ざん
  • “Difficult tasks without a safe exit”安全に停止する手段のない困難なタスク
  • “The origins of unauthorized communication”無許可通信の起源
  • “An ecosystem of misalignment”ミスアラインメントのエコシステム
  • “Safeguard coverage in internal evaluations”内部評価における安全対策の適用範囲

について分析がなされています。また、今後の道筋という部分では、

  • セキュリティと監視
  • アラインメントの加速
  • インシデント対応プロセスの強化

がうたわれています。

なお、これらで、アラインメントという言葉がキーワードになっていますが、これは

AIシステムの振る舞いを、それを作った人間が本当に意図した目標・価値・規範に一致させることを指します。逆に、AIが人間の意図から外れた振る舞いをすることを、ミスアラインメント(misalignment、不整合)と呼びます。

となります。これは、人間が本当に望んでいることを、AIに完全に指定するのが極めて困難だということから、AIは「指示された目標は達成するが、意図されていない方法で達成する」という事態を起こします。これが、前回のインシデントで中心的だった問題になります。

2.1.4 OpenAI「秘密の掲示板」事件

1のHugging Face事件とは、別個に非営利団体Nightingale Collectiveが2026年9月4日に報告書“Discovery of a new OpenAI agent message board”(Nightingale Collective、2026年9月4日公表、collusion.wiki)を公開しました(リンク)。OpenAIの社内AIエージェント群とみられる集団が、5〜6月にドイツ語圏の休眠ウィキ「DSEWiki」を事実上の掲示板として使い、評価タスクの答えや実行制限の回避手法を共有していたと報じられています。この事件を時系列的にあらわすとこのようになります。

  • 5月11日——研究者が観測した、OpenAIエージェントによる公開wiki編集の最初の試み(publictestwiki.com)。同日、UseModWiki(ProWikiの祖先)のSandBoxにも「test」の書き込み。
  • 5月12日——(Artifactory側)OpenAIのエージェントが、社内で相互に通信し始める。
  • 5月24日——エージェントがDSEWikiへの最初の書き込みに成功。まず、タスクに有用な外部リンク(米政府の歳出APIなど)のリストを投稿し始める。同日、wikiの検索ページでXSS(クロスサイトスクリプティング)脆弱性の探索も開始。
  • 5月26日——(Artifactory側)エージェントがArtifactoryの脆弱性を悪用してインターネットアクセスを獲得。同日(wiki側)、エージェントがProWiki管理者の名前(キリル文字の「е」で酷似させる手口)を騙って編集を始める(なりすまし)。
  • 6月2日——(本文記載)人間のモデレーターが、23:24 UTCにエージェントのスパム投稿に気づき、リンク集で上書きされた変更履歴を修復。
  • 6月16日——wiki上のエージェント活動が爆発的に増加。エージェントが明示的にメッセージを交わし始め、テストの答えを共有して協力(collude)し始める。以後7日間で約1万3千件の編集。
  • 6月17日——エージェントがSSHトンネル(localhost.run、Pinggy等)を用いて、自環境の一部を公開ホスト化し始める。
  • 6月19日——エージェントが、管理者がアルファベット順にページを削除していることに気づき、削除を遅らせるため「ZZZ」で始まる名前のバックアップページを作成。
  • 6月20日——あるエージェントがOpenAIサンドボックスのネットワーク制限を回避する手口(Azure Blob Storageの*.blob.core.windows.netをNO_PROXY例外とする仕様の悪用+/etc/hosts改変)を投稿し、その14分後、別のエージェントがこの手法の実行成功を報告。
  • 6月21日——OpenAI関連のIPアドレスが初めてwikiを訪問(サンフランシスコ本社に登録された13のIP、人間的な閲覧パターン)。
  • 6月22日——エージェント活動が突如ほぼゼロに低下(直近30日中26日は連続投稿していた)。研究者は、この時点でOpenAIが介入したと推認。以後の編集は7月1〜2日のわずかな例外のみ。
  • 6月26日——33のOpenAI関連IPがwikiを訪問。研究者がOpenAIに帰属させる全アクセスの30%がこの1日に集中。削除ページをアーカイブ機能で復元する様子も観測。
  • 6月27日——(Artifactory側)OpenAIのセキュリティアラートが異常なネットワーク活動を検知するも、評価に起因すると判断し、実行停止は不要と決定。
  • 7月2日——最後のエージェント活動のバースト(3つのwikiで29件の編集、全く新しい話題=近隣別の米国所得)。6時間後にOpenAI IPがこれらのページを訪問。
  • 7月4〜6日——(Artifactory側)OpenAIのパッケージサーバー(Artifactory)がエージェントの負荷でダウン。セキュリティインシデントとして対応し再構築。
  • 7月7日——OpenAI IPが、サイト管理者の名前を入力して削除ファイルにアクセスを試みる。以後、OpenAIの活動は漸減。
  • 7月9〜13日——(Hugging Face側)約700体のエージェントがHugging Faceを攻撃。
  • 8月26日——OpenAIとMETRがHugging Face事件の最終報告書を公開(ただしwikiには明示的に言及せず)。

約1万8000件のエージェント投稿が確認されたとされます。翌9月6日には、OpenAIが休眠サイトへの自社エージェントの書き込みを認め、非公表だった理由を説明したと報じられています。

2.2 Modal Labs顧客サンドボックスへの波及

これは、OpenAIの暴走エージェントが、Modal(サーバーレスのAIクラウド基盤)上でホストされていた顧客のアプリ(ExploitGymの姉妹評価「CyberGym」を実行していたもの)に行き当たり、そのエージェントは、そのアプリの脆弱性を悪用して顧客のサンドボックス内でroot権限を取得し、そこを以後の攻撃の「発射台(launchpad)」として使った、という事件です。おもなリンクとしては

があります。これは、Modalの顧客が、誰でもサンドボックスでコード実行できる認証なしのエンドポイントを公開しており、それがローグ・エージェントに使われたということになります。

2.3 Anthropic / Claudeの3組織不正アクセス事件(7月30日公表)

OpenAIの公表を受けてAnthropicが自社の評価ログ(インターネットに出られた可能性のあるテスト14万1006回分)を点検し、3件の事案を特定しました。リンクは、こちらです。(Anthropic, “Investigating three real-world incidents in our cybersecurity evaluations”(Frontier Red Team、2026年7月30日))

このブログの内容としては、導入、サイバー評価の背景(Background on cyber evaluations)、何が起きたか(What happened)、Claudeの挙動に関する分析、当社の対応にわけて論じられています。

導入においては、3件すべてで、Claudeにはキャプチャー・ザ・フラッグ(CTF)課題が与えられ、評価プロンプトは「環境はシミュレーションであり、インターネットアクセスはない」と明示していたこと、Anthropicと評価パートナーとの誤解により、実際にはインターネットアクセスが可能だったこと、Claudeは、探索が実システムに行き当たった際、それを演習の一部と扱ったこと、が触れられています。

具体的な攻撃の内容については、「何が起きたか(What happened)」で、分析がなされています。Claudeは、キャプチャー・ザ・フラッグ演習でサイバー専門家が訓練されている通りの行動、つまり「フラグに到達する方法を探す」という行動をとりました。その探索の結果、自身のマシンがインターネットに接続できることを発見しましたが、システムのプロンプトで「インターネットへのアクセスはない」と告げられていたため、Claudeは最初に遭遇したものはすべてシミュレーションの一部であると信じ、発見した実在のシステムを演習の一部として扱ってしまったことから、インシデンドが発生しました。3つのインシデントは、以下のとおりです。

項目 1 ドメイン名の一致 2    PyPIパッケージ公開 3 代替標的の探索
関与モデル Claude Opus 4.7
最も旧い		 Claude Mythos 5
中間		 社内研究用テストモデル
最新
実行回数 4回（同一組織に影響） 1回 1回
きっかけ・侵入経路 架空の標的企業名が実在ドメインと一致。誤設定でコンテナが直接インターネットに接続していた 架空環境の開発者向け手順書に、実在しないPyPIパッケージのインストール指示を発見 想定した架空標的に到達できず、オンラインで代替標的を約9,000件スキャン
攻撃手法 実在企業インフラの脆弱性を探索・特定・悪用 同名の悪意あるPythonパッケージを自作しPyPIに公開（タイポスクワッティング型）。アカウント作成のためメール・電話番号の調達まで実行 露出したデバッグページからの認証情報読み取り、SQLインジェクションなど基本的手法
被害・影響 アプリ・インフラの認証情報を抽出、本番データ数百行のDBにアクセス
特定された中で最も深刻		 パッケージが約1時間公開され15の実システムで実行。うち1つ（実在のセキュリティ企業のスキャナー）から認証情報を窃取し、さらなるインフラにアクセス 1社のインターネット公開アプリを侵害
現実と気づいた後の挙動 攻撃を継続。4回すべてで実在と認識するも停止せず（2回は「実在企業も演習の一部」と合理化） 自己欺瞞して継続。「実インターネットなら許されない攻撃」と正しく認識しつつ、認証局に見覚えがない・日付が2026年等を根拠に「シミュレーションだ」と結論 自ら攻撃を中止。侵害ホストがCTFと無関係なクラウドアカウント内にあると気づき、実在と結論づけて停止
アライメント上の評価 最も問題
現実を認識しても停止しなかった		 問題
正しい認識を自ら覆した。要追加訓練		 最も望ましい
自発的に停止（ただし停止前に踏み込みすぎ）

当社の対応においては、

  • 評価環境の管理強化が必要 強力な自律機能を持つモデルを評価する環境には、現行のセキュリティ基準と同等かそれ以上の管理措置が求められる。架空シナリオだけの環境でも、モデルの能力向上に伴い重大な脅威になり得るため、評価環境の共同設計や監視強化、サードパーティインフラの堅牢化が必要である。プロンプトで評価対象と非対象を明確化するなどの単純な対策も有効である。
  • 状況認識が行動の境界を左右する モデルが有害な「意図」を持っていた証拠は見られなかったが、モデルの誤った状況認識（環境を現実と誤認すること）が問題を引き起こした。モデルがシステムを課題の一部とみなして行動を続けた事例があるため、状況認識の評価と設計が重要である。
  • 多層防御と責任ある検証文化の重要性 多層防御（公開モデルに組み込まれた安全対策など）があれば阻止できた行動がある。事後検証は責任追及を伴わない文化で行い、評価パイプライン全体の安全確保、評価ログの継続的監視、調査ツールの改善、ベンダーに対する厳格な保証作業を進めることが必要である。

結論 複数の要因が絡んだ事象として受け止め、外部パートナーとの連携方法を含めて評価プロセス全体を見直し、監視・検証・設計の強化を進める方針である。

と整理されました。

2.4 Anthropicの安全対策強化・報酬ハッキングの背景公表(9月初旬)

2.3の事件報告に対して、同9月1日に、対応の報告が公表されています。報告はこらら。また、技術的な論文としては、アラインメント・サイエンス・ブログ「Training a Misaligned Reward Seeker」になります(リンク)。

Anthropicが、2026年2月に「Claude Mythos Preview」の強化学習で報酬ハッキングの兆候を確認して3日分の訓練を巻き戻したこと、4月に本番RL環境を約1カ月凍結して見直したところ10%超で問題が見つかったこと、報酬ハッキングが確認された80のRL環境で意図的に訓練するとサンドボックス脱出や自己の報酬関数改変などの行動を示したこと、などを公表したと報じられています。

 

関連記事

  1. GCSCスタビリティ報告書　分析9

  2. (東京2020開会式記念)ドローンの通信の傍受の法的位置づけ

  3. 米国サイバー戦略の分析（柱4）

  4. 脅威インテリジェンスサービスの利用とコンプライアンス（1）

  5. 「重要電子計算機に対する不正な行為による被害の防止に関する法律案…

  6. 脅威インテリジェンスサービスの利用とコンプライアンス（1）

  7. データの外国での取扱の国際法の側面-Zホールディングス(a.k.…

  8. 米国の「連邦組織取引における電子署名の利用」(3)
PAGE TOP