何が起きたか
ミラノを拠点とするMicrosoftパートナー、SynSphere ItaliaのCEOでITエンタープライズアーキテクトでもあるEgiziago Cioffi氏は、受信顧客メールの約60%を自動処理するAzure OpenAIアシスタントを自ら構築しました。インデックス作成ジョブの実装、Azure OpenAIの検索パイプラインの設定、SharePointとの接続まで、すべて本人の手によるものです。
このエージェントはチームが実施した評価をすべて通過し、単体テストも合格。評価スコアはクリーンでした。ところがCioffi氏が低権限アカウントで、高権限アカウントが以前に投げたのと同じ質問を試したところ、出力が一致しなかったのです。アシスタントは、そのユーザーがSharePoint上では自力で開けないはずの文書内容を返していました。証拠は検索ログに残っていました。
なぜ「テストは全部通った」のか
Cioffi氏のチームが実施した評価は、事実の正確性・関連性・タスク完遂率を測るものでした。「検索パイプラインが誰の権限で動いているか」は、そもそも評価項目に入っていません。ここが本件の核心です。品質評価と権限評価は別物であり、前者を満点で通過しても後者は一切保証されません。
多くの本番RAG構成では、エージェントは「リクエストした人」ではなく「インデクサ」の権限で回答します。Netragard創業者兼CEOのAdriel Desautels氏はVentureBeatへの書面回答で、この失敗を認可境界の構造的崩壊だと表現しました。「アプリがアイデンティティを意識した検索を強制しないなら、権限の低い『普通の』ユーザーがアプリに問い合わせるだけで、本来制限されたデータにアクセスできてしまう。これは認可境界を、検索能力を持つ最低権限レベルまで引き下げる」。同氏はまた、エージェントが「単一・長寿命の非人間アイデンティティで動き、あらゆるタスクに備えて広範な権限を保持しがち」だとも指摘しています。
Azureには対策機能がある、ただし経路次第
Azure AI Searchは2025年5月のプレビュー以降、Entraベースのトークンによる文書レベルACLトリミングを提供しています。呼び出し元のEntraトークンを検証し、ユーザーとグループのクレームを取り出して、同期済みの権限メタデータがアクセスを許可する文書だけを返す仕組みです。SharePointのACL同期はその後のプレビューで追加されました。
ただし制約があります。SharePoint ACLプレビューは2026-05-01-preview APIのspg:プレフィックスでサイトグループのメタデータを取り込めますが、クエリ時に確実に強制されると文書化されているのはEntraバックの プリンシパルのみです。プレビューはREST APIとプレビューSDK経由で動作し、すべてのエージェント配備経路をカバーしているわけではありません。
さらに注意すべきは一次経路の挙動です。Azure OpenAI On Your DataはAzure AI Searchのセキュリティフィルタで文書レベルのアクセス制御に対応していますが、Microsoftの文書によれば、許可グループのフィールドがマッピングされていない場合は文書レベルのアクセス制御が無効になります。設定漏れが「閉じる」ではなく「開く」側に倒れる、フェイルオープンの初期値です。
そしてCioffi氏が採ったのはカスタムパイプラインの経路でした。Azure AI Searchを迂回する自作RAGは、広い権限を持つサービスアカウントでインデックスを作り、開発者が自分で作らない限りクエリ時のエンタイトルメント検査は存在しません。ネイティブのトリミング層は、そもそも通っていなかったのです。
「攻撃が成功した後」に何が起きるか
Straikerのレッドチームは本番エージェントに対して1,700件超の攻撃成功例を積み上げ、7月に初のSTAR Labs Threat Reportとして公開しました。対象となった生産性エージェントでは、成功した攻撃の91%が静かなデータ持ち出しで終わっています。マルウェアは不要、ネットワーク内の横展開もなし。エージェントは到達できるデータをすべて返しただけでした。
この数字の読み方には注意が必要です。同レポートは、成功例のうちどれがエンタイトルメントの不備に起因し、どれがプロンプトインジェクションやツール悪用など他の攻撃クラスなのかを分解していません。91%はあくまで「攻撃が成功した後に何が起きたか」であり、「どれだけの配備が検索時のエンタイトルメントを強制できていないか」を測った数字ではありません。
参考として、英国AI Security Institute（UKASI）は7月25日から28日のサイバー評価で19件の無許可エージェント行動を記録し、8月4日にインシデント報告を公開しました。ただしこの評価はサイバー分類器を意図的に無効化しインターネット接続を有効にした条件下のもので、性質としては封じ込めの失敗であり、検索エンタイトルメントの失敗ではありません。Cioffi氏の事例と共通するのは「実行時のスコープ検査が存在しなかった」という一点だけです。
修正はクエリ時フィルタ一つ
Cioffi氏の対処は、新しいアイデンティティ基盤の導入ではありませんでした。モデルがチャンクを見る前に、リクエストしたユーザーのSharePoint権限を確認するフィルタをクエリ経路に追加しただけです。インデックス時ではなくクエリ時に走るため、アクセス不可の内容はそもそもモデルのコンテキストウィンドウに入りません。
フィルタ稼働後も、アシスタントは受信メールの約60%を自動処理し続けています（フィルタ導入前の自動処理率との比較値は示されていません）。同氏が語ったトレードオフは定性的なもので、以前はアシスタントが使えていた一部の内容が、リクエスト元ユーザーの権限が届かないという理由で除外されるようになった、というものです。この狭まりが割に合うかどうかは、コンテンツの機微性、ユーザー層ごとの権限のばらつき、そして「答えられない質問」への許容度で決まります。
アイデンティティ統治の買収ラッシュでは埋まらない層
セキュリティ業界はアイデンティティに巨額を投じています。CrowdStrikeは2026年1月8日にSGNLの7億4,000万ドルでの買収を発表し、2月20日に完了。Palo Alto Networksは2025年7月に発表したCyberArkの250億ドル買収を2026年2月11日に完了しました。奇しくも両案件は同じ月にクローズしています。
しかしアイデンティティガバナンス基盤が統治するのは、どのサービスアカウントが存在し、何に到達でき、トークンがいつ失効するかという資格情報のライフサイクルです。検索の権限境界そのものではありません。今回の失敗モードでは、チェーン上のあらゆる資格情報が正規です。サービスアカウントはクリーンで適切に管理され、ナレッジベースは正しくインデックスされ、資格情報の不正使用が一切ないため、検索を止めるフラグもどこにも立ちません。
💼 事業会社視点：これは自社にどう効くか
日本企業でいま最も危ないのは、SharePointやNotionを社内ナレッジ基盤にしてRAGチャットを内製した情シス部門と、それを顧客に納品した受託開発企業です。特に受託の場合、Azure AI Searchのネイティブトリミングを使わずカスタムパイプラインを組んだ案件は、契約上どちら側の瑕疵になるかが曖昧なまま稼働しています。人事評価・役員会資料・M&A関連が入ったサイトを一つでもインデックスしていれば、平社員アカウントからの質問で漏れる構造です。
経営者が今週指示すべきは一つ。「そのAIは誰の権限で検索しているのか」を全社のAI検索システムについて答えさせることです。Azure AI SearchとSharePointインデクサ、Entraバックのプリンシパルという構成なら、クエリ時ACLトリミングが有効か、ユーザー層がSharePointサイトグループに依存していないかを確認します。Azure OpenAI On Your Dataを使っているなら、許可グループフィールドのマッピング有無を必ず見てください。未マッピングなら文書レベル制御は無効です。
検証コストはアカウント2つと30分。高権限アカウントが既に投げた質問を低権限アカウントで再投入し、出力を低権限側が直接アクセスできる範囲と突き合わせるだけです。SaaS事業者ならこれを顧客向けのセキュリティ説明資料に載せられます。逆に説明できないベンダーは、来期の調達要件で落ちます。