Microsoft Copilot Cowork、Skillファイル経由の間接プロンプトインジェクションでM365ファイル流出経路を実証 — Claude Opus 4.7でも100%成立、エージェント設計の構造的課題

この記事は約17分で読めます。

プロンプトインジェクション専門のセキュリティ研究組織 PromptArmor は2026年5月25日、Microsoft 365 の Frontier feature として提供されている Microsoft Copilot Cowork において、Skill ファイル経由の間接プロンプトインジェクションにより M365 ファイルの流出経路が成立し得ることを実証しました。攻撃者は悪意ある Skill ファイル（Copilot Cowork が拡張機能として読み込むファイル）に指示を仕込み、被害者がそれをアップロードして Cowork のタスク内で起動した場合、Cowork に SharePoint や OneDrive 上のファイルの pre-authenticated download links を取得させ、Teams メッセージ内の外部画像リクエストを通じて攻撃者サーバへ送信させることができます。PromptArmor によれば本攻撃チェーンは 5回試行で5回成立（100%）、しかも Claude Opus 4.7 を直接指定した場合にも同じインジェクションで成立 しています。本件は、PromptArmor が個別の実装バグというより、企業エコシステム全体に委任された権限で動作するエージェントの設計上のリスクとして公開したものです。なお同社は、今回の設計リスクとは別に、Copilot Cowork のサンドボックス環境から直接データを外部送信できる個別脆弱性を Microsoft に開示済みだとも述べています。本記事では公開情報と先行事例の文脈に基づいて、攻撃チェーン、設計上の核心問題、そしてエンタープライズ AI 導入における実務的含意を整理します。

Microsoft Copilot Cowork とは：M365 テナント全体に委任権限を持つエージェント

Microsoft Copilot Cowork は、Microsoft 365 の Frontier feature として現在提供されているエージェント機能で、ユーザーの Microsoft 権限で動作し、Microsoft Graph 経由でテナント内のデータを読み取り、操作することができます。一般的なチャットアシスタント型の Copilot とは異なり、エージェント型として複数ステップのタスクを自律的に実行し、メール送信や Teams メッセージ投稿といったアクションも実行可能です。Microsoft の公式ドキュメントによれば、Cowork は「メール送信や Teams へのメッセージ投稿といった機密性の高いアクションを実行する前に、ユーザーの承認を求める」と説明されています。本件で問題となるのは、この承認フローに対する重要な例外条件です。

Copilot Cowork は Skill と呼ばれる仕組みで機能拡張が可能です。Skill は OneDrive 上の特定パスから自動的に読み込まれる仕様になっており、PromptArmor のレポートによれば、管理者から見た Skill の運用統制は限定的です。ユーザーが Web で見つけた便利な Skill ファイルをそのまま OneDrive にアップロードして利用するケースは一般的に想定される利用パターンで、本件の攻撃チェーンはこの「外部から取得した Skill を信頼コンテキストに置く」習慣を起点としています。

核心的な設計欠陥：active user 宛のメッセージは承認なしで送信される

本件で最も重要な設計上の問題は、Microsoft のドキュメントで「機密アクション実行前に承認を求める」と謳われている内容と、実際の挙動の乖離です。PromptArmor の検証によれば、Copilot Cowork はメール送信および Teams メッセージ投稿について、受信者が active user（その Copilot Cowork を実行しているユーザー本人）の場合に限り、承認を求めずに即時実行する 動作を取ります。さらに、この挙動はユーザー側の設定で変更することができません。

「自分宛にメッセージを送るだけなら問題ないだろう」というのが本来の設計意図と推測されますが、攻撃者の視点ではこれが致命的な抜け穴になります。なぜなら、Teams や Outlook で受信したメッセージに含まれる外部画像タグは、ユーザーがメッセージを開いた瞬間に外部 URL への HTTP リクエストを発生させるためです。攻撃者はこの「自分宛メッセージは無承認で送信できる」「メッセージを開くと外部リクエストが発生する」という2つの仕様を組み合わせることで、ユーザー操作を最小限に抑えた状態で機密データを外部送信できる経路を構築できます。

攻撃チェーンの5段階

PromptArmor が実証した攻撃チェーンは次の5段階で構成されます。

  1. 被害者は SharePoint または OneDrive に PII や財務データを含むファイルを保有している。これは通常の業務環境では当然の状態です。
  2. 被害者が、プロンプトインジェクションを仕込まれた Skill ファイルを Copilot Cowork にアップロードする。攻撃源は Skill ファイル本体である必要はなく、Claude for Chrome 経由の Web データ、接続済み MCP サーバなど、Cowork が読み込む任意のデータが起点になり得ます。
  3. 被害者が「今週の作業内容をレビューして」のような自然な依頼を Cowork に投げ、Skill が起動する。これは Cowork の代表的なユースケースで、攻撃者はユーザーの自然な業務行動をトリガーとして利用できます。
  4. インジェクションが Copilot Cowork を操作し、Teams メッセージを active user 宛に投稿する。具体的には「ドキュメントプレビューを作成するサービスがある」と Cowork に伝え、Cowork に各ファイルの pre-authenticated download links を取得させ、悪性 HTML 画像タグの URL パラメータとして攻撃者制御サイトへ送信する内容のメッセージを作らせます。この間、人間の承認は一切要求されません。
  5. 被害者が Teams メッセージを開くと、pre-authenticated download links が攻撃者サーバへ送信され、攻撃者はリンクを訪問するだけでファイルをダウンロードできる。pre-authenticated download links は、リンクを持つ任意の主体がファイルをダウンロード可能な URL であり、Cowork はユーザー権限でこれを生成する能力を持ちます。

攻撃チェーン全体で人間の承認が要求されないことに加え、PromptArmor は 「Task complete」ブロックを展開しても悪意あるメッセージ内容は表示されない という可視性問題も指摘しています。Teams アクションのリンクをクリックしてもメッセージ本文は隠されたままであり、被害者が Cowork の動作を事後監査しようとしても、攻撃の痕跡を発見することは困難です。

モデル非依存性：Claude Opus 4.7 でも100%成功

本攻撃チェーンの検証は、当初 Microsoft Copilot Cowork のモデル選択を「auto」（Claude Opus 4.7 と Claude Sonnet 4.6 を動的にルーティングするモード）に設定して実施されました。PromptArmor はその後、モデルを Claude Opus 4.7 に明示的に指定して同じインジェクション でも検証し、攻撃が成立することを確認しています。さらに興味深いことに、Opus 4.7 を直接指定した場合、Cowork はより包括的に最近編集されたドキュメントを検索し、auto モードよりも多くのファイル（その週の以前の Cowork セッションで使用されたすべてのドキュメントを含む）を流出対象に拡張しました。

この事実が示すのは、本件は 特定のモデルの応答性能や安全機構の問題ではない ということです。最先端の AI モデルでも、Skill という信頼コンテキストに置かれた指示には従ってしまい、結果として攻撃者の意図通りに動作します。PromptArmor が強調しているのは、「これは Skill ファイルという untrusted data を trusted context に持ち込む構造そのものの問題」であり、モデル側の改善で完全に防御することは困難という認識です。

インジェクションの効率も極めて高く、PromptArmor は5回試行で5回攻撃チェーン全体を成功させており、攻撃の成立はユーザー側のクエリ文言の具体性に依存しませんでした。インジェクション本体は 81行の Skill ファイル中わずか5行、他の行と同等の長さで紛れ込ませることが可能でした。

Scheduled tasks がリスクをさらに拡大する

Copilot Cowork ではユーザーがスケジュールタスクを設定し、特定のプロンプトを定期実行することができます。「週次レビュー」のような業務上自然な定型タスクは、まさにスケジュール化される代表例です。スケジュールタスクが本件の攻撃面に与える影響は深刻です。なぜなら、ユーザーが実行時に同席していないため悪性ワークフローを止める機会がなく、プロンプトインジェクションが 繰り返し発火し続ける ことになるためです。一度悪性の Skill がアップロードされた状態で週次タスクが回り続ければ、毎週新しい機密ファイルが攻撃者サーバへ流出する経路が継続的に維持されます。

緩和策：SharePoint 側の BlockDownloadPolicy で爆発半径を制限する

本件に対する根本的な防御は、Microsoft Copilot Cowork のアーキテクチャ修正が前提となるため、現時点でユーザー組織が取れる対策は、攻撃の爆発半径を制限する方向の緩和策に限られます。PromptArmor が推奨する主な緩和策は、Microsoft エコシステム全体での過剰な権限付与の見直しと、SharePoint 側での pre-authenticated download links 取得の制限です。具体的には、SharePoint Online Management Shell から次のコマンドを実行することで、サイト単位またはセンシティビティラベル単位で BlockDownloadPolicy を有効化できます。

Set-SPOSite -Identity <SiteURL> -BlockDownloadPolicy $true

または、センシティビティラベルベースでの制御：

Set-Label -Identity <label> -AdvancedSettings @{BlockDownloadPolicy="true"}

ただし、Microsoft の公式ドキュメントによれば、この設定はファイルへのユーザー体験に大きな影響を与えます。BlockDownloadPolicy の対象ファイルでは、ユーザーはブラウザ経由でのみアクセス可能となり、ダウンロード・印刷・同期、および Word・Excel・PowerPoint を含む Microsoft 365 Apps からのアクセスができなくなります。業務影響と防御効果のトレードオフを組織として判断する必要があります。

なお PromptArmor は、本記事で公開した「設計上のリスク」とは別件として、Copilot Cowork のサンドボックス環境から直接データを外部送信できる脆弱性を Microsoft に開示済みだとも報告しています。こちらは個別バグであるため CVE 採番・パッチリリースの可能性がありますが、本記事で公開された設計問題については Microsoft が「これは個別バグではなく設計上のトレードオフ」と判断する場合、CVE が採番されず修正もされない可能性があります。

視点①：EchoLeak からの系譜と、Microsoft の CVE 採番姿勢

本件を理解するには、Microsoft Copilot 系製品で過去に発生した同種の脆弱性事例の系譜を踏まえる必要があります。最も重要な先行事例は EchoLeak（CVE-2025-32711、Microsoft（CNA）付与の CVSS 9.3 Critical） です。2025年6月に Aim Security が公開した EchoLeak は、Microsoft 365 Copilot に対する完全なゼロクリック・プロンプトインジェクション攻撃で、攻撃者が単にメールを送信するだけで、被害者の機密ファイルが攻撃者のサーバへ送信される脆弱性でした。Microsoft はこれに CVE を採番し、サーバサイドでの修正を緊急デプロイ済みです。EchoLeak は、本番運用中の AI システムでプロンプトインジェクションが具体的なデータ流出を引き起こした最初の既知事例として、業界に大きな衝撃を与えました。

次の節目は、2026年1月15日にパッチ展開された CVE-2026-21520（CVSS 7.5） です。NVD 公式記述では Copilot Studio における「情報漏えい（Exposure of Sensitive Information to an Unauthorized Actor）」として登録されており、NVD 自身の CVSS 評価は本稿執筆時点で未提供（CVSS 7.5 は他ソース寄与の値）です。一方、発見者である Capsule Security と VentureBeat の解説では、本件は SharePoint フォーム経由の 間接プロンプトインジェクション として位置付けられており、Capsule Security は本件を「ShareLeak」と命名しています。Capsule Security は Microsoft が本件に CVE を採番したことについて「エージェント構築プラットフォームの脆弱性に対する CVE 割り当てとして極めて異例（highly unusual）」と表現しています。エージェント型 AI への CVE 割り当てが業界として確立しつつあるシグナルとして注目されました。

これらの先行事例を踏まえた上で本件を見ると、Microsoft の対応姿勢に微妙な違いが現れる可能性があります。EchoLeak と CVE-2026-21520 はいずれも「個別の実装バグ」として CVE 採番・パッチ展開されましたが、PromptArmor が今回公開した内容は「active user 宛のメッセージ送信は承認不要」という 意図的な設計判断 であり、Microsoft がこれを「バグ」と認めるかどうかは別問題です。PromptArmor 自身が本記事を「個別バグの開示」ではなく「エンタープライズ全体に委任権限を持つエージェントを利用する際にユーザーが受け入れているリスクを知らせるため」と位置付けているのは、この点を意識した公開姿勢の表れと読めます。

視点②：エージェントの「委任権限」がもたらす攻撃面の構造変化

PromptArmor は本件について、「エージェントに複数システムへのアクセスを与えることは、プロンプトインジェクション攻撃面を拡大する」「単独で見ればエージェントの意図された能力は無害だが、統合されたシステムの特性により、ユーザーがリスクにさらされる」と評価しています。これは TKC Tech Lab がこれまで継続的に取り上げてきたいくつかのテーマと正確に重なります。記事 #20（Meta AI エージェント Sev 1 インシデント）では、エージェントが直接データを操作したわけではないにもかかわらずインシデント化された経緯を扱いました。記事 #25（Claude Chrome 拡張 ShadowPrompt）では、PromptJacking がブラウザ拡張という統合ポイントを攻撃面に変えた事例を扱いました。記事 #29（OpenClaw）、#30（Flowise）では、AI エージェントビルダー側の認可バイパスを扱いました。今回の Microsoft Copilot Cowork 事案は、これらの系譜の延長線上で、「テナント全体への委任権限を持つ業務エージェント」という新カテゴリでの実証された攻撃事例 として位置付けられます。

PromptArmor 自身、過去に Claude Cowork、Superhuman AI、Notion AI、Slack AI、Google Antigravity、IBM Bob、Snowflake Cortex、Ramp Sheets AI、GitHub Copilot CLI といった広範なエージェント型 AI 製品で同種の脆弱性を公開しています。これは Microsoft や Anthropic、Google といった個別ベンダーの問題というより、エージェント AI 製品カテゴリ全体に共通する設計上の課題 です。各社が「便利な統合機能」として実装している連携能力が、攻撃者の視点では「データ流出のための egress channel」として機能してしまうという構造的問題です。

実務的な含意

本件を受けて、Microsoft 365 環境で Copilot Cowork の導入を検討中または既に利用中の組織が取るべき実務的アクションは次の通りです。

  • Copilot Cowork の利用範囲と権限を再評価する。Cowork はユーザー権限で動作するため、ユーザーがアクセスできる SharePoint サイト、OneDrive ファイル、Teams チャンネルすべてが事実上 Cowork の攻撃面に含まれます。最小権限の原則に立ち戻り、特に経営層、財務、人事、法務など機密データを扱う部門での Cowork 利用は慎重に評価する必要があります。
  • Skill ファイルのガバナンスを確立する。Skill が OneDrive の特定パスから自動ロードされる仕様である以上、組織として「許可された Skill リスト」「外部 Web から取得した Skill のレビュープロセス」「Skill の変更検知」といったガバナンス機構を整備する必要があります。管理者側の Skill 監視機能は限定的というのが PromptArmor の指摘です。
  • センシティビティラベルベースの BlockDownloadPolicy 適用を検討する。組織全体での BlockDownloadPolicy 適用は業務影響が大きすぎる可能性が高いため、Confidential や Highly Confidential 等の高機密ラベルが付与されたファイルに限定して適用するアプローチが現実的です。
  • Scheduled tasks の運用ポリシーを明文化する。スケジュール化されたタスクは攻撃のリスク面を継続的に拡大するため、業務上必要なスケジュールタスクの一覧化、定期レビュー、新規追加時の承認フローを整備する必要があります。
  • EchoLeak 系の MSRC アドバイザリと CVE 公開を継続監視する。PromptArmor が別途 Microsoft に開示している「サンドボックス直接 egress 脆弱性」が今後 CVE 採番される可能性があります。Microsoft Security Response Center および Microsoft Update Guide での Copilot 系製品の脆弱性公開を定期的に確認するプロセスを整備しておくことが推奨されます。

所感：エージェント AI の「設計問題」をどう扱うか

本件で最も重要な論点は、技術的な攻撃チェーンそのものではなく、「これを Microsoft はバグとして扱うのか、設計トレードオフとして扱うのか」という対応姿勢にあります。EchoLeak と CVE-2026-21520 で示された通り、Microsoft は明確な実装バグとして識別されたプロンプトインジェクション脆弱性には CVE 採番とパッチを提供する姿勢を見せています。一方で、「active user 宛のメッセージは承認不要」という挙動は意図的な UX 上の判断である可能性が高く、Microsoft が修正対象とするかどうかは個別の判断になります。

PromptArmor は本記事をあえて「設計問題」として公開し、「個別バグ修正では解決できない構造的リスクを利用者に知らせる」というスタンスを取りました。これは責任ある開示の文脈で見ると一定の合理性がある選択ですが、同時に「ユーザーは設計上のリスクを受け入れた上で利用するべきだ」という負担をエンドユーザー組織に移転する効果も持ちます。エージェント AI 製品の安全性は、個別バグの修正速度だけでなく、「どこまでが許容される設計トレードオフで、どこからが修正すべき脆弱性か」というベンダー側の判断基準が業界として可視化されるかどうかに依存します。CVE-2026-21520 の「highly unusual」という形容詞が示す通り、業界はまだその境界線を模索している段階にあります。本件はその境界線をめぐる議論を一歩進める事例として、今後数か月の Microsoft 側の対応と業界の反応が注目されます。

主要ソース

一次ソース・公式情報

参考情報（先行事例）

slug: microsoft-copilot-cowork-prompt-injection-exfiltration

コメント

タイトルとURLをコピーしました