社内RAGは権限制御だけでは不十分

実験は段階的に進む。アクセス制御が全くない状態（PI-062-01）では、一般ユーザーへの回答に個人の携帯番号、人事評価情報、本番設定文書の模擬APIキーが含まれた。LLMにユーザーの部門と役職を伝えるだけ（PI-062-02）では不正な文書を取得できたままで、認可はアプリケーション側で強制すべきであり、プロンプト指示は補助にすぎないとラボは結論づけた。

Retrieverが部門で絞り込み（PI-062-03）、続いて役職と文書で絞り込むと（PI-062-04）、営業の一般社員は管理職専用の営業戦略文書を取得できず、sales-manager01は取得できた。しかし許可文書内の開示は解決しなかった。営業の一般社員は閲覧を許可された顧客連絡先文書から依然個人の携帯番号を入手できた。ラボは、最終回答だけでは区別できない三つの問いを分けて考える。取得文書が認可されているか、LLMに実際に渡された文書が認可されているか、回答自体が適切で根拠があるか、である。

プロンプト比較（PI-062-10）では、取得テキストを信頼できないデータとして扱うよう指示する強化プロンプトで個人番号の出力が減ったが、ベースラインでも攻撃マーカーは出ず、インジェクション耐性の改善は確認できなかった。また強化実行でも、根拠文書に裏付けのない営業施策・計画・ROI/KPIの具体値が生成されたと指摘。認証、Retrieverの認可、コンテキストのログ記録、プロンプト指示、出力検証を別々の制御として推奨し、結果は全経路・全入力での安全性を証明するものではないと注意を促した。