AIエージェントのRAG、権限管理に構造的な穴

企業向けAIエージェントの普及が進む中、検索拡張生成（RAG）と呼ばれる仕組みの権限管理に、見落とされがちな構造的な欠陥があることが具体的なケースで確認された。ミラノを拠点とするMicrosoftパートナー企業SynSphere ItaliaのCEOで、ITアーキテクトのEgiziago Cioffi氏は、自ら構築したAzure OpenAIのメールアシスタントで、受信メールの約60%を自動処理できるシステムを開発した。評価スコアは良好で、社内テストも通過していたが、ある検証で深刻な問題が浮かび上がった。

Cioffi氏が低権限のアカウントでアシスタントに問い合わせを行ったところ、そのアカウントが本来SharePoint上で直接アクセスできないはずのコンテンツが返答に含まれていたことを確認した。高権限アカウントによる問い合わせと、低権限アカウントによる問い合わせの結果が一致していたのだ。これは、アシスタントがリクエストを送ったユーザーの権限ではなく、データをインデックス化（索引作成）した際のサービスアカウントの権限で情報を取得・返答していたことを意味する。評価スコアやユニットテストには、この「誰の権限で情報を返すか」という観点が含まれていなかった。

RAGとは、AIが事前に学習した知識だけでなく、社内文書などの外部データをリアルタイムで検索して回答に活用する仕組みのこと。その検索の段階で、「誰が質問したか」に応じたアクセス制御が機能していなければ、権限のないユーザーに機密情報が渡るリスクが生じる。MicrosoftのAzure AI Searchは、2025年5月のプレビューから文書レベルでのアクセス制御機能を提供し始め、SharePointのアクセス権との連携も後続のプレビューで追加されている。ただし、この機能がすべての利用経路で確実に有効になっているわけではない。

Microsoftの公式ドキュメントによると、「Azure OpenAI On Your Data」において、文書へのアクセス権を管理するフィールドが正しく設定されていない場合、文書レベルのアクセス制御は無効になる。言い換えれば、設定が不完全な場合にはアクセス制限が「開放状態」になるという仕様であり、意図せずセキュリティの穴が生じやすい構造となっている。Cioffi氏のシステムはAzure AI Searchを経由しないカスタムパイプラインを採用しており、クエリ実行時の権限チェックは開発者が独自に実装しない限り機能しない構成だった。

この問題が個別事例にとどまらないことを示すデータもある。AIセキュリティ企業Straikerは2025年7月、同社のSTAR Labsによる脅威レポートを公表した。同レポートによると、業務用AIエージェントに対して実施した1,700件以上の攻撃実験において、成功した攻撃の91%がマルウェアやネットワーク内の横断移動を一切使わずに、データの密かな持ち出しで終わっていた。エージェント自身が情報を返してしまうため、従来型の攻撃手法を必要としないという点が特徴的だ。

この一連の事実が示すのは、AIエージェントの評価基準が「正確に答えられるか」に偏りがちで、「誰に対して何を答えるべきか」という権限の観点が後回しになりやすいという構造的な課題だと言える。企業がRAGを活用したエージェントを本番環境に展開する際、機能テストと同等かそれ以上に、アクセス制御の検証が必要だという見方ができる。今後は、技術の選定やアーキテクチャ設計の段階から権限管理を組み込む「セキュリティ・バイ・デザイン」の考え方が、AIエージェント開発においても重要性を増していくと位置づけられる。

企業にとっての実務的な示唆は明確だ。評価スコアが良好でもそれだけでは不十分であり、異なる権限レベルのアカウントを使った実地検証が欠かせない。また、利用するサービスの設定仕様を把握した上で、権限チェックが実際に機能しているかをログレベルで確認することが、安全な運用の前提となる。AIエージェントの導入が加速する現在、こうしたセキュリティ面の検証が開発・運用プロセスの標準として定着していくかどうかが、今後の注目点の一つとなる。