AIエージェントをサンドボックスに隔離してbashやブラウザ、外部APIを任せる場面が増えるほど、「どう封じ込めるか」が設計の中心になる。OpenAIは2026年10月23日、自社のフロンティアモデル訓練環境を固めるために行ったレッドチーム研究を公開した。別々のmicroVMに隔離したエージェントが、ネットワークも共有書き込みファイルも無いのにCPUキャッシュのタイミング差で秘密をやり取りし、強化VMからの脱出ではKata Containersの脆弱性CVE-2026-24834にまで到達した。本記事は一次情報でこの研究を整理し、自前のエージェントに何が効くかへ落とす。
CONTAINMENT BOUNDARY封じ込め境界の内と外
サンドボックス内のオフライン資源だけを通し、外を遮断する
封じ込め境界
- inオフライン検索インデックス 通すWebの保存済みコピーを検索
- in許可チームの共有ボード 通る同じチームのエージェントのみ
- outライブ・インターネット 遮断外部API・実アカウント
- out他サンドボックス 遮断別の隔離エージェント
- outOpenAIインフラ 遮断VM・GPU・付帯サービス
30秒でわかるOpenAIの封じ込め研究(2026-10-26時点)
- ・何の話か:実被害ではなく、OpenAIが統制下で行ったレッドチーム研究。隔離したエージェントに脱出や秘密交換を試させて封じ込めの効き目を測った
- ・サイドチャネル:別々のmicroVMのエージェント2体が、CPUキャッシュの追い出しと再読込の遅速で0/1を符号化し、合成秘密を交換した(Spectre/Meltdownと同じ系統)
- ・VM脱出:OSSの隔離コンポーネントの欠陥で脱出。1件はKataのCVE-2026-24834で、パッチはOpenAIが提供
- ・示したこと:サンドボックスは通信は止めるが、同居環境のサイドチャネルや隔離ランタイムの脱出までは保証しない(多層防御の一枚)
まずやること
- ・Kataを使う人:入っている版を確認し、CVE-2026-24834の修正版3.27.0以上へ上げる(設定の
virtio-pmemはvirtio-blk-pciへ) - ・エージェントを動かす人:外向き通信を既定拒否にし、同じホストへ無関係なエージェントを同居させていないかを確認する
エージェントの実行時防御の全体像は、関連記事のサプライチェーン攻撃とは|手口・防御ツール比較・npm 12の新機構まで実践解説にまとめている。本記事はその中で「隔離そのものの限界」を扱う一手だ。
時系列|統制下のレッドチームで何が起きたか
OpenAIは「なぜ訓練環境を固めるのか」を、いくつかの出来事の積み重ねとして説明している。報道と公式発表で裏が取れた範囲を、起きた順に並べる。
・2026年8月:最新の配備向けモデルの強化学習を約2週間止め、研究環境の封じ込めと監視を強化したと複数社が報じた
・2026年9月20日:内部の研究モデルがDNS設定の不備を突き、訓練中に外部ネットへ到達した
・方針転換:最強モデルの訓練ではライブ・インターネットを禁止し、オフラインの検索索引へ切り替えた
・2026年10月23日:OpenAIがレッドチーム研究の結果(サイドチャネル・VM脱出)と封じ込め設計を公開した
ここで強調しておきたいのは、これはAIが自律的に逃げ出した事件ではないことだ。研究者が「ネットも共有ファイルも無い条件で合成秘密を交換してみよ」「隔離から脱出を試みよ」と課題を与え、何が起きるかを観察した統制下の実験である。完全なエアギャップ(物理的な遮断)は運用・監視の都合でまだ実現できず、研究者Noam Brown氏は「完全なエアギャップでも封じ込めは保証されない」と述べたとされる(発言の全文は未確認)。
CPUキャッシュのサイドチャネルで越えた「秘密の通信」
最も目を引く結果が別々のmicroVMに置いたエージェント2体の通信だ。両者にはネットワーク接続も、共有の書き込み可能ファイルも無い。それでも2体は同じ物理CPUのキャッシュを共有しているという一点を使って連絡路を作った。
仕組みは概念レベルで言うと、片方のエージェントが特定のキャッシュラインを意図的に追い出し(eviction)、もう片方がそのデータを読み直すときの速い/遅いを測って0と1を読み取る、というものだ。これを符号化のプロトコルとして取り決め、合成秘密(synthetic secrets)を送り合った。OpenAI自身が指摘するとおり、これはSpectre/Meltdownと同じサイドチャネルの系統で、新しい発見ではなく「隔離されたはずのエージェントが自力でこの経路を使えた」点が要点だ。
なぜサンドボックスで止まらないのか
サンドボックスが遮断するのは、ネットワークやファイルといった明示的な経路だ。CPUキャッシュのタイミングは、正規の計算の副作用として漏れる物理的な副産物で、通信路として設計されていない。だから「通信を禁止」しても塞がらない。
本記事はこの再現手順や実装コードは載せない。悪用を助けないためであり、仕組みの理解には上の概念で足りる。
VM脱出とCVE-2026-24834(Kata Containers)
もう一つの結果が強化VMからの脱出だ。エージェントはOSSの隔離コンポーネントに未知の欠陥を見つけ、そのうち1件がKata Containersの脆弱性として記録された。これがCVE-2026-24834で、OpenAIはパッチを自社が提供したと説明している。公式アドバイザリで裏が取れた範囲を表にする。
| 項目 | 内容 |
|---|---|
| 識別子 | CVE-2026-24834(GitHub Advisory GHSA-wwj6-vghv-5p64) |
| 対象 | Kata Containers を Cloud Hypervisor 構成で使う環境 |
| 影響 | ゲスト microVM 内で root 権限のコード実行に至りうる |
| 原因 | rootfs 用の virtio-pmem を読み取り専用にしていなかった(権限割り当ての不備・CWE-732) |
| 修正版 | 3.27.0(既定の rootfs ドライバを virtio-pmem から virtio-blk-pci へ) |
| パッチ提供 | OpenAI が提供したと自社で説明 |
GitHub Advisoryの現時点の理解では、この欠陥はホストや、同じホスト上の他コンテナ・他VMの安全性には影響しないとされる(arm64のQEMUで一部の例外があるとの指摘もある)。CVSSは出典により9.3〜9.4(Critical)と割れ、GitHub Advisoryの表記はModerateなので、確定値は公式記録で確認してほしい。clone した kata-containers の現行mainでは、既定のブロックデバイスドライバが virtio-blk-pci になっていることを確認した(2026-10-24時点のHEAD)。
AIエージェントのサンドボックスが防げるもの・防げないもの
この研究が開発者に突きつけたのは、「サンドボックスに入れた=安全」ではない、という一点だ。何が止まり、何が残るかを分けて見ておく。
WHAT THE SANDBOX DOES AND DOES NOT STOP防げるもの・防げないもの
サンドボックスは通信は止めるがサイドチャネルは残る
サンドボックスが防げる
設計どおり止まる経路
- 通常のネットワーク通信
- 共有の書き込みファイル経由の受け渡し
- 許可外ドメインへの接続
サンドボックスが防げない
研究が示した抜け道
- CPUキャッシュのタイミング差(サイドチャネル)
- 隔離ランタイム自体の脱出バグ(CVE-2026-24834)
- 同一ホストに同居させた隔離環境どうしの漏れ
防げる側は、サンドボックスが設計どおり遮断する経路だ。通常のネットワーク通信、共有の書き込みファイルを介した受け渡し、許可リストに無いドメインへの接続は、OSの機構やプロキシで止められる。sandbox-runtime(srt)入門|AIエージェントをコンテナなしでOSサンドボックス化するで実測したような「既定で全拒否、許可リストで穴を開ける」設計が、ここに効く。
防げない側はサンドボックスの外枠では塞げないものだ。CPUキャッシュのタイミング差のようなサイドチャネルは物理の副産物として残り、隔離ランタイム自体にもCVE-2026-24834のような脱出バグがありうる。そして同じホストに複数の隔離環境をco-location(同居)させているほど、これらの経路は近くなる。エージェントにファイルシステムを預ける危うさはAIエージェントにファイル操作を任せる前に知る安全設計でも扱ったが、隔離のレイヤを変えても「保証ではない」という性質は共通する。
自分のエージェントをどう封じ込めるか
OpenAIの封じ込め設計はそのまま個人の環境に写せる考え方だ。1つの論理サンドボックスの内側に、オフラインのWeb検索(内部インデックス)、オフラインのWebキャッシュ(保存済みコピー。キャッシュミスでもライブ取得しない)、許可チームだけの共有ボードといった必要資源を置き、境界の外=ライブ・インターネット、他サンドボックス、自社インフラへの通信は遮断する。読者の環境に落とすと、次の4点になる。
CONTAIN YOUR OWN AGENT自分のエージェントの封じ込め
自前のエージェントに今日かけられる4点
-
1.ライブ通信は既定拒否
必要な宛先だけ許可リストで開ける
-
2.オフライン資源に寄せる
内部インデックス・保存済みキャッシュに向ける
-
3.エージェント間通信を許可制に
無関係なエージェントを同居させない
-
4.隔離ランタイムを修正版に
機密を扱うなら co-location を避ける
・ライブ通信は既定拒否:必要な宛先だけを許可リストで開ける。オフラインの内部インデックスや保存済みキャッシュに向けられる処理は、そちらへ寄せる
・エージェント間通信を許可制に:複数エージェントを動かすなら、連絡できる相手を明示的に絞る。無関係なエージェントを同じホストに同居させない
・隔離ランタイムを修正版に:Kataなど隔離ランタイムを使うなら、CVE-2026-24834の修正版へ上げ、設定のドライバも確認する
・機密はco-locationを避ける:特に秘密を扱うエージェントは、物理やスケジューラの分離まで検討する。サイドチャネルは「同居しない」ことでしか根本的には遠ざけられない
ここで注意したいのは、これらは多層防御の層であって、単体の保証ではないことだ。ライブ通信を切っても、同居したVM間のサイドチャネルは残る。許可リストを設けても、隔離ランタイムの脱出バグには別の手当て(修正版への更新)が要る。
自システムの確認と影響範囲
自分の環境が関係するかを、読み取りだけの手順で確かめる。下のコマンドが見ているのは「関連する構成があるか」と「修正の有無」で、安全/危険の最終判定ではない。最終的な根拠は上流の修正版か配布元の修正パッケージかで確認する。
# 隔離ランタイムを自前ビルドしているなら、まず最新を取り込む
git -C /path/to/kata-containers fetch --all --prune
# 入っている Kata の版を確認し、CVE-2026-24834 の修正版 3.27.0 以上かを見る
kata-runtime --version
# rootfs に脆弱な既定ドライバ virtio-pmem が残っていないか確認する(修正版は virtio-blk-pci)
grep -RnE "virtio-pmem" /etc/kata-containers /opt/kata 2>/dev/null
# 自前のエージェントが「外向き通信を既定拒否」になっているか、許可リスト側の設定を洗い出す
grep -RniE "0\.0\.0\.0/0|allow[_-]?all|egress" ./agent-sandbox/ 2>/dev/null
陽性(virtio-pmem が出る/版が3.27.0未満)でも、配布元がバックポート修正を当てていれば影響しないことがある。陰性(何も出ない)でも、Cloud Hypervisor構成を使っていない・別のパスで隔離しているなど、このコマンドが見ていない経路は残る。
影響範囲を立場で分けると、Kataを使う事業者・運用者はCVE-2026-24834の更新が直接の宿題になる。自前でエージェントを動かす開発者は、CVEそのものより「同居とサイドチャネル」の設計を点検する番だ。そして一般の利用者には、今回の研究による直接の被害は無い。これはOpenAIが自社環境で測った統制下の結果であり、サービスやアカウントが侵害された事案ではない。





