詳細を読む
SynSphere Italiaのエジツィアゴ・チョッフィCEOは2026年9月、SharePointに接続した独自のAzure OpenAIメール支援エージェントが、利用者の権限を超える文書を回答に使う問題を明らかにしました。品質評価と単体テストは通過していましたが、低権限アカウントで試すとSharePoint上では開けない内容が返され、検索時の権限確認が欠けていたことが判明しました。
原因は、独自RAGパイプラインが広い権限を持つインデクサーの範囲で情報を取り込み、質問者ごとの権限を検索時に照合しなかったことです。正確性や関連性、タスク完了を測る評価だけでは「誰の権限で検索したか」を検証できず、アクセス制御の欠落を見逃しました。
Azure AI Searchには、Entraトークンと同期済み権限情報を使い、許可された文書だけを返すクエリ時のACLトリミングがあります。ただし、プレビュー機能や対応経路には制約があり、許可グループのフィールドをマッピングしない構成やAzure AI Searchを迂回する独自RAGでは、開発側が権限確認を組み込む必要があります。
チョッフィ氏は、モデルへ文書断片を渡す前に要求者のSharePoint権限を確認するフィルターを検索経路へ追加しました。取得範囲は狭まりましたが、導入後も受信メールの約60％を自動解決しており、当該環境では主要な自動化機能を維持しました。
なお、Straikerの調査で生産性エージェントへの成功攻撃の91％が検知されないデータ流出に至ったという数字は、権限確認の欠落だけを測ったものではありません。プロンプト注入やツール悪用なども含むため、今回の事例の発生率を示す統計としては扱えない点に注意が必要です。
企業は本番投入前に、同じ質問を高権限・低権限の2アカウントで実行し、低権限者が元システムで直接閲覧できる範囲と回答を照合すべきです。サービスアカウントのID管理に加え、検索時の権限照合を別の防御層として設けることが、RAG運用の実務的な要点です。