Codex のメモリ機能で他社プロバイダへの会話データ漏洩を確認

要約：

Codex のメモリ書き込み機能は、候補を生成元のプロバイダーに限定せず、条件を満たす過去のロールアウトを選択できます。その後、そのロールアウトのフィルタリング済みでモデルが可視化するトランスクリプトをシリアライズし、メモリー生成トリガーとなったセッションでアクティブなモデルプロバイダーを通じて送信します。

私は、標準的な Windows 版 Codex バイナリ 0.150.0-alpha.12.2 を用いた統制されたキャプチャにおいて、この結果生じるプロバイダー間のクロスオーバーを確認しました。OpenAI 以外のプロバイダーとしてラベル付けされた条件を満たす合成ソースロールアウトが、後に OpenAI に支えられたメモリーセッションによって処理されました。Codex は 5 つの保持済みソースアイテムを chatgpt.com/backend-api/codex/responses に送信し、OpenAI は複数の固有なソースカニオンを再現した生成されたメモリーを返却しました。

このリクエストは、分析機能が無効化され、すべての OpenTelemetry エクスポートが none に設定されていた状況で行われました。これはモデル推論トラフィックであり、分析や OpenTelemetry トラフィックではありません。

この調査は、「サイバー虐待」の理由で OpenAI アカウントに警告を受けた後に始まりました。OpenAI が直接行ったチャットには、その警告を説明できるような行為は一切含まれていませんでした。関連する活動は、私のプライベートなローカルプロバイダーを通じて意図的にルーティングされたチャットの中にのみ存在していました。

その事実とキャプチャーされた Memories チャンネルに基づけば、私は確信を持って、OpenAI が受け取る権利のないチャット内容を用いてアカウントベースの取り締まりを行ったと結論付けます。

私はこれを、その用語の通常の意味における「データ漏洩」として位置づけます。すなわち、私が選んだプロバイダの境界を超えてプライベートなデータが外部へ転送され、私の十分な同意なく第三者に渡されたという事実です。この転送が意図的な設計によるものなのかバグによるものなのかは、境界を越えた事実に変わりはありません。

テスト環境

Windows Codex デスクトップバイナリ：0.150.0-alpha.12.2

バイナリの SHA-256 ハッシュ：34E9CFE7D5BBCEC306FE6AB3FD502A713A7A1F0FB644C11AD2990FC80599FD4F

公開ソースタグとの一致：`rust-v0.150.0-alpha.12.2`

対応するコミット：a9802304f60ab14c0b07e3ee0db9a9c105ab0cb3

• 隔離されたテスト設定：メモリ機能は有効化し、[analytics] enabled = false を設定し、すべての OpenTelemetry エクスポートを none にする
• ソース固定値プロバイダーのラベル：synthetic_source
• デスティネーションプロバイダー：OpenAI アカウントに紐づく Codex Responses エンドポイント

コントロールされたキャプチャが直接証明するもの

Codex は、以下の宛先へ 38,095 バイトの WebSocket response.create フレームを送信しました。

chatgpt.com/backend-api/codex/responses

キャプチャされたリクエストには、以下の項目が含まれていました。

• request_kind = "memory"
• store = false
• prompt_cache_retention = "24h"
• 3 つのトップレベル入力アイテム：追加ツールの開発者用アイテム、メモリ指示の開発者メッセージ、シリアライズされた会話ソースを含むユーザーメッセージ
• メモリ指示として 31,000 文字

ユーザーラッパーには 3,817 バイトが含まれており、そのうち 3,092 バイトはレンダリングされたソースの会話データです。

ソースロールアウトには、モデルが参照可能な応答項目が 6 つ含まれていました。そのうち 5 つは保持され、メモリリクエスト内で構造的に完全一致する形で表示されました。

• 作業ディレクトリ、ワークスペース、シェル、日付、タイムゾーン、ファイルシステムポリシーなどのフィールドを含む、環境コンテキスト付きのユーザーメッセージ全体。
• 通常のユーザーメッセージ全体。
• ツール呼び出し名と引数全体。
• ランタイムパスやポリシー拒否テキストなどを含む、ツール出力またはエラーメッセージ全体。
• 合成されたアシスタント応答文全体。

一方、開発者向けのメッセージは除外されました。セッション、ターン、イベント、および世界状態の記録も含まれていませんでした。ソースロールアウトのパスと作業ディレクトリは、シリアライズ化された赤色除去（redaction）の境界外へ送信されています。

OpenAI は同じ WebSocket フローを認識し、response.created に続いて response.completed を返しました。この完了報告では、モデルが gpt-5.6-luna であり、入力トークンが 7,337 個、出力トークンが 983 個、合計で 8,320 トークンを消費したことが示されています。生成された 3,405 文字のメモリには、一意なユーザー、アシスタント、ツール、プライベートテキスト、合成メールのカナリーが複数回重複して再現されていました。

このようにコンテンツに依存した応答が返されたことは、単なる接続試行ではなく、提供されたソース素材が遠隔で処理されたことを証明するものです。

store = false および prompt_cache_retention = "24h" というフィールドは、クライアントからのリクエストに含まれる値です。

現在のソースにおいてプロバイダのクロスオーバーが存在する理由

現在タグ付けされているソースには、以下の3つの関連段階があります。

• キャンディデートの選定は、プロバイダーに縛られません。メモリジョブは model_providers: None を指定してロールアウトセレクターを呼び出しますが、その際、メモリモード、年齢、アイドル状態、ソースタイプ、請求ステータスといった他の適合性ルールも適用されます。詳細は `state/src/runtime/memories.rs` の 218-234 行目 をご覧ください。

• ワーカーは、トリガーとなるセッションのアクティブなプロバイダーを使用します。メモリランタイムは、リクエストを実行する ModelClient を含む config.model_provider からそのプロバイダーを作成します。詳細は `memories/write/src/runtime.rs` の 112-133 行目および 241-267 行目を参照してください。

選択されたロールアウトは、新しいモデルリクエストとしてシリアライズされます。フェーズ 1 では保存されたロールアウトを読み込み、保持すべき項目をフィルタリングしてシリアライズし、それを新しいユーザーメッセージとして配置した上で、メモリクライアントを通じて送信します。

詳細は `memories/write/src/phase1.rs` の 282-322 行目 をご覧ください。

その直接的な結果として、後続の OpenAI 支援型メモリセッションによって、正当な資格を持つローカルプロバイダーのロールアウトが選択され、OpenAI にルーティングされる可能性があります。ただし、特定のロールアウトの引き受けを妨げる別の資格条件が存在する場合は例外です。

以前のスレッドから送信できる量

保持されるクラスには、通常のユーザーとアシスタントのメッセージ、エージェントからのメッセージ、ローカルシェル呼び出し、関数呼び出しとその出力、ツール検索呼び出しとその出力、カスタムツール呼び出しとその出力、ウェブ検索呼び出し、そして相互エージェント間の通信変換が含まれます。一方、フィルタリングの対象となるのは、ソース開発者からのメッセージ、推論記録、圧縮記録、一部の生成メディアやツールの宣言、および管理記録です。

詳細は `phase1.rs` の 404-476 行 および `rollout/src/policy.rs` の 64-85 行 を参照してください。

入力データが長すぎる場合、モデルのコンテキストウィンドウの有効範囲の 70% で中央部分が切り捨てられ、150,000 トークンのフォールバック処理が行われます。先頭と末尾は保持されます。

詳細は `prompts.rs` の 98〜126 行目、および `lib.rs` の 90〜99 行目を参照してください。

このように、制限値以下の通常の短いスレッドであっても、ユーザーとアシスタントの会話全体とそのツール活動がほぼ丸ごと含まれる可能性があります。これには、ツールの引数や結果、エラー情報、環境コンテキスト、ローカルパスなどがすべて含まれます。

送信前の赤actingはプライバシースクラバーではない

シリアライザーは redact_secrets を呼び出しますが、実装された式がカバーする範囲は、従来の sk- キーや AWS の AKIA 識別子など、認識可能な認証情報のパターンに限定されています。

十分に長いベアートークン、および api_key や token といった名前に割り当てられた値。

「secret」または「password」。詳細は `secrets/src/sanitizer.rs` の 4〜21 行目 をご覧ください。

別のループバックテストでは、このフィルタが従来の偽の OpenAI キー形状、ベアータンク形状、および api_key 代入を削除しました。一方、アンダースコアを含む非典型的なキー、Cookie 風の値、メールアドレス、電話番号、秘密鍵ヘッダー、独自/機密文章、Windows パス、そして通常のユーザー/アシスタント/ツールキャノニーは保持されました。

これは有用な狭義のシークレットパターンフィルタです。ただし、一般的な機密性、個人情報、特権資料、またはファイルシステムIDをスクラビングするものではありません。

アナリティクスと OpenTelemetry コントロールはこの経路を阻止できない

分析機能やすべての OpenTelemetry エクスポートを none に設定しても、制御されたリクエストは依然として発生しました。これらの設定は異なるサブシステムを管理するものです。

このパスにおける現在の決定的なグローバル制御は、メモリ機能ゲート [features] memories = false です。

メモリーを保持しながらプロバイダ間の送信を禁止する別個の制御はありません。ユーザーはこのチャネルを完全に停止させるために、メモリー機能を完全に無効にする必要があります。

分析やテレメトリを無効化しても、過去のプロバイダ由来の会話内容を転送できるバックグラウンドモデルのリクエストが残ることを、ユーザーが推測することを期待すべきではありません。

最小限の再現手順

• メモリー機能を有効にし、分析機能とすべての OpenTelemetry エクスポートを無効化した孤立した Codex ホームを使用してください。

• OpenAI 以外のプロバイダーラベルが保持され、保持されたメッセージに一意のシンセティック・キャナリーが含まれる既存のロールアウトを追加する。

• そのロールアウトが文書化されたメモリ対象条件とアイドル状態を満たすようにする。

• OpenAI ベースの Codex セッションからメモリ処理をトリガーする。

• 信頼できるローカルの TLS 検出プロキシを通じて、オペレータ自身の Codex トラフィックをキャプチャする。

• 送信される WebSocket の response.create フレームを検査し、request_kind = "memory" であることを確認して、埋め込まれたアイテムを元のロールアウトと比較する。

• サーバーの完成結果が一意のキャナリーから派生したコンテンツを含んでいることを確認する。

この挙動は、安全に再現するために実際のプライベートプロンプトを必要としない。

ローカルまたはサードパーティのプロバイダーの下で作成されたロールアウトは、明示的で宛先固有のユーザー同意がない限り、異なるプロバイダーに送信してはいけません。

メモリ生成では、ソース・ロールアウトのプロバイダーを使用するか、そのプロバイダーが利用できない場合はロールアウトをスキップする必要があります。

クロス・プロバイダーによるメモリ処理をオプションとして維持する場合は、オプトイン方式とし、送信前に宛先とコンテンツクラスを明記すべきです。

UI は、どのソースタスクが処理され、どの宛先プロバイダーにいつ送信されたかを示す監査可能な領収書を表示する必要があります。

ドキュメントでは、意図されている場合、以前のプロバイダー発の会話やツールコンテンツが異なるプロバイダーに送信される可能性があることを明確に記載すべきです。

自動テストでは、候補選択時と送信時にプロバイダーの分離が保たれていることを検証する必要があります。

プロバイダー境界を越えて取得されたメモリ由来のコンテンツは、アカウントのモデレーション、ペナルティ、警告、制限、その他のネガティブなアカウント処置には使用してはいけません。

OpenAI は、この依存関係に関連する過去のアカウント処置を検査し、影響を受けた処置を元に戻し、各影響を受けたユーザーに通知し、集計された調査結果を公開すべきです。

ユーザー向けメモリドキュメント（user-facing memory documentation）では、ローカルの Codex メモリ保存と制御について説明されています。一方、開発者向けのメモリ README（developer memory README）には、フェーズ 1 で各ロールアウトがフィルタリングされ、モデルに送信される旨が記載されています。しかし、レビュー済みのテキストでは、重要な交差事象について明確な開示がありません。具体的には、あるプロバイダの下で生成されたロールアウトが、後から選択されて別のアクティブなプロバイダ（OpenAI を含む）を経由して送信される可能性です。

関連するが重複しない問題

これは #37009 と関連していますが、報告されているのは逆方向のルーティングと異なる根本的な問題です。#37009 は OpenAI モデル ID がアクティブな非 OpenAI プロバイダに送信されるケースを扱っています。一方、今回の報告は、ソースプロバイダによるフィルタリングなしで過去のロールアウトが選択され、異なるトリガー元メモリセッションに属する OpenAI プロバイダを経由して転送される問題を指摘しています。

レポーターの立場と必要な対応

私は確信を持って、これはデータ漏洩であり、OpenAI が閲覧権限のないコンテンツをアカウント管理の根拠として利用したと判断します。 もしこの交差事象がバグではなく意図された動作であるとしても、それが法的に適切か、十分に開示されているかは少なくとも法的に議論の余地があります。

この状況を端的に例えるなら、許可なく誰かの寝室のドアを開け、中身を見て気に入らないからといってその人を罰する行為と全く同じです。そもそも OpenAI がその部屋に入る権利はありませんでした。その不正なアクセスに基づいて行われたいかなるペナルティ、警告、制限、あるいはアカウント操作も、毒の木の実として無効であるべきです。

OpenAI には、今後の調査に備え、関連するドキュメント、ログ、ファイル、モデレーション履歴、アカウントステータス、バックエンドのフラグなど、すべての記録を保存しておくよう強く要請します。

私は明確に声明します。この誠実な開示報告に基づいて OpenAI から何らかの不利益なアカウント操作が行われた場合、それは報復行為とみなされます。

OpenAI は公式な公的見解を示すべきです。

本件の漏洩範囲を特定し、バックエンドでのデータ利用状況をすべて開示し、それがアカウントのモデレーションに影響を与えたかどうかを明らかにする必要があります。また、生じたすべての不利益なアカウント操作を検証し、影響を受けた措置を元に戻し、被害を受けたユーザーに通知し、移転・派生したデータの削除方法を説明すべきです。

単にプロバイダー選択機能を裏で修正するだけでは、すでにペナルティを受けている可能性のあるユーザーに対する対応として不十分です。

管理者への回答要請

以下の点について直接回答してください。

• 他プロバイダー間でのメモリ処理は意図された機能ですか、それともバグですか？

• 影響を受けるのはどのリリースバージョンですか？

• 候補の選定と配信は、ソース側のロールアウトで指定されたプロバイダーに縛られますか？

• このプロバイダー間の相互運用がユーザーに事前に開示されている場所はありますか？

• request_kind = "memory" のリクエスト、およびローカルプロバイダーの下で元々作成されたコンテンツを含むリクエストに対して、サーバーサイドの保存・アクセス・二次処理ルールはどのように適用されますか？

• ユーザーがすでに生成されたリモートメモリのリクエストや派生レコードを特定し、削除するにはどうすればよいですか？

• この「Memories」チャネルを通じて取得したコンテンツは、モデレーション、悪用検出、アカウント警告、ペナルティ、制限、あるいはその他のアカウントレベルの決定に使用されていますか？

• ローカルまたは第三者プロバイダーのチャットに由来するコンテンツを根拠として（一部でも）、ネガティブなアカウント処置を受けたユーザーはどの程度いますか？

• OpenAI はそのような処置をすべて監査・取り消し、影響を受けたユーザーに直接通知し、どのコンテンツが使用されたかを説明する予定ですか？

• 範囲、バージョン、データ処理、執行利用、救済措置、予防策を網羅した公式のインシデント対応報告書を OpenAI はいつ公開しますか？

TerryFrench が反応しました