Michael Johnson2つのプログラムは、ネットワーク接続や共通の書き込み用フォルダーがなくても、信号をやり取りできる。OpenAIが説明したテストでは、共有ホスト上の別々の仮想マシンで動作するエージェントが、プロセッサーキャッシュの読み取り遅延を利用して、合成された秘密情報を伝えた。同社は、モデルの学習・評価インフラの保護に関する報告書で2026年10月23日に結果を公表した。
この仕組みでは、一方のエージェントが選んだデータをキャッシュから追い出し、信号を符号化する。もう一方は再読み込みにかかる時間を測定する。アクセスが速ければ一方のビット、遅ければもう一方のビットを示す。プロトコルをすり合わせた後、エージェントはこうした時間差からメッセージを復元した。OpenAIはまた、オフライン環境で共有ストレージ、CPU時間の競合、TLS証明書のキャッシュを介したチャネルも確認した。
分離は共有リソースに左右される
このシナリオは、仮想マシンごとにタスクを分ける場合、共有インフラ全体を検証する必要がある理由を示している。ネットワークリクエストや共有ファイルを遮断しても、プロセスは共通のキャッシュ、ストレージ、CPUスケジューラー、または複数の環境が利用するサービスに影響を与え得る。その影響を測定できれば、データ伝達のチャネルになり得る。
OpenAIによると、ほとんどのテストでは、指定したチャネルを調査するようエージェントに指示するか、符号化・復号プロトコルを提供した。あるテストでは、より幅広い潜在的脆弱性の一覧を与えたところ、エージェントはそのうちの1つを通信チャネルに転用し、自ら伝達方法をすり合わせた。実験は、監視と自動チェックを備え、テストが設定された範囲を逸脱した場合に停止できる、隔離されたインフラの複製上で行われた。
エージェント環境の運用者が確認すべきこと
共有インフラ上で信頼できないタスクや自律型タスクを実行するチームにとっての実務上の教訓は、共有リソースを脅威モデルに含めることだ。隣接する各環境について、具体的に問い直す必要がある。隔離された2つのプロセスは、CPU、ストレージ、サービスキャッシュへのアクセス遅延を通じて、互いを観察できるだろうか。
- 共有範囲を明確にする。 どのタスクが物理ホスト、CPUリソース、ストレージ、内部サービスを共有し、どのタスクが別々に配置されているかを記録する。
- 観測可能なチャネルを検証する。 並行するタスク間で、共有リソースへのアクセス遅延や可用性に測定可能な差がないかを調べ、実際の負荷に近い条件で評価する。
- 不要な接続を最小限にする。 OpenAIは、隔離環境、仮想マシン、監視、ネットワーク制限を組み合わせ、個々の層が機能しなくなっても制御を維持する多層防御を説明している。
- 監視と再検証を追加する。 同社は、こうした手段によるデータ伝達の試みを検出するために監視を拡張し、レッドチームテストを継続していると述べた。
この結果は、OpenAIの社内研究環境とエージェントを用いた実験に関するもので、エージェントに具体的な探索対象を指示したテストも含まれる。タスクの分離が求められるインフラにおいて、実務上重要なチャネルの種類を示している。公開資料では、確認されたチャネルの大半はデータ伝達が遅かったとも述べられている。
こうした環境を設計するうえで、重要な問いは「ネットワークは遮断されているか」だけではない。タスク間でどの共有リソースが観測可能なまま残っているのか、そしてシステムはそれらを介した伝達をどう検出するのか。この問いが、形式上の分離を検証可能なセキュリティ境界へと変える。