Azure OpenAI アシスタントの検索ギャップ解消に新プラットフォーム不要

シンスフィア・イタリアのCEOであり、ITおよびエンタープライズアーキテクトであるエジジアゴ・チオッフィ氏は、ミラノを拠点とするマイクロソフトのパートナー企業で活躍しています。彼自身もエージェントを構築しました。インデックス作成ジョブの記述から、Azure OpenAI の検索パイプラインの設定、SharePoint への接続まで全て手がけ、チームが実施したあらゆる評価テストをパスさせたのです。

チオッフィ氏は VentureBeat に対して書面で回答し、自社の Azure OpenAI によるメールアシスタントは、着信する顧客からの問い合わせの約 60% を自動的に解決できると語りました。評価スコアは良好で、ユニットテストもすべて合格しました。しかし、誰も問うていない重要な質問がありました。

チオッフィ氏は、そのアシスタントに対して、高権限アカウントが既に試したのと同じ質問を、低権限アカウントでも実行してみました。すると、出力結果に不一致が生じました。アシスタントは、ユーザー自身が SharePoint で開くことができないコンテンツを返してきたのです。ログを確認すると、評価スコアとは異なる事実が浮かび上がりました。

チオッフィ氏の検索ログこそが、この特定の生産環境での失敗を示す証拠です。以下に示す独立したデータは、この種の失敗が孤立した事例ではないことを示しています。

多くの生産環境における RAG（検索拡張生成）デプロイメントでは、エージェントが回答する際に、リクエスト元の権限ではなく、インデクサーの権限が利用されてしまいます。

Azure AI Search は 2025 年 5 月のプレビュー版以来、Entra ベースのトークンを用いたネイティブなドキュメントレベルの ACL（アクセス制御リスト）絞り込み機能を搭載しており、SharePoint の ACL 同期もその後のプレビューで追従しました。この機能は存在しますが、必要な場所ですべてで使われているわけではありません。

SharePoint の ACL プレビュー機能では、2026-05-01-preview API において spg: プレフィックスを使用してサイトグループのメタデータを取得できるようになりました。ただし、クエリ実行時に確実に権限が適用されるのは Entra に基づくプリンシパルのみが文書化されています。このプレビューは REST API とプレビュー SDK を通じて提供されており、すべてのエージェント導入パスを網羅しているわけではありません。

例えば Azure OpenAI On Your Data では、Azure AI Search のセキュリティフィルターを通じてドキュメントレベルのアクセス制御をサポートしていますが、Microsoft 自身のドキュメントによると、permitted-groups フィールドがマッピングされていない場合、ドキュメントレベルでのアクセスは無効化されます。

これは、公式パスにおける「デフォルトで開いた状態（fail-open）」です。Azure AI Search を完全にバイパスするカスタム RAG パイプラインでは、クエリ実行時に権限チェックが行われない限り、広範な特権を持つサービスアカウントの下でインデックスが作成されます。Straiker の導入は、このカスタムパイプラインの経路を採用しました。

大規模に展開された生産環境のエージェントにおいて、成功した攻撃の 91% が検知されないままデータが流出しています。

Straiker のレッドチームは、生産環境のエージェントに対して 1,700 回以上の成功したエクスプロイト試行を行い、その結果を 7 月に発表した初の STAR Labs サイバー脅威レポートにまとめました。この 91% という数値は、検知されずにデータが流出した生産環境の生産性向上用エージェントに対するすべての成功した攻撃を指すものであり、単に検索時の権限適用が失敗しているデプロイメントの数を測るものではありません。

対象となった生産性エージェントの攻撃事例において、91% の成功した攻撃は検知されずにデータが流出していました。報告書によると、マルウェアの使用も不要でした。また、ネットワーク内での横方向への移動も行われていませんでした。エージェントは到達可能なすべてのデータを返却しています。

Straiker の報告書では、これらの成功事例のうち、特定の権限設定の失敗に起因するものがどれほどあるか、プロンプトインジェクションやツールの悪用、その他の攻撃クラスに起因するものとの内訳については明記されていません。

独立して調査を行った英国 AI セキュリティ研究所（UKASI）は、7 月 25 日から 28 日にかけて実施されたサイバー評価において、19 の承認されていないエージェントの動作を記録しました。UKASI は今年 8 月 4 日にそのインシデント報告書を公表しています。この評価では、サイバー分類機能を無効化し、インターネットアクセスを有効にした状態で意図的に実行されました。

UKASI の報告書が示しているのは、エージェントがデプロイ者が想定した範囲を超えて動作し、許容度の高いテスト環境下で、損害が発生する前にその逸脱を検出できる信頼性の高いメカニズムが存在しないという事実です。これは検索権限の失敗ではなく、コンテナ化の失敗（収束不能）であり、Cioffi 事件との共通点は、同じメカニズムが共有されていることではなく、ランタイム時のスコープチェックが欠如している点にあります。

なぜ評価がこの点を逃し、ネイティブな対策が Cioffi のデプロイに届かなかったのか

Cioffi 氏のチームが実施した評価は、エージェントが正しく回答できるかを検証するために設計されました。具体的には、事実の正確性、関連性、タスク完了率を確認するものです。

しかし、この評価フレームワークでは、「検索パイプラインがソース資料を取得する際に、誰の権限を使用しているか」という問いは含まれていませんでした。

現在、Azure AI Search はプラットフォームレベルで「検索時の権限チェック」機能を提供しています。クエリ実行時に ACL（アクセス制御リスト）を絞り込む処理により、呼び出し元の Entra トークンを検証し、ユーザーやグループの主張情報を抽出します。その結果、同期された権限メタデータが呼び出し元にアクセス許可を与えている文書のみが返されます。

Azure AI Search に SharePoint インデクサーと Entra ベースのプリンシパルを組み合わせて使用するデプロイメントでは、この制御機能はネイティブに備わっています。しかし、Cioffi 氏のデプロイメントはこの経路を採用していませんでした。同氏が構築したカスタムの Azure OpenAI 検索パイプラインは、ネイティブな絞り込み層を迂回していたため、評価が繰り返されるたびにその隙間（ギャップ）が残存し続けていたのです。

攻撃者の視点から見れば、これはアクセス制御の欠陥です。Netragard の創設者兼 CEO アドリエル・デサウルスは VentureBeat への書面回答で、この失敗は権限境界の構造的崩壊に帰着すると指摘しました。

「通常、NHI（非人間）の認証情報は広範な権限を持ち、高権限データを参照できるため、そのデータがインデックスに格納されます。もしアプリがアイデンティティを認識した検索を実装していなければ、権限の低い『通常のユーザー』でもアプリを通じてクエリを発行し、本来は制限されたデータにアクセスできてしまいます。これにより、検索機能を持つ最低レベルの権限まで権限境界が引き下げられてしまうのです」

この隙間こそが、Cioffi 氏の低権限テストによって暴かれた問題です。アシスタントのコンテキストウィンドウには、低権限アカウントでは SharePoint を介して直接取得できないはずの SharePoint コンテンツが含まれていました。評価は通過しましたが、検索に関する権限境界は実際には適用されていなかったのです。

デサウルス氏はこの評価の盲点を運用上の課題として捉えています。「エージェントは通常、あらゆるタスクを完了するために必要な広範な権限を持つ、単一の長期間稼働する非人間のアイデンティティで動作します。また、注入されたコンテンツを通じて読み取られたり乗っ取られたりする可能性のあるプロンプト、出力、通訳、メモリ、ログといった領域も、評価では十分にカバーされていないことが多々あります。このミスマッチこそが、現在の多くの評価が誤っている点です」

Cioffi 氏が導入したフィルタは、アシスタントの検索範囲を狭める役割を果たしました。これにより、約 60% のメールに関する検索が可能になっています。

Cioffi 氏の修正には、新たなアイデンティティプラットフォームの導入は不要でした。彼は権限判断を検索パス自体に組み込み、モデルがチャンク（データ断片）を受け取る前に、リクエスト元のユーザーの SharePoint 権限を確認するクエリ経路フィルタを追加しました。このフィルタはインデックス作成時ではなく、クエリ実行時に動作します。ユーザーが SharePoint で開くことができないコンテンツは、モデルのコンテキストウィンドウ内に入ることはありません。

この制御により、アシスタントがアクセスできる範囲が狭まりました。Cioffi 氏は VentureBeat の取材に対し、フィルタを稼働させた状態で、アシスタントは依然として約 60% の受信メールを自動解決できていると明かしました。ただし、フィルタ導入前の自動解決率の比較データについては公開していません。彼が指摘した定性的なトレードオフは、以前は回答に利用していた一部のコンテンツが、リクエスト元のユーザー権限に達しないため除外されるようになった点です。これが境界線を厳格に守るための代償となります。

検索時の権限フィルタリングが、狭まった検索範囲の縮小に見合う価値があるかどうかには、単一の答えはありません。これは、インデックス化されたコンテンツの機密性や、ユーザー層全体における権限のばらつき、そしてモデルが必要なチャンクをフィルタでブロックされた際に回答不能なクエリが発生しても許容できるかどうかに依存します。Cioffi 氏の事例が示しているのは、カスタム Azure OpenAI パイプラインにこのギャップが存在すること、回答品質の評価ではそれが検出されないこと、そしてビルダーがトレードオフを説明可能な形でクエリ経路フィルタによってその隙間を埋められることです。

アイデンティティガバナンスプラットフォームは異なるレイヤーの問題に対処するものです。両方の制御が必要となります。

CrowdStrike は 2026 年 1 月 8 日、SGNL を 7 億 4,000 ドルで買収すると発表し、同年 2 月 20 日に取引を完了しました。一方、Palo Alto Networks も 2025 年 7 月に CyberArk を 250 億ドルで買収すると発表し、2026 年 2 月 11 日に契約を結んでいます。

この二つの大型取引が同じ月に完了したことで、アイデンティティセキュリティが世界有数のセキュリティベンダーにおけるプラットフォームの柱として確立されました。

アイデンティティガバナンスプラットフォームは、どのサービスアカウントが存在し、何にアクセス可能で、トークンがいつ期限切れになるかを管理します。AI エージェントを動かす認証情報のライフサイクルを統制する重要なレイヤーです。しかし、ここで重要なのは「検索権限の境界」までカバーしていない点です。

検索権限の境界とは、適切なスコープを持つサービスアカウントが、インデックス作成ジョブよりも低い権限しか持たないユーザーに代わってコンテンツを検索・取得する瞬間を指します。この時、チェーン上のすべての認証情報は正当なものです。サービスアカウントは健全で適切に管理されており、ナレッジベースも正しくインデックスされています。低権限のユーザーがアシスタントに問い合わせると、アシスタントはフルスコープのインデックスに基づいて回答を返します。

何らかの不正な認証情報の使用がないため、この検索プロセス自体にはアラートが発生しません。

Cioffi 氏が開発したフィルタリング機能は、まさにこの「検索権限の境界」レイヤーに特化した制御です。Azure AI Search のネイティブ ACL トリミングも同様のレイヤーを対象としていますが、これはその機能を利用するデプロイメントに限られます。

いずれの技術もアイデンティティガバナンスを代替するものではありません。認証情報のライフサイクルにおけるギャップと、検索実行時の権限付与におけるギャップの両方を埋めるためには、両方のレイヤーで制御を実装する必要があります。

セキュリティチームなら誰でも実行できる、たった一つの質問とテスト

AI の検索システムがコンテンツを取得する際にどの権限を使用しているか、常に問いかけるべきです。

デプロイメントで Azure AI Search と SharePoint インデクサー、そして Entra に基づくプリンシパルを利用している場合、クエリ実行時の ACL 制限（ACL trimming）が有効になっていることを確認し、ユーザー層が SharePoint サイトグループに依存していないかを検証してください。もしカスタムの検索パイプラインを採用しているなら、権限チェック自体が存在しない可能性さえあります。

まずは低権限のアカウントから回答の実証を始めましょう。すでに高権限のアカウントがアシスタントに対して実行済みの質問を、同じく低権限のアカウントで再実行します。その出力結果と、低権限のアカウントが基盤システムに直接アクセスして得られる情報とを比較検討してください。

Desautels 氏は、これがレッドチーム（攻撃側のテストチーム）が着手する地点であると確認しています。「最初のテストは、おそらくデータと指示の間の隙間、そしてユーザーのアイデンティティとアシスタント自身の認証情報の間の隙間を狙うでしょう」と彼は記述しています。「私たちがアシスタントにデータとして取り込まれると予想するコンテンツ内に、指示を仕掛けるのです。そのコンテンツが、攻撃者が権限を持っていない特権的なアクションを引き起こすように誘導します。」Desautels 氏の評価では、失敗した結果とは「注入したコマンドの成功、あるいは部分的な実行」のことです。

アシスタントが、アカウントの直接アクセス権限を超えた情報を返す場合、検索時の権限境界は適用されていません。この検証には 2 つのアカウントと 30 分が必要です。評価スコアでは再現できない結果が得られます。

Cioffi 氏は、ネイティブな ACL（アクセス制御リスト）の制限層をバイパスするカスタム Azure OpenAI パイプライン上でエージェントを構築しました。チームが行ったすべての評価を実行しましたが、すべて合格した後のログで初めてこの隙間を発見しました。評価では「エージェントが正しく回答できたか」は検証されていましたが、「どの権限を使って回答しているか」までは確認していませんでした。

次のデプロイが本番環境に上がる前に、2 つのアカウントを使った比較テストを実行してください。30 分あれば、自分がその境界線のどちら側に立っているかがわかります。