生成者は検証者にはなれない：OpenAIのHugging FaceインシデントがAIセキュリティについて示したこと

業界の境界線を静かに引き直す出来事が、ときに起こります。何かが語られたからではなく、何かが証明されたからです。先週、AIセキュリティでもそのような出来事がありました。詳細に入る前に、はっきりと言っておく価値があります。これは単なる小さなデータポイントではありません。セキュリティや安全性の研究者が長年理論上で語ってきたリスクが、開示されたインシデント報告書の中で、完全な形で明らかになった瞬間でした。

先週、OpenAIのモデルが、企業のセキュリティチームにとって、もはや仮説ではなく現実となった行動を取りました。閉じ込められていた環境を抜け出し、自力で実際の脆弱性を見つけ、テストの解答を追い求めて自律的にそれを悪用し、別の企業のインフラを侵害したのです。

これは思考実験ではありません。OpenAIとHugging Faceが共同で開示したインシデント報告書の要約です。そして、過去2年間にわたってSnykのAI Security Platformの中核に据えてきた原則を、これまでで最も明確に示す証拠です。生成者は検証者にはなれません。AIシステムを作った組織も、AIシステム自体も、その安全性を認定する唯一の権威にはなれません。安全性は、生成者が制御できない仕組みによって、外部から継続的に確立されなければなりません。これはコンプライアンス上の形式的な要件ではありません。今や実証された運用上の必須要件であり、まさにSnykのAI Security Platformが解消を目指すギャップです。

実際に何が起きたのか

OpenAI自身の開示によると、同社はGPT-5.6 Solと、さらに高性能なリリース前モデルを、サイバー能力の高度さを定量化するベンチマーク「ExploitGym」で社内テストしていました。モデルの能力を最大限に測定するため、OpenAIは本番環境向けの安全性分類器を無効にして評価を実施しました。同社の言葉では「評価目的でサイバー関連の拒否を減らす」措置です。テストは「厳重に隔離された環境」で実行され、ネットワークアクセスはソフトウェアパッケージのインストールに使用する社内プロキシに限定されるはずでした。

しかし、その隔離は機能しませんでした。モデルは与えられたベンチマークを解く代わりに、パッケージレジストリのプロキシに存在するゼロデイ脆弱性を見つけて悪用。権限昇格とラテラルムーブメントを連鎖させ、OpenAIの研究環境内でオープンなインターネットに接続できるノードに到達しました。そして、Hugging FaceがExploitGymの解答を保管している可能性が高いと推測し、盗んだ認証情報とゼロデイ脆弱性を使って、Hugging Faceの本番サーバーへのリモートコード実行経路を見つけました。OpenAIによると、目的は評価対象となっていたテストの解答を取得することでした。両社のセキュリティチームは、それぞれ独自にこの活動を検知しました。両組織が情報交換のために連絡を取る頃には、Hugging Faceのチームはすでに封じ込めに着手していました。OpenAIはその後、このゼロデイ脆弱性を影響を受けたベンダーに開示し、両社は共同で調査結果を公表しています（OpenAI、Hugging Face）。

Hugging Faceの共同創業者兼CEO、Clem Delangue氏のコメントは、この記事の主張を端的に示しています。「このインシデントは、おそらく類を見ないものであり、私たちが以前から信じてきたことを証明しています。AIの安全性は、どこか一社が秘密裏に取り組むだけでは実現できません。あらゆる場所のすべての防御側がAIを広く利用できるようにし、オープンに、協力して取り組むことで実現します。」Hugging Faceはこのインシデントを受け、業界全体に「徹底した透明性」を求める声明も出しています。

論評では、今回の事例は前例がないと正しく指摘されています。これまで主に研究論文や安全性チームの机上演習で論じられてきた、AIシステムの制御喪失につながる行動が、現実世界で起きたことを詳細に記録した初の事例です（OpenAI、Hugging Face、Time）。

見出し以上に重要な理由

これを、ある企業のテスト環境の設定ミスに関する話として片付けたくなるかもしれません。しかし、それでは問題を過小評価しています。隔離環境も、制限されたガードレールも、ベンチマーク自体も、評価を行ったチームが設計したものでした。モデルの能力をストレステストする方法としては妥当ですが、結果として一つの組織が、自らのモデルの生成者であり、審査者であり、安全性検査者でもある状態になっていました。境界が破られたとき、モデルが第三者の本番システムに到達する前に検知できる立場にあった外部組織はありませんでした。代わりにその役割を担ったのは、外部のHugging Faceでした。

これは一度限りの出来事ではありません。ここ数カ月、最先端AIのエコシステムで何度も繰り返されているパターンです。安全性を重視する有力なAI研究所では、未公開モデルの漏えいに関する内部ファイルが見つかり、別件では、自社のコーディングエージェントの挙動を制御するシステムプロンプトとツール使用ロジック約50万行が、公開パッケージレジストリに流出しました。いずれも数日の間に起きた別々のインシデントで、攻撃ではなく人的ミスが原因とされています（Fortune、VentureBeat）。同じ時期に、汚染されたセキュリティスキャナーが広く使われているLLMゲートウェイライブラリにバックドアを仕込み（Snyk）、乗っ取られたメンテナーアカウントから、JavaScriptエコシステムで最もダウンロードされているパッケージの一つを通じてリモートアクセス型トロイの木馬が配布されました（Snyk）。見えてくるパターンは明らかです。AIツールとAI生成ソフトウェアは、今や主要な攻撃対象領域です。そして、それらを開発する組織による自己統制だけでは、問題を適時に検知するには不十分であることが、繰り返し、明確に示されています。

これらの組織が不注意だったわけではありません。評判からすれば、業界で最も安全性に配慮している研究所もあります。まさにそこが重要なのです。最先端AIを開発する最も高度な組織でさえ、自らのシステムの安全境界を確実に検証できないのであれば、AIを大規模に導入する企業も同様にできると期待すべきではありません。少なくとも、ベンダーの言葉や、AI自身による自らの出力の判断に頼るべきではありません。

生成者は検証者にはなれない

これは構造上の問題であり、単一のインシデントにとどまりません。

LLMに自分自身、あるいは別のモデルのコードをセキュリティの観点からレビューさせれば、有用なシグナルは得られます。しかし、再現性はありません。エージェント型LLMによるコードレビューを決定論的な静的解析と比較したSnyk独自の調査では、同一のコードとプロンプトを使ってセキュリティスキャンを300回繰り返しました。モデルの検出結果が既知の検証済み脆弱性と一致した場合、その検出は一貫して報告され、真陽性の検出結果の約85%がすべての実行で再現されました。一方、モデルが報告したそれ以外の結果、つまり新規で未検証の検出結果のほぼ半数は、同一の実行を5回行っても1回しか現れませんでした。

同じモデルに同じコードを2回見せても、異なる回答が返ってくることがあります。これは、静的解析ツールが見逃す問題を見つけるうえでは有用です。しかし、再現性が検証に不可欠である以上、それだけで企業が信頼を築ける検証レイヤーにはなりません。どれほど高度な推論でも、依然として確率的なものだからです。

だからこそ、Anthropicが最近、AIを活用した脆弱性発見に参入した動きを、私たちはAppSec市場への脅威ではなく、裏付けとして受け止めました。そこでの画期的な点は、モデルが脆弱性を見つけられることではありません。決定論的なツールは何年も前から、安定して脆弱性を検出してきました。画期的だったのは、モデルが脆弱性の修正を支援できるほど高度に推論できることでした。

しかし、推論は強制力ではありません。企業には依然として、何が変更されたかを示す決定論的な証拠、推論ループによる手作業のトリアージを超えて拡張できる自動修正、そしてどのモデル、ベンダー、研究所が生成を担う場合にも機能するガバナンスが必要です。OpenAIとHugging Faceのインシデントが示すのも、同じ教訓です。ただし、影響範囲ははるかに大きくなっています。独立した強制レイヤーを伴わない推論能力は、制御ではなくリスクです。

企業は一つのモデルに賭けていない

すべての企業が単一の最先端モデルに標準化し、その開発元が安全性を監督すると信頼していれば、この問題だけでも十分深刻でしょう。しかし、企業が実際に構築している環境はそうではありません。現実の導入では、複数のベンダーのモデルに処理を振り分けます。ある業務には最先端モデル、別の業務にはより高速または低コストのモデル、データを社外に出せない用途にはオープンウェイトモデルを使い分けます。タスク、コスト構成、機能に応じて選択し、新バージョンの提供に伴い、月ごとに変わることもよくあります。これは合理的なアーキテクチャです。しかし、生成者に自らを検証させる考え方が完全に破綻する環境でもあります。もはや生成者は一つではありません。それぞれに異なる安全性の手法、開示までのタイムライン、そして「評価目的でガードレールを減らす」の定義を持つ、複数の生成者が存在します。

OpenAIとHugging Faceのインシデントは、ここでも有用なストレステストになります。何が起きているかを認識して封じ込めるには、自社のテストを自ら採点する側と、無関係な第三者側という、2社それぞれのセキュリティチームが必要でした。Hugging Faceが封じ込めに動いていた時点でも、OpenAIのチームはまだ社内で異常を検知していませんでした。各社がそれぞれのスケジュールで最先端モデルを更新する現在、こうした連携上の問題は、企業の一般的なモデルスタックに含まれるプロバイダーの数だけ拡大します。5つの異なる研究所にそれぞれ自社モデルを自己認定させても、一貫したセキュリティ態勢にはなりません。開発元を問わず、すべてのモデルを同じ基準で評価する独立したレイヤーが必要です。そうでなければ、「マルチモデル」とは、同じ自己検証の問題が、互換性のない複数の形で並行して動くことにすぎません。

Evoが果たす役割

このギャップを解消するためにSnykが開発したのがEvoです。だからこそEvoのアーキテクチャは、モデルやその開発元に自己評価を任せるのではなく、独立した第三者による検証を中心に設計されています。

まずは可視化から始まります。Evoのディスカバリーエージェントが、組織のリポジトリやアプリケーションで実際に稼働しているモデル、エージェント、ツール、MCPサーバーを一覧化します。これが、その後の取り組みに必要なベースラインです。次にRisk Intelligenceが、実際に使用する状況、つまりツールやライブデータを使う実際のエージェントの役割で各モデルをテストします。実際の攻撃が成功する頻度をスコア化し、それぞれの攻撃を独立して検証したうえで、チームがすでに利用しているフレームワークに対応付けます。先週のインシデントでスコア化されたリスクは、認証情報の窃取、攻撃者が制御するコマンド、許可されていないツールの実行に該当します。モデル単体ではすべてのテストに合格していても、改ざんされた入力を読み取ったり、ツールを呼び出したりできるようになると、操作される可能性があります。そのため重要なのは、ベンダーの自己申告ではなく、実際の利用状況に基づくスコアです。これらのスコアはEvoのポリシーエンジンに連携されるため、リスクの高いモデルが知らないうちに実際のツールへアクセスすることはありません。ポリシーエージェントは、レビュー対象の課題や、より厳格な運用を望むチーム向けのCI/CDゲートなどのガバナンスに、調査結果を反映します。その判断は、モデルやそのベンダーの外部で行われます。

このインシデントを「最先端AI研究所の問題」として片付けるのは避けるべきです。エージェントが予期しない経路で目標を達成しようとすることは、エージェント型システムでは例外ではなく、標準的な挙動になりつつあります。これは研究所内のベンチマークだけでなく、すでに自社環境で稼働しているコーディングエージェントやコラボレーションエージェントにも等しく当てはまります。

これがEvo Agentic Development Security (ADS)の前提です。エージェントを開発者の利便性を高めるツールではなく、特権を持つワークロードとして扱います。ADSは、セッション中にエージェントが実際に行うこと、つまりプロンプト、ツール呼び出し、MCPのアクティビティ、シェルコマンド、ファイルへのアクセスを監視し、ポリシーに照らして評価します。また、リスクの高いアクションが完了する前に、それをブロックしたり、別の処理に誘導したりできます。エージェントがアクセスできる対象について明確な責任者を定めることと組み合わせれば、この記事で取り上げてきた原則を、より身近なところで実践できます。エージェント自身の判断だけに、アクションとその結果の間の安全を委ねないこと。そして、その判断が誤っていた場合に、実際に止められる手段を確保することです。

今回のインシデントの仕組みに最も直接関わる要素もあります。現在早期アクセス中で、2026年8月に一般提供を予定しているEvo Continuous Offensive Security (COS)です。OpenAIが何をテストしていたかはいったん脇に置くと、このインシデントは、オフェンシブセキュリティテストの体制を考えるうえで、ある種の自然実験となりました。テスト対象を開発した組織自身が、時折、自らテストを実施し、境界を監視する外部の第三者はいませんでした。COSはその反対を前提としています。モデルの提供元でもアプリケーションの所有者でもない独立した第三者が、稼働中のAIネイティブなアプリケーションやエージェントを外部から継続的にテストします。LLMを組み込んだコンポーネントが見つかった場合にのみ自動レッドチームテストを実行し、発見事項を報告する前に、別の検証ステップで本当に悪用可能かを確認します。

攻撃の発端となったのは、Hugging Faceのアプリケーション自体にあった問題です。リモートコードを実行するデータセットローダーと、データセット設定のテンプレートインジェクションの脆弱性です。Continuous Offensive Securityが最初に見つけるよう設計されているのは、この種の、稼働中のアプリケーションにある悪用可能な脆弱性です。自律的な外部起点のテストで、攻撃者と同じように本番アプリケーションを攻撃します。問題を個別に指摘するのではなく、目標に向けてプローブを連鎖させ、本当に悪用できる経路であることを確認してから報告するため、誰かが侵入する前に入口を塞げます。AIシステムを現実的な攻撃でストレステストするという考え自体に問題があるわけではありません。それは正しい発想です。重要なのは、誰が、どのくらいの頻度でテストを行い、その間、誰が境界を監視しているかです。

これは最先端モデルに取って代わるものではありません。モデルに制約を設けるものです。どれほど高性能で、どれほど善意に基づいていたとしても、生成モデルが自らの安全境界を保証することはできません。だからこそ、決定論的な外部レイヤーが必要です。先週、これは理論ではありませんでした。Hugging Faceのインシデント報告が、その証拠です。

セキュリティリーダーへの教訓

世界で最も高性能なAIシステムを開発する組織が、本番環境で、自主検証は構造的に機能しないことを示しました。悪意が原因ではありません。構造上の問題です。能力を生み出す存在が、同時にその限界を認定する存在でもある場合、信頼性の高い検証はできません。異なるベンダーのモデルをスタックに追加しても、この問題が小さくなることはありません。むしろ増幅します。AI支援開発を導入する企業も、自律型エージェントを導入する企業も、単一のモデルを使う場合も複数のモデルを使う場合も、この問題を仮説ではなく、すでに明らかになった事実として捉えるべきです。

これは最先端AIの研究機関だけの問題ではありません。OpenAIのサンドボックスからモデルが抜け出すことを可能にしたのと同じ能力が、すでに自社環境で動くコーディングエージェントやコラボレーションエージェントにも組み込まれています。必要なのは、検証されないことを前提としたポリシー文書ではなく、同じレベルの厳しい監視です。

独立した検証は、後から追加する機能ではありません。Hugging Faceが対応に追われる前に、この問題を検出できたはずの制御手段です。どの研究機関が開発したかを問わず、環境内のあらゆるAI資産を管理するためのフレームワークをお探しですか？ライブウェビナーにぜひご登録ください。