Azure OpenAIアシスタントが権限外のSharePoint文書を返す問題

何が起きたか

イタリアのMicrosoftパートナーSynSphere ItaliaでCEOを務めるEgiziago Cioffi氏は、Azure OpenAIを使った顧客メールの自動返信アシスタントを構築していた。このアシスタントは受信メールの約60%を自動解決し、Cioffi氏のチームが実施した評価もすべて合格していたという。

しかし、Cioffi氏が低い権限のアカウントを使って同じ質問をしたところ、結果は高権限アカウントと一致しなかった。アシスタントは、そのユーザーがSharePoint上では開けない文書の内容を返した。ログは評価結果と異なる実態を示していた。

根本原因と標準機能の限界

原因は、RAGパイプラインの検索処理が要求者の権限ではなく、インデックス作成時のサービスアカウント権限で動いていたことにある。Cioffi氏の構成はAzure AI Searchを経由しないカスタムパイプラインで、クエリ時にアクセス権を確認する仕組みが無かった。

Azure AI SearchにはEntra IDトークンによる文書レベルのACLトリミングがプレビュー実装されている。ただし、SharePoint ACL同期を含むこの機能は、選択した経路や設定条件を満たす必要があり、すべてのエージェント展開をカバーするわけではない。Microsoftのドキュメントでも、Azure OpenAI On Your Dataでpermitted-groupsフィールドがマッピングされなければ文書レベルのアクセス制御は無効になるとされている。

広がる同種のリスク

この問題は単独のミスではない。セキュリティ企業Straikerの報告では、本番エージェントへの攻撃成功例1700件超のうち、91%がサイレントなデータ流出で終わった。ただしこれは権限チェックの欠如だけを指すものではなく、プロンプトインジェクションやツール悪用なども含む。

英国のAI Security Instituteは、制約の少ない評価環境でエージェントが意図しない行動を19件起こしたと報告している。これも実行時にエージェントの行動範囲を検証する仕組みの不在が背景にあるとみられる。

対策の方向性

原題が示す解決策は、権限で絞り込む「1つのフィルタ」と、アシスタントのアクセス範囲を狭めることにある。具体的には、検索結果を要求者のACLに基づいてフィルタし、アシスタントに見せてもよいデータの範囲を限定する実装が必要だ。

ただし、どのようなフィルタをどの層に置くかはシステム構成によって異なる。Cioffi氏の事例ではカスタムパイプライン側に権限チェックを追加する必要があり、既存の評価手順には低権限アカウントを使ったテストを含めるべきという教訓が残る。