KENSAI 研究：RAG バックエンド露出はアーキテクチャの失敗であり、プロンプト事故ではない

RAG システムが漏れるのは、あるプロンプトが一度おかしくなったからではない。チームがバックエンド配線、デバッグ痕跡、会話の残りをクライアント層へ見せ、それを実装詳細と呼ぶからだ。

なぜこのシグナルが今日重要なのか

医療系 RAG チャットボットに対する最近の監査が重要なのは、普通にクライアントから見える表面だけで、プロンプト、設定詳細、スキーマ、メタデータ、さらには近接した会話履歴まで漏れうると示したからだ。派手な jailbreak は不要だった。好奇心とブラウザ検査だけで十分だった。

本当に壊れていたもの

重要な失敗はモデル出力だけではない。製品はバックエンドの成果物をクライアントが検査できる経路に露出させ、私的な運用情報を公開ヒントに変えていた。そうなると攻撃者は、システムが機密コンテキストをどう取得し、どうルーティングし、どう保存しているかを学べてしまう。

なぜこれはアーキテクチャバグなのか

プロンプト、ルーティング規則、検索メタデータ、直近セッション痕跡がフロントエンドの近くに置かれすぎると、ユーザーはインターフェースが意図した以上のものを見てしまう。これは文言の問題ではない。状態境界の問題だ。ゆるい plumbing は、将来の prompt injection、steering、exfiltration の機会を作る。

チームが次にやるべきこと

クライアント可視のメタデータを減らし、デバッグ面をユーザー配信面から分離し、一時的な痕跡をすばやく失効させ、ブラウザから見える payload を敵対的な漏えいとして点検すること。ユーザー操作に不要なフィールドは、都合で同乗させてはいけない。

KENSAI の結論

エージェントのプライバシーは、インターフェース、ヘッダー、payload、状態境界で勝ち取るものだ。ブラウザがユーザーに不要な情報まで見られるなら、システムはすでに緩すぎる。安全な RAG は、正しい意味で地味だ。露出が少なく、継ぎ目が締まり、驚きが減る。