技術要約：見えないものは見せない：セキュアなText-to-SQLのための認可優先スキーマコンテキスト

1. 問題提起

大規模言語モデル（LLM）ベースのText-to-SQLエージェントは、ユーザーの意図を理解しクエリを生成するために、データベーススキーマ（テーブル、カラム、および結合関係）に依存している。エンタープライズ環境におけるきめ細かなアクセス制御においては、スキーマメタデータ自体が機密情報となり得る。例えば、employee_compensation（従業員報酬）やfraud_score（不正スコア）といったテーブル名やカラム名は、実際のデータレコードを公開せずとも、内部のビジネスプロセスやデータ資産を露呈させてしまう。

現在のText-to-SQLシステムは、通常、完全なスキーマを提供するか、フルスキーマ空間から関連するオブジェクトを検索してモデルのコンテキストに追加する。この設計は、スキーマメタデータは普遍的に可視であるという前提に基づいているが、これはマルチテナント環境や制限されたアクセス権を持つ環境においては安全ではない。対処すべき核心的な問題は、プロセスレベルのスキーマ露出である：

• 脅威: 完全な、あるいは部分的に取得されたスキーマが低信頼コンポーネント（例：外部LLMサービス、リランキングモジュール、またはプロンプトインジェクションに対して脆弱なコンポーネント）に入り込むと、許可されていない識別子や構造的関係が漏洩する。
• 既存の防御策の限界: 生成後のSQLバリデーションやデータベース管理システム（DBMS）のアクセス制御は、不正なクエリの実行を阻止することはできるが、モデルがすでに観測してしまったスキーマ情報を取り消すことはできない。一度、許可されていないオブジェクトがコンテキストに入ると、プロンプトインジェクション、ロールプレイ、またはマルチターンでの探索を通じて、機密性の高いスキーマ構造を再構築されるリスクがある。
• ギャップ: 関連性のある情報の検索（リトリーバル）よりも前に認可を強制するメカニズムが欠如しており、これにより、許可されていないオブジェクトが低信頼のパイプラインに決して入り込まないようにする必要がある。

2. 手法：認可優先フレームワーク

著者らは、関連性の計算が行われる前にアクセス制御を強制することで、コンパクトで安全なスキーマコンテキストを構築する、**認可優先（Authorization-First）**フレームワークを提案している。このシステムは、検索、リランキング、および生成コンポーネントが信頼境界の外側にあるという脅威モデルの下で動作する。

2.1 核となる原則

• 生成前コンフィデンシャリティ: 認可は、スキーマオブジェクトが検索に参加するための前提条件として扱われる。システムは、クエリ依存の関連性スコアリングを行う前に、ユーザー固有の認可サブスペース（$S_u$）を構築する。
• プロベナンス（由来）を考慮した継承: セキュリティは基本オブジェクト（テーブル、カラム）だけでなく、派生したアーティファクト（意味論的記述、結合ヒント、SQLデモンストレーション）にも及ぶ。あるアーティファクトが可視となるのは、それが依存するすべての基本オブジェクトが認可されている場合のみである。例えば、認可されたカラムの記述の中に、未認可のテーブルに関する言及が含まれてはならない。
• 情報を明かさない棄却: リクエストが認可されたサブスペース内で満たされない場合、システムは原因に関わらずバイト単位で同一の汎用的なメッセージ（「現在のアクセス範囲内ではリクエストを完了できません」など）を用いてリクエストを拒否する。これにより、拒否の挙動がスキーマ探索のためのオラクル（手がかり）として機能することを防ぐ。

2.2 システムパイプライン

本フレームワークは、オフラインのガバナンスとオンラインの推論で構成される：

1. オフライン・ガバナンス: スキーマを原子化し、意味論的記述を生成する。極めて重要な点として、記述はターゲットとなるオブジェクトとその自身のテーブルのみから生成され、グローバルなスキーマからは決して生成されない。これは、隠蔽された識別子の漏洩を防ぐためである。すべてのアーティファクトにはプロベナンスラベルが付与される。
2. オンライン推論:
   • 認可サブスペースの構築: ユーザーの質問を処理する前に、システムはユーザーのポリシー $P(u)$ に基づいてスキーマをフィルタリングし、$S_u = \text{Authorize}(S, P(u))$ を作成する。
   • 制限された検索: テーブルの検索、カラムの選択、およびリレーションの選択は、すべて $S_u$ の中でのみ行われる。未認可のオブジェクトは、単にスコアが低くなるのではなく、候補空間から完全に排除される。
   • 権限に安全な意味論的エンリッチメント: 省略されたエンタープライズ識別子（例：cust_rsk_scr）を扱うために、システムは検索のフォールバックとして意味論的記述を使用する。これらの記述は識別子マッチングと融合されるが、プロベナンスのルールを厳格に遵守する。
   • 充足可能性ゲート（Satisfiability Gate）: $S_u$（単なる上位$K$個の検索結果ではなく）が、必要なエンティティと操作をカバーしているかどうかをシステムがチェックする。カバレッジが不十分な場合、汎用的な拒否メッセージが発行される。
   • コンテキストの組み立て: 最終的なコンテキストは、認可されたテーブル、カラム、リレーション、および派生したアーティファクトから組み立てられる。

3. 主な貢献

1. 生成前スキーマコンフィデンシャリティ・フレームワーク: 著者らは、生成前のスキーマコンフィデンシャリティを、生成後のSQL認可とは異なる明確な目的として定義した。彼らはクロス境界スキーマ処理に関する脅威モデルを定義し、プロセスレベルの露出メトリクスを導入した。提案されたメカニズムは、関連性検索の計算が行われる前に、未認可のオブジェクトとその派生アーティファクトが除去されることを保証する。
2. 順序付けと防御の深さに関する実証的証拠: 最終的なプロンプトが提案手法と「検索後にマスクする（retrieve-then-mask）」ベースライン間でバイト単位で同一である制御実験を通じて、プロセスレベルの漏洩を排除できるのは、認可の「順序」（検索後か検索前か）に起因することを証明した。さらに、漏洩プロベナンス分析により、コンテキストの最小化と生成後のバリデーションが直交するリスクを軽減することが示された。すなわち、フルスキーマのコンテキストは直接的なインジェクションによって漏洩し、提案手法による残留漏洩はモデルのハルシネーションのみに起因する。
3. 意味論的エンリッチメントに関する条件付き結果: 本論文は、識別子の不透明性が意味論的エンリッチメントの恩恵を受けるための前提条件であることを確立した。自然言語の識別子を持つ標準的なデータセットではエンリッチメントによる測定可能な利得はないが、体系的に省略されたエンタープライズ形式のスキーマにおいては、検索の再現率（Recall）とダウンストリームの精度（SchemaF1）を大幅に向上させた。

4. 実験結果

フレームワークは、20のデータベースと4つの権限ティアを含む、アクセス制御が拡張されたSpiderベンチマークを用いて評価された。

• プロセスレベルの露出: 本フレームメントは、プロセスレベルのスキーマ露出を、フルスキーマのベースラインにおける平均 35.5 個の未認可オブジェクトから 0 へと減少させた。これは、予算を一致させた「検索後にマスクする」ベースラインと比較して、ユーティリティのコストなしで達成された。
• SQL漏洩: 未認可のSQL参照は、0.546（フルスキーマ）から 0.115 に減少した。
  • 0.546から約0.15への減少は、コンテキストの最小化（コンテキストサイズの縮小）によるものである。
  • 0.15から0.115へのさらなる減少は、充足可能性ゲートによるものである。
• 漏洩プロベナンス: 分析の結果、提案フレームワーク下で発生したすべての未認可のSQL参照は、提供されたコンテキストからではなく、モデルのハルシネーション（識別子の推測）に起因することが示された。対照的に、フルスキーマのベースラインでは、100%の漏洩がコンテキストから直接コピーされていた。
• プロンプトインジェクション耐性: 直接的な列挙攻撃およびロールプレイ攻撃を用いたケーススタディにおいて、本フレームワークは、難読化されたスキーマ設定における未認可テーブルの復元率を 40–55%（フルスキーマ）から 0.00% へと減少させた。
• 意味論的エンリッチメントの影響: 難読化されたスキーマにおいて、意味論的エンリッチメントは検索の再現率を +11.5 ポイント、SchemaF1を +6.6 ポイント向上させた。自然言語のスキーマでは、測定可能な利得は見られなかった。

5. 重要性と主張

本論文は、Text-to-SQLシステムにおいてプロセスレベルの機密性を達成するためには、**「認可は検索に先行しなければならない」**と主張している。著者らは、生成後の防御策は、低信頼のコンポーネントがすでに観測してしまった情報を取り消すことができないため、不十分であると論じている。

本研究の重要性は以下の点にある：

• アーキテクチャの転換: セキュリティ境界を、SQL実行レイヤーからスキーマコンテキスト構築レイヤーへと移動させたこと。
• 防御の深さ（Defense-in-Depth）: コンテキストの最小化（モデルに機密データを見せないこと）とSQLバリデーション（モデルによる不正なクエリの実行を防ぐこと）は、直交するリスクに対処するものであり、併用すべきであることを示したこと。
• ゼロ・ユーティリティ・コスト: 厳格な事前検索認可が、同じ量の認可済みデータを扱うベースラインと比較して、検索の有用性や生成精度を低下させないことを証明したこと。

著者らは、本フレームワークが公知の知識からの推論、データベースのエラーメッセージ、または統計的開示を防ぐものではないとして、限界についても謙虚に述べている。また、充足可能性ゲートはヒューリスティックであり、評価は動的なエンタープライズ環境ではなく合成されたポリシーに基づいていることも認めている。本フレームワークは、既存のSQLバリデーションおよびDBMSアクセス制御を置き換えるものではなく、それらを補完する「情報最小化レイヤー」として提示されている。