テクニカル・サマリー：ゴースト・ツールコール：投機的エージェント・ツールにおける発行時のプライバシー

1. 問題提起

ツール拡張型言語エージェントは、レイテンシを削減するために**投機的実行（speculative execution）**をますます採用しています。このパラダイムでは、エージェントのランタイムが将来起こりうる可能性の高いツールコールを予測し、プランナーがどの実行ブランチを確定（コミット）させるかを決定している間に、それらを並列にディスパッチします。これはパフォーマンスを向上させますが、著者らが「ゴースト・ツールコール（Ghost Tool Calls）」と呼ぶ、新たなプライバシーの失敗モードを引き起こします。

ゴースト・ツールコールとは、放棄された投機的な呼び出しのことであり、外部の観測者（例：検索プロバイダー、APIエンドポイント、またはネットワークモニター）にディスパッチされたものの、エージェントの最終的な確定プランには昇格されなかったものを指します。これらのコールは、エージェントが特定のワークフローへのコミットを行う前に発行されるため、推論されたユーザーの意図（トピック、エンティティ、および潜在的なフォローアップアクション）を外部サービスに漏洩させてしまいます。

核心となる問題は**時間的（temporal）**なものです。外部の観測者が投機的なコールを受信した時点で、情報はプロバイダーのログ、キャッシュ、またはネットワークトレースに保持されます。標準的なプライバシーメカニズムは、以下の理由により対処できません。

• コミット時のクリーンアップは、観測者がすでにデータを保持しているため効果がありません。
• 読み取り専用制限（例：投機的実行を読み取り専用ツールのみに限定する）は、引数やデスティネーション（送信先）エンドポイントを通じて意図が漏洩することを防げません。
• アクセス制御のホワイトリストは、ツールが許可されていれば、そのブランチが後に放棄されるかどうかにかかわらず、コールを許可してしまいます。

著者らは、投機的エージェントのプライバシーには、コミット時の決定ではなく、コールが信頼されたランタイム境界を離れる前に行われる**発行時（issue-time）**のポリシー決定が必要であると主張しています。

2. メソドロジーとフレームワーク

トレースモデル

著者らは、以下の2つのシーケンスを比較するトレースモデルを用いて、プライバシーのギャップを定式化しています。

• 発行されたトレース ($S$): すべてのディスパッチされたツールイベント（投機的なものを含む）の順序付けられたログ。
• 確定されたトレース ($C$): エージェントが最終的に使用するイベントの順序付けられた部分集合。
• ゴースト・コール: $S \setminus C$ に含まれるイベント。
• 限界露出量 ($\Delta_i$): 観測者 $i$ が見る投機的トレース $O_i(S)$ と、確定のみを想定した反事実的な $O_i(C)$ との差。これは、投機によってのみ漏洩する追加情報の量を表します。

このモデルは、3つの開示チャネルを特定しています。

1. 引数（Arguments）: 文字通りのペイロード（例：検索クエリ）。
2. デスティネーション（Destination）: アクセスされたエンドポイントまたはコレクション（例：HR休暇管理API vs 一般的な検索）。
3. メタデータ（Metadata）: タイミング、順序、リトライ回数、およびキャッシュの状態。

投機的ツール・プライバシー契約

発行時の境界でプライバシーを強制するために、本論文は**投機的ツール・プライバシー契約（Speculative Tool Privacy Contracts）**を提案しています。これは、「コミット前の観測」を、状態の変異（state mutation）とは異なる第一級の効果として扱うランタイム抽象化です。

主要構成要素:

• ラベル（Labels）: 各投機的イベントは、実行モード、効果クラス、観測者クラス、引数の感度、デスティネーションの感度、およびブランチの確信度と共にラベル付けされます。
• モニター（The Monitor）: プランナーと外部I/Oパスの間に位置する信頼されたコンポーネント。すべての投機的イベントをディスパッチ前に評価します。
• 決定関数（Decision Function）: モニターは、イベントを以下の5つのアクションのいずれかにマッピングします。
  1. ALLOW（許可）: 変更なしでディスパッチ。
  2. REWRITE（書き換え）: ディスパッチ前に、機密性の高い引数を一般的な同等物に変換。
  3. SHADOW（シャドウ）: 外部コールではなく、信頼できるローカルの代替品を実行。ブランチが昇格された場合に結果が使用されるが、外部の観測者は元のリクエストを見ることができない。
  4. DEFER（保留）: ブランチが確定プランに昇格された場合にのみ、再評価のためにイベントをキューイング。
  5. BLOCK（遮断）: イベントを完全に破棄。

健全性の不変条件（Soundness Invariant）: 完全な媒介（complete mediation：モニターより前に生のデータが漏れないこと）および正しいラベル付けを前提として、モニターは、イベントが後にコミットされるか放棄されるかにかかわらず、禁止されたフィールドが観測者の限界露出量 ($\Delta_i$) に入ることを防ぎます。

3. 主な貢献

1. ゴースト・ツールコール概念: 放棄された投機的な呼び出しを、コミット時の状態変異とは異なる「発行時の開示」という独自のプライバシー脅威として定式化したこと。
2. 投機的ツール・プライバシー契約: ラベル、5つのアクション・パイプライン、および「観測前の効果」を扱う健全性の不変条件を備えた、具体的なランタイム抽象化。
3. 実証的評価: 3つの生成コーパス（30タスクの静的、150タスクのペア、および66タスクのAgentDojo）と、実際のプロバイダー研究（Brave Search/DuckDuckGo）を用いた包括的な評価。評価には、隠された機密ラベルの復元率を測定するために、複数の敵対モデル（LLM、キーワードマッチング、TF-IDF）を使用しています。

4. 結果

評価では、敵対的復元（adversarial recovery）（敵対者が観測者の投影から機密ラベルを正しく推論できる確率）とタスク成功率に基づいてポリシーを比較しています。

• 漏洩の確認: 投機的トレースは漏洩を大幅に増加させます。静的なプラン・ベンチマークにおいて、復元率は、投機なしの0.44から、ナイーブな投機（Naive speculation）では0.97へと跳ね上がりました。
• 事後制御の無効性: ディスパッチ後に作用する、あるいは読み取り専用の制限に依存するポリシーは、漏洩を減らすことができませんでした。
  • Late-Scrub、ACL、およびSIA（Speculative Interaction Agents）: これらのポリシーは、限界露出量をそのまま残してしまいます。読み取り専用ツールに投機を制限するSIAは、読み取り専用コールであっても引数やデスティネーションを通じて意図が漏れるため、ナイーブなベースラインと同程度の性能しか示しませんでした。
  • Pre-Scrub: ディスパッチ前の自由記述テキストによる引数のスクラビング（除去）は、構造化されたフィールドやデスティネーションが未処理のままであれば、不十分です。
• 発行時変換の有効性: ディスパッチ前に投影を変換するポリシーのみが、漏洩を減少させました。
  • Rewrite（書き換え）: 機密性の高い引数を一般的な同等物に言い換えることで、復元率をほぼ底値（例：実在のプランナー・シナリオで0.04）まで下げました。
  • Shadow（シャドウ）: ローカルの代替品にルーティングすることで、いくつかのベンチマークで復元率を0.00に抑えました。
  • Gate（ゲート）: 低確信度のコールをブランチ昇格まで保留することで、漏洩を減少させましたが、閾値が厳しすぎるとユーティリティとのトレードオフが生じます。
• 残留シグナル: 漏洩の主な担い手は、構造化された引数フィールドとデスティネーションURLです。ツール名をマスクしたり、自由記述のテキスト除去を行ったりしても、デスティネーションや構造化された引数がトピックを明らかにしている場合、漏洩を止めることはできません。
• ユーティリティ vs. プライバシー: ほとんどのポリシーにおいて、タスク成功率は高い水準（0.77–0.83）を維持しました。ShadowおよびRewriteは、タスクの有用性に影響を与えることなく、ほぼゼロの漏洩を実現しましたが、事後のフィルタリングはプライバシーの利益を全く提供しませんでした。
• レイテンシ: 契約の強制メカニメント自体がレイテンシのボトルネックになることはありませんでした。マルチツールの非同期ワークロードにおいて、プライバシー保護ポリシー（Rewrite、Gate）は、ナイーブなベースラインと同等のレイテンシ上の利点を維持しました。

5. 意義と主張

本論文は、投機は「発行時のプライバシー失敗」を生み出すものであり、従来の認可やコミット時のクリーンアップでは解決できないと主張しています。本研究の意義は以下の点にあります。

• プライバシー境界のシフト: プライバシーの決定ポイントを「エージェントがコミットする時」から「エージェントが発行する時」へと移動させたことです。著者らは、一度観測者が投機的なコールを保持してしまうと、被害は完了しているため、ランタイムは送信する「前」に何を送信するかを決定しなければならないと主張しています。
• 「安全な」投機の再定義: 投機を「読み取り専用」ツールに制限すること（一般的な安全性パターン）は、プライバシーの観点からは不十分であることを示しました。読み取り専用コールであっても、意図を漏洩させるからです。真のプライバシーには、観測可能な投影を変換または抑制する必要があります。
• 実用的な抽象化: 提案された契約（Rewrite, Shadow, Defer）は、ランタイムシステムが、タスクの有用性を犠牲にすることなく、投機によるレイテンシのメリットとプライバシー要件のバランスを取るための、具体的かつ実装可能なフレームワークを提供します。

著者らは、投機はパフォーマンス面で魅力的ですが、ユーザーの推論された意図の漏洩を防ぐために、投機的なコールの引数またはデスティネーションの投影を能動的に変更または抑制する発行時ポリシーが必要であると結論付けています。