ミラノを拠点とするMicrosoftのパートナー企業SynSphere ItaliaのBTおよび企業アーキテクト兼CEOであるEgiziago Cioffiは、Azure OpenAIを基盤とするメールアシスタントを開発した。このアシスタントは、受信した顧客メールの約60％を自動処理し、評価と単体テストでも良好な結果を示した。しかしCioffiは、低権限のアカウントで同じ質問を投げかけた際、ユーザーがSharePointで直接開けないコンテンツをアシスタントが返していることに気づいた。ログは評価結果と矛盾していた。
問題は、多くの本番環境のRAGシステムで、アクセス制御がリクエストを行ったユーザーではなく、インデクサーアカウントの権限に基づいて適用されていることにある。Azure AI Searchは2025年5月のプレビュー以降、Entraベースのトークンを使った文書レベルのACLトリミングをサポートし、SharePoint ACLの同期機能はその後のプレビューで追加された。しかし、この機能はすべてのデプロイ経路をカバーしているわけではない。SharePoint ACLプレビューでは、2026-05-01-preview APIでspg:プレフィックスを使ってサイトグループのデータを取得できる。クエリ時に確実に適用されることが文書で確認されているのは、Entra対応のIDだけである。Azure OpenAI On Your Dataで許可されたグループのフィールドがマッピングされていない場合、文書レベルのアクセスは無効になる。Azure AI Searchを介さないカスタムパイプラインでは、クエリ時の権限チェックは開発者に委ねられる。
Straikerは7月に公表した報告書で、本番環境のエージェントを標的とした1,700件を超える成功した攻撃の91％が、気づかれにくいデータ漏えいにつながったと報告した。UKASIは7月25〜28日の評価で、19件の不正なエージェントアクションを記録し、その報告書は8月4日に公表された。
なぜ重要か
この事例が示す核心的な問題は、AIアシスタントの回答が正確であっても、ユーザー権限が正しく適用されていることの証明にはならない点にある。これは、顧客メールを処理し、SharePointのような企業向けコンテンツソースに接続するシステムにおいて、権限の低いユーザーが本来アクセスできない文書に到達するリスクを生む。アクセス制御をインデクサーアカウントではなくリクエストを行ったIDに基づいて実施できるかどうかは、使用するAzureコンポーネント、IDの種類、構成に左右される。Azure AI Searchを使用しないカスタムアーキテクチャでは、この責任は開発者に委ねられる。そのため、評価や単体テストでクエリ時の権限チェックを別途検証しなければ、セキュリティ上の欠陥を見落とす可能性がある。残る明確な問いは、すべてのデプロイ経路において、文書レベルの権限がどのIDによって、またどの段階で確実に適用されるのかという点だ。
背景
OpenAIはFikirPilotのアーカイブにおいて新しい名前ではない。過去90日間に、この名前が登場するニュースを6本公開しており、最も新しいものは2026年9月1日付だ。
用語：エージェント
AIエージェントとは、単一の回答を生成するのではなく、目標を達成するためにツールを呼び出し、複数のステップにわたる作業を実行するソフトウェアである。