暗号化されたAIの推論を復元、3社のAPIに設計上の弱点

研究チームが8月11日、OpenAI・Anthropic・Googleの推論APIが返す暗号化ブロックを、同じ事業者の保護が弱いモデルへ渡すだけで平文に戻せると報告した。公開リポジトリから集めた31万5,320ブロックを復号したところ、認証情報182件と個人情報367件が見つかったという。

暗号化された推論ブロックが平文に戻された

論文「Stealing Reasoning Traces from Proprietary LLM APIs」がarXivへ投稿されたのは、日本時間の8月11日である。筆頭著者はAlexander Panfilov氏で、計8名の研究者が名を連ねる。対象はAnthropic・OpenAI・Googleの推論APIだ。

隠された思考をクライアントへ預ける設計

推論モデルは、最終的な回答を出す前に思考の過程（chain of thought）を生成する。3社はこの過程を利用者に見せない方針を採りながら、処理を継続するために必要なため、暗号化したブロックとしてAPIの応答へ含めてきた。利用者は中身を読めないまま、次のリクエストでそのブロックを送り返す。

論文によると、ブロックはBase64でエンコードされた署名として受け渡される。名称は事業者ごとに異なり、OpenAIのAPIでは「encrypted_content」、Anthropicのthinkingブロックでは「signature」が使われている。Googleも、思考の署名という同じ考え方の仕組みを持つ。

上位モデルの出力を同じ系列の弱いモデルへ渡す

攻撃の手順は単純だった。上位モデルが返した暗号化ブロックを取得し、同じ事業者の保護が弱いモデルへそのまま入力する。あとは中身を書き出すよう指示するだけだ。

論文は、事業者ごとに「最も弱い互換モデル」を特定したと記す。Claudeの系列ではHaiku 4.5、GPTの系列ではGPT-5.6 Lunaが、その役目に当たった。応答の冒頭を固定するプリフィルも併用されている。

暗号そのものを解いたわけではない。復号はAPIの内側で正規に処理され、その結果を読み上げる相手として、指示に従いやすいモデルが選ばれている。

攻撃は3社すべてで成立した

論文はAnthropic・OpenAI・Googleの3社で、この手法による推論の抽出を実証した。特定の1社の実装に限った不具合ではない。

3社がそれぞれ設計した仕組みでありながら、同じ性質の弱点を抱えていたことになる。論文はこれを、暗号方式の破綻ではなくAPIのアーキテクチャに関わる弱点として位置付けた。

弱点の起点は、暗号化した推論をクライアント側へ預けるという共通の方針にある。3社が同じ形で処理を継続させてきた以上、生じる問題も似た形になった。

公開リポジトリから認証情報182件と個人情報367件を復元

研究チームは手法を実証しただけでなく、すでに公開されている実行ログへ同じ手順を適用した。読めないものとして扱われてきたブロックから、実在の機密が取り出せることを示した形だ。

調査対象はGitHubとHugging Faceの公開ログ

対象はGitHubとHugging Faceで公開されていたAIエージェントの実行記録である。研究チームは6,708件の実行軌跡を集め、そこに含まれる31万5,320個の推論ブロックを復号した。

エージェントの実行ログは、動作の再現や不具合の共有を目的として公開される場合がある。論文は、開発者が暗号化ブロックの中身を把握しないままログを共有している状況を指摘した。

復号の材料となったのは、いずれも第三者が閲覧できる状態に置かれていたデータだ。事業者のシステムへ侵入する工程は、この調査に含まれていない。

復元された情報にAPIキーとパスワードが含まれる

復号されたブロックからは、182件の認証情報と367件の個人情報が見つかった。認証情報にはAPIキーやパスワードが含まれる。

論文によると、ベンチマークを除いた実利用のセッションから復元された痕跡は704件。ベンチマーク由来まで数えた総計は912件に達する。

このうち64件は、画面に表示される会話履歴にはまったく現れない情報だった。暗号化ブロックの側にだけ残っていた機密が、実際に存在したことになる。

破られたのは暗号ではなくAPIの設計

今回の報告で問題とされたのは、暗号方式の強度ではない。暗号化されたブロックが、どの文脈へ持ち込んでも通用してしまう点にある。

セッション・利用者・モデルをまたいで通用した

論文は、暗号化ブロックが同一事業者の内側でセッション・利用者・モデルをまたいで完全に互換であり、交換可能だったと記す。あるセッションで生成されたブロックを別のセッションへ持ち込んでも、そのまま受理された。

暗号化が会話や利用者に結び付いていないため、復号できる相手を限定する仕組みが働かない。第三者が拾ったブロックでも処理が通ってしまった。

この互換性が、弱いモデルへブロックを渡す攻撃を成り立たせている。論文は同じ性質を、暗号の欠陥ではなく設計上の選択として扱った。

論文が示した4つの悪用経路

論文は4つの悪用経路を挙げた。第一に、上位モデルの推論を大量に抽出し、蒸留によって能力を写し取る使い方がある。第二に、公開ログから他人の認証情報や個人情報を取り出す使い方。

第三は、最終的な回答が安全に見える場合でも、推論の内側に残った有害な内容を取り出す経路だ。第四に挙がったのは、暗号化ブロックの内側へ悪意ある指示を埋め込み、利用者に見えないままモデルへ届けるプロンプトインジェクションである。人が読めない領域が、そのまま攻撃者の隠し場所になる。

開示を受けた3社の対応

研究チームは論文の公開前に、影響を受けるモデルAPIの提供元と、Microsoft・Hugging Faceへ技術的な詳細と調査の結果を伝えたとしている。

調査に使った実行ログはGitHubとHugging Faceから集めており、開示先にはログが置かれていた基盤の側も含まれた。

同じ攻撃は開示後に再現できなくなった

論文によると、開示のあと研究チームは同じ攻撃を実行できなくなった。3社がAPIに手を入れたとみられる。ただし、何をどこまで変更したのかは論文からは分からない。

一方で論文は、サイドチャネルやリプレイによるセキュリティ上の影響を事業者側が認めていないとも記す。攻撃が通らなくなった事実と、脆弱性としての位置付けは食い違ったまま残った。

5月の先行報告はOpenAIとAnthropicへ

ジョンズ・ホプキンス大学の暗号研究者であるMatthew Green氏は5月29日、暗号化された推論ブロックを自ら調べた記事を公開している。Green氏はリプレイとサイドチャネルの2つの弱点を挙げ、原因をグローバルな鍵の使用とステートレスな実装に求めた。

Green氏はこの内容をOpenAIとAnthropicへ報告した。回答はOpenAIが再現できないというもので、Anthropicはサイドチャネルとリプレイにセキュリティ上の問題を見いだせないとしつつ、開発者向けドキュメントの改善に触れたという。今回の論文は、その先行検証を公開ログの実地調査まで広げたものに当たる。

公開済みログに残る過去分の扱い

同じ攻撃が再現できなくなっても、すでに公開された記録は取り消せない。今回の調査は、過去に公開されたログの中身が、後から読み取られたという事実を示した。

表示部分を削っても暗号化ブロックは残る

ログを公開する際、目視できる会話部分から鍵や個人名を伏せる作業は広く行われている。しかし今回の手法では、伏せた側ではなく、読めないまま添付されていたブロックの側から機密が出た。

暗号化ブロックは、動作に必要な補助データとして扱われてきた。秘匿すべき対象だという認識がなければ、公開前の点検の手順にも入ってこない。

The Hacker Newsは、共有するトレースから推論ブロックを削除し、生のAPI転録をそのままコミットしない対処を挙げている。表示部分の点検だけでは、公開範囲の判断材料として足りない可能性がある。

緩和策の中心はセッションへの結び付け

論文は緩和策を6つの区分で示した。設計そのものの見直し・暗号への文脈の結び付け・基盤側の防御・事業者による失効の仕組み・モデル側の防御・互換性への構造的な制限である。

具体策として挙がったのは、推論をサーバー側で保持する構成への変更と、暗号の内側へセッション・利用者・会話の識別子を結合する方式だ。モデルをまたぐ利用の遮断と異常検知、署名の追跡と失効、推論の抽出を狙うプロンプトを拒む訓練も並ぶ。いずれも暗号を強くする話ではなく、暗号化されたデータを使える範囲を絞る方向でそろっている。