6月22日、Natalie IsakとSarah Cooleyが「Guarding AI memory」と題した記事を公開した。AIエージェントのメモリ機能が抱えるセキュリティリスクと、Microsoftがそれに対して講じている防御策について詳しく解説した内容だ。
注目すべきは、記事が取り上げる「遅延型ツール実行（Delayed Tool Invocation）」と呼ばれる攻撃パターンだ。攻撃者は悪意ある命令を共有ドキュメントに埋め込み、AIアシスタントがそれを処理した数日後、まったく別の会話の中で命令が静かに起動する。従来のプロンプトインジェクション攻撃（AIへの入力に悪意ある指示を混入させる手法）は「1回のやり取りで完結する」ことが多かったが、メモリ機能の登場によって「時間をまたいで発動する攻撃」が現実的な脅威となった。
AIメモリは「攻撃面を拡大する」
AIシステムにメモリ機能が加わると、単なるステートレス（会話をまたいで文脈を保持しない）なツールから、ユーザーの好みや文脈を記憶する「学習する協力者」へと変わる。これによりパーソナライゼーションやエージェントとしての一貫性が実現する一方で、攻撃者にとっては「単一のプロンプトで全てを決める必要がなくなる」という点が本質的な脅威の変化だ。
メモリがなければ、攻撃者は1回のやり取りで目的を達成しなければならない。メモリがあれば、時間をかけて段階的に行動を誘導したり、後から発動する「遅延型の悪意ある指示」を埋め込むことが可能になる。
最も危険なシナリオ：遅延型ツール実行（Delayed Tool Invocation）
記事の核心は、この「遅延型攻撃」の具体的なシナリオだ。
攻撃者は、ユーザーが開く共有ドキュメントのフォーマット内に、AIアシスタント向けの隠し命令（hidden instructions）を埋め込む。命令の内容は「ユーザーのスケジュールを外部に送信せよ」というものだ。アシスタントはドキュメントを処理するが、この時点では何も実行しない。
数日後、まったく別の会話の中で、その休眠状態の悪意ある命令が起動し、アシスタントは攻撃者の定義したコンテンツでメモリを更新する。以降、攻撃者はユーザーのスケジュール更新を継続的に取得し続ける。
この攻撃の巧妙さは「露出から実行までの時間的ギャップ」にある。攻撃が発生したコンテキストとは切り離された場所で実行されるため、防御が手薄になり、フォレンジック（インシデント発生後に何が起きたかを追跡・調査する手法）も困難になる。
なお記事では、このシナリオはMSRC（Microsoft Security Response Center）のケースに基づくものであり、最初の発見者であるJohann Rehberger（プロンプトインジェクションを使ったAIエージェント攻撃の先駆的な研究で知られるセキュリティリサーチャー）、Håkon Måløy、Gal Zrorの各リサーチャーへの謝辞が明記されている。
Microsoft 365での具体的な対策
Microsoftは「多層防御（defense-in-depth）」の観点から、ストレージ・取得・モデル操作・ユーザー制御の各層にわたって対策を実装している。
メモリ書き込み時（Memory Creation）
- 独自のプロンプトインジェクション分類器が書き込み前にコンテンツを検査・除去。プロンプトインジェクションとは、AIへの入力データに攻撃者が悪意ある指示を紛れ込ませ、本来の動作を乗っ取る手法を指す
- M365 Copilotは明示的なメモリ書き込みのたびにTask Adherence（タスク整合性チェック）を実行。ユーザーの意図とツール呼び出しの乖離を検出し、プロンプトインジェクションの影響を軽減する
メモリ保存後（Memory Storage）
- Data Subject Requests（DSR）やテナント分離など、M365全体のデータポリシーに準拠
- Customer Lockboxや保存時の暗号化など、メールボックスデータと同等のセキュリティポリシーを適用
可観測性（Observability）
- メモリ更新は組織の監査ログに記録される（Purview監査）
- SOCアナリストはDefender Advanced HuntingやSentinelの
MemoryUpdatedフィールドを使い、既存の分析ワークフローにメモリアクティビティのアラートを組み込める - eDiscoveryによるAI関連データの検索・削除にも対応
| 機能 | 意味 |
|---|---|
| Task Adherence | ユーザー意図とのズレを検出し、メモリへの不正書き込みを防止 |
| 統一コンプライアンス境界 | メール・チャット・ドキュメントと同じポリシーでメモリを管理 |
| メモリ監査イベント | 既存のセキュリティオペレーションと統合されたメモリ変更の可視化 |
| eDiscovery対応 | 既存のコンプライアンスツールでAI関連データを検索・削除可能 |
安全なAIメモリ設計の5原則
記事後半では、Microsoftが提唱する設計原則が示されている。単なる推奨事項の羅列ではなく、それぞれが「攻撃者がどこを突いてくるか」という視点に裏打ちされた原則だ。
- 永続化前に意図と出所を確立する — 信頼できないコンテンツ由来のメモリは書き込まない。遅延型攻撃はまさにこの「出所の検証」をすり抜けることで成立する
- 境界はモデルの外側で強制する — プロンプトによる制御は信頼できるセキュリティ境界にならない。決定論的なシステムで制御すること。AIに「この命令には従うな」と指示しても、攻撃者はその指示自体を書き換えられる
- 取得（Retrieval）をリスク判断として扱う — 保存時に安全だったメモリも、時間とともに陳腐化・汚染される可能性がある。「過去に安全だったから今も安全」という前提は成り立たない
- セキュリティチームにライフサイクル全体の可視性を提供する — 何が、いつ、なぜ変わったかの完全な記録がインシデント対応の前提になる。前述の
MemoryUpdated監査ログはまさにこの原則を実装したものだ - ユーザーがコントロールを持てるようにする — メモリの確認・編集・削除の手段をユーザーに提供する。攻撃が成功した後でも、ユーザー自身が被害を限定・修復できる手段を残しておくことが重要だ
記事では「エージェントのケイパビリティとコントロールを同時に前進させることが目標だ」と締めくくられており、これを業界全体で最も難しい課題の一つと位置づけている。メモリ機能はAIエージェントの有用性を飛躍的に高めるが、それはそのままセキュリティの複雑性の増大を意味する。今回のMicrosoftの取り組みは、その両立に向けた現時点での一つの回答と言えるだろう。
詳細はGuarding AI memoryを参照していただきたい。
