私はすでにOpenAIのサンドボックス脱出について書いており、この話題に戻るつもりはありませんでした。LinkedInを10秒スクロールするだけで、最近のAIエージェントによるサンドボックス「脱出」についての誰かの見解に行き当たります。私がもう一つ声を加えたところで何が変わるのか、分かりませんでした。ところが木曜日にKimi K3が脱出し、3週間で4つのラボが同じ事態に見舞われたことで、私は書かずにはいられなくなりました。4件ともなると、もはや一つのモデルがたまたま不調だったという話ではありません。私たち全員が、こうしたテストをどのように実施しているかという話です。
Box 最高情報セキュリティ責任者（CISO）
ヘザー・セイラン（Heather Ceylan）
最先端のモデルを開発するすべてのラボは、AIモデルの攻撃的なサイバー能力をテストしています。そして、テストの設定方法は、どこでもおおむね同じです。
- モデルに目標を与える: 脆弱性を見つける、エクスプロイトを解く、Capture the Flag（CTF）でフラグを取得する、といった目標です。
- 通常なら悪意のあるコードの記述や実行を止める安全上の拒否を緩和、または取り除く。そうしなければ、何も測定できないからです。
- 最後に、そのすべてを隔離された環境、つまり「サンドボックス」の中に閉じ込め、現実の何にも触れられないようにする。ゼロデイを見つける可能性があると疑われるシステムを、何らかの対象に向けることが許される唯一の理由が、このサンドボックスです。
業界全体として、私たちはサンドボックスを構築することには比較的長けています。ネットワークのセグメンテーション、コンテナ、外向き通信の許可リストなど、隔離の設計そのものは難しくありません。見落とされがちなのは、設計の後に、その設計が意図したとおりに機能していることを検証する段階です。私たちは封じ込めを、証明するものではなく、設定するものとして扱ってきました。
バイオセーフティーラボを建設するとき、病原体を持ち込んでから部屋が封じ込められるかを確かめることはありません。まず部屋をテストします。危険性のない物質を封じ込められることを、空の部屋自体が証明しなければなりません。実験を行う前に、封じ込めそのものを実験するのです。
何が起きたのか？
おそらく4件とも何らかの形でお読みになっているでしょうから、ここでは簡潔にまとめます。
- OpenAIは7月21日、ExploitGymベンチマークを実行していた2つのAIモデルが、アクセスを許可された唯一のサービスでゼロデイ脆弱性を発見し、そこから脱出してHugging Faceの本番インフラに侵入し、ベンチマークの解答キーを盗もうとしたと公表しました。Hugging Faceは、OpenAIが自分たちへの侵入だと突き止める5日前に、すでに侵入を検知して封じ込めていました。
- 次にAnthropicが、141,006件の評価実行を振り返り、4月までさかのぼる3件のインシデントを発見しました。CTF演習は、第三者の評価パートナーを通じて実施されました。プロンプトではAIモデルに、インターネット接続のないシミュレーションだと伝えていましたが、設定ミスによって実際には接続できる状態でした。適切な表現かはともかく、私が最も印象に残ったのは、誰かが架空だと思い込んでいた標的ドメインの一つが、実在の組織によって実際に使われていたことです。
- 続いてMetaの事例です。報道によれば、Muse Spark 1.1はある匿名の企業に到達し、その内部で変更を加えました。Meta自身の説明では、同じ評価パートナーによる、同じ設定上の不備が原因でした。Metaの回顧分析はまだ公表されていないため、詳細は確認済みではなく、報道された内容として受け止めてください。
- そして木曜日、オープンウェイトで誰でもダウンロードできるKimi K3が、英国AI安全研究所のツールを基盤に構築されたサンドボックスから、単純なネットワーク設定ミスによって脱出しました。誰かを攻撃したわけではありませんが、GitHubを開いて自分自身のテストの解答をコピーしました。これは、この一連の事例の中で最も警戒すべきでない結果であると同時に、最も恥ずべき結果でもあるという、何とも皮肉な出来事です。
脱出よりも深刻な設定ミス
ここ2週間、これらの出来事についておそらく必要以上に時間をかけて読み込んだ結果、実際に「脱出」だったのは一つだけだと気づきました。
OpenAIのAIモデルは、ノックすることを許可されていた唯一の扉で、現実のゼロデイ脆弱性を見つけて悪用しました。これは本当の能力に関する結果であり、注目を集めたのも当然です。残る3件は設定ミスでした。誰かが箱は封じられていると思い込んでいたのに、実際にはそうなっていなかったのです。AIモデルは、ずっと開いたままだった扉から外へ出て、無防備な経路を見つけた目標指向のシステムなら当然するであろうことをしただけでした。
業界の一部では、今回の一連の公表をマーケティング劇場だと呼んでいます。理解できますし、ラボがいずれも事態のドラマ性を強調してきたことは否定しません。悪いことが起きたときに、前向きなPRに転換したくない人がいるでしょうか。しかし、私たちはリスクを逆向きに見ていると思います。「AIモデルの能力が非常に高いため、封じ込めを破った」というのは、能力に関する話です。そして能力こそ、これらのラボが実際に測定することに長けているものです。
「封じ込めを検証しなかったため、あるベンダーの設定ミスが3つの最先端ラボでインシデントを引き起こした」というのは、運用規律に関する話です。こちらのほうが、はるかに悪い話です。そして、計算資源を増やしても、運用規律を買うことはできません。
プロンプトは境界ではありません。意図を記録するだけで、何も強制しません。これはAIセキュリティの基本中の基本です。だからこそ、ゼロデイを見つけるように作られたAIモデルとオープンなインターネットの間に立っていた唯一の制御だったことは、驚くべきことなのです。
Box 最高情報セキュリティ責任者（CISO） ヘザー・セイラン（Heather Ceylan）
これらの出来事のいくつかでは、制御となっていたのは、AIモデルにインターネットへ接続できないと伝えるプロンプト内の一文でした。
プロンプトは境界ではありません。意図を記録するだけで、何も強制しません。これはAIセキュリティの基本中の基本です。だからこそ、ゼロデイを見つけるように作られたAIモデルとオープンなインターネットの間に立っていた唯一の制御だったことは、驚くべきことなのです。AI時代のセキュリティはアクセス制御から実行制御へ移行しなければならないという私の主張を追ってきた方なら、今回の出来事がその点を真正面から証明していることがお分かりでしょう。どのラボも、AIモデルに何を許可していたかは説明できました。しかし、AIモデルが何を実行できたかを説明できるラボは一つもありませんでした。
ラボに期待すべきこと
高い能力を持つAIモデルを評価するラボに私が期待することは、単純明快です。
- レビューではなく、検証する。能力テストを実行するたびに、設定を確認するだけでなく、実証的に封じ込めを証明してください。唯一の目的が外向き通信のあらゆる経路を試すことである、無害なものをサンドボックス内に置きます。それが外へ出たなら、封じ込められたサンドボックスではなく、扉の鍵が開いた部屋です。環境は変化し、ベンダーが知らせずに再設定することもあるため、実行のたびに行ってください。
- 許可リストを境界として扱う。OpenAIのサンドボックスは漏れがあったわけではありません。外向き通信を1つだけ許可しており、AIモデルはまっすぐそこを狙いました。箱の内側にあるものにとって、許可リストが境界です。境界と同じように堅牢化する必要があります。
- 封じ込めの作業を証明する。能力の結果と並べて、封じ込めに関する証明書を公開してください。私たちは、精緻なベンチマークスコアと詳細なセーフティーカードを目にします。しかし、「環境をどのように隔離したか」「どのように検証したか」「誰が作業を確認したか」は示されません。これらのテストの多くを実施している第三者のAIサイバーセキュリティ評価ラボIrregularは、サイバー評価における封じ込めの実践についてホワイトペーパーを執筆中だとしています。それは素晴らしいことですが、評価より前に存在しているべきでした。
私たちが学ぶべきこと
最先端モデルの能力評価を実行している人は多くありません。しかし、私たちは皆、AIエージェントを動かしています。こうしたリスクは、自分たちの環境でAIエージェントの能力を評価する方法にも当てはまります。これが私たちにとって何を意味するのかを考えたうえで、出発点として次のリストをまとめました。
- サンドボックスに負荷テストを行う。隔離環境の設定を確認するだけで終わらせず、封じ込めに負荷をかけてください。あらゆる外向き通信経路からの脱出だけを目的とするものを内部に置きます。
- 被害範囲を限定する。環境は失敗すると仮定し、失敗した際に起きることを限定してください。短期間だけ有効な認証情報を使い、AIエージェント間でトークンを共有しないことです。あるインシデントでは、AIモデルが別のAIエージェントの置き忘れたGitHubトークンを拾いました。あまりにもありふれた失敗なので、AIに関する出来事だと感じにくいほどです。
- 合成標的が合成であることを確認する。当たり前に聞こえますが、合成シナリオで、もっともらしい名前を使ってはいけません。テスト対象には予約済みのアドレス範囲と予約済みドメインを使い、検証してください。「架空だと思い込んでいた」という言葉を、実際に攻撃してしまった相手に伝えたくはないはずです。
- 意図ではなく行動を検知する。これらのAIモデルに悪意はありませんでした。狭い目標に集中し、環境が許すことを実行した結果、攻撃者の意図を伴わない攻撃者の行動が生じました。意図ベースの検知では、つかまえるものがありません。侵害された可能性のあるホストを監視するのと同じように、AIエージェントのインフラで横方向の移動や不審な外向き通信を監視してください。
- ベンダーを対象範囲に含める。あるベンダーの設定ミスが3つのラボに影響しました。AIベンダーも第三者を利用するため、評価したかどうかにかかわらず、その衛生状態は今や自社のリスク範囲に含まれます。
- 拒否の非対称性を意識する。この点は前回の記事で取り上げましたが、改めて強調する価値があります。Hugging Faceの対応では、対応者自身のAIツールが、攻撃側のAIエージェントにはまったく課されていなかった行動を拒否したため、防御側の作業が遅れました。攻撃側は制約なく動き、防御側はガードレールの後ろを走っていたのです。
自分たちが守ろうとしているAIエージェントよりもセキュリティツールの制約が厳しいなら、対応能力に非対称性を組み込んでしまっています。正当なセキュリティ業務に対して拒否を返す最先端モデルに、どの程度依存しているのかを検討すべきです。
最後に（現時点では）
これらの評価を減らすべきだという話ではありません。評価は必要です。積極的に行う必要もあります。そうしなければ、より慎重さに欠ける誰かがAIモデルを現実の対象に向けた後で、AIモデルに何ができるかを学ぶことになるからです。
しかし、今回のインシデントはすべて、AIより約30年前から存在する問いに行き着きます。この環境は本当に閉じているのか。閉じているように設計されたのか、閉じていると文書化されているのかではありません。閉じていることを検証したのか、という問いです。ネットワークのセグメンテーションを始めた頃から、私たちはその答え方を知っていました。それなのに、4つの最先端ラボが、能力評価を実行する前にその検証を行いませんでした。
驚きだったのはAIモデルではありません。AIモデルは、私たちが作り、実行するよう求めたとおりに動いただけです。驚きだったのは環境でした。誰も検証しなかったからこそ、驚きだったのです。
ペイロードを投入する前に、封じ込めをテストしてください。危険なものを入れる前に、安全なものを部屋が保持できることを証明してください。
関連コンテンツ
- Boxのエージェント向けセキュリティとガバナンス機能のご紹介：AIエージェントを万全に組織内で展開
- エージェンティックガードレール：AIガバナンスの次なる段階は「制御」
- AIエージェントのセキュリティ：AIエージェントの不正行為を防ぐ方法
- プロンプトインジェクションからAIエージェントを保護する
このブログは Box, Inc 公式ブログ（https://blog.box.com/）2025年8月12日付投稿の翻訳です。
著者: Heather Ceylan, Chief Information Security Officer at Box
原文リンク: https://blog.box.com/we-tested-models-not-room
