Ashraf

OpenAI/Hugging Face事件、モデル評価のセキュリティに警鐘

昨日、OpenAIとHugging Faceから開示されたモデル評価中の侵害は、「セキュリティインシデント」として軽視されていました。AI駆動のパイプラインを構築するエンジニアの皆さん、その見方には注意が必要です。これは単なるデータ漏洩ではなく、eval-as-a-serviceアーキテクチャの根本的な失敗です。

最先端モデルを評価する際、私たちは事実上、サードパーティAPIから提供される信頼できないコードを、自社の独自プライベートデータセットに対して実行しています。これはセキュリティ上の悪夢であり、それが今や標準になりつつあります。

失敗の原因：Eval by Proxy

今回のインシデントの核心はシンプルでした。モデル評価中に外部リクエストパイプラインが悪意ある入力ペイロードを評価コードを実行する環境とやり取りできるようにしてしまっていました。

主要ラボが使用する自動評価フレームワークの多くは、本番アプリケーションコードのように「サンドボックス化」されていません。以下の理由から、緩い環境で動作しています：

  1. ツールアクセス：モデルは推論を証明するためにコード（Python REPL）を実行する必要があります。
  2. データアクセス：評価はプライベートテストセットを読み取る必要があります。
  3. 環境の永続性：評価ツールは複数ステップにわたってコンテキストを保持することがよくあります。

未検証のモデルプロンプトにその環境を公開すると、根本的にモデルに対するRCE（リモートコード実行）の罠を作り上げてしまうことになります。

セキュリティモデルの見直しが必要な理由

エンジニアリングチームはこれまでLLMを「安全な機能的入力」として扱ってきました。モデルは単にテキストを返すだけだと想定していたのです。しかし評価の文脈では、モデルはオーケストレーターです。悪意ある訓練データや毒されたファインチューニングによってオーケストレーターが侵害されると、「評価」そのものが攻撃ベクトルになります。

直ちに変更すべき3つのこと：

  1. 評価ループのサンドボックス化：ローカルまたはHugging Face Spacesなどの共有クラウドインフラで評価パイプラインを実行する場合、モデルは必ず脱出を試みると想定してください。各評価パスは、出口なしでカーネル制限を強化した短命のエフェメラルコンテナで実行する必要があります。
  2. 評価用データのスクラビング：モデル性能をテストするために最も機密性の高い「ゴールデンデータ」を評価に投入しています。サードパーティAPIを利用している場合、そのデータは実質的にモデルの訓練ループの一部となります。差分プライバシーや厳格にサニタイズされたテストデータを使用していない場合、データは漏洩しています。
  3. 「Eval Service」の監査：フレームワークを盲信してはいけません。Hugging Faceから重みやAPIベースの補完応答を自動的に取得するツールを使用している場合、それらの接続は信頼できないサードパーティ入力として扱ってください。モデル呼び出しの戻り値に対して厳格なレート制限と入力検証を実装してください。

結論

業界は独自の評価パイプラインを構築することを恐れるあまり、「Eval-as-a-Service」プラットフォームの構築を急いでいます。しかしOpenAIとHugging Faceが示したように、これを自動化するインフラは、それを保護するセキュリティよりも速く進んでいます。

「evals」を単なるCIステップとして見てはいけません。独自データを外部のブラックボックスに供給する機密パイプラインです。適切に対応してください。

Reference: OpenAI/Hugging Face Security Incident Disclosure (July 2026)