ネクストステップMCPセキュリティ:【第2回】コンテキスト汚染攻撃の全貌 - AIの記憶を狙う新たな脅威

## はじめに
[前回【第1回】](https://qiita.com/QueryPie/items/524f85cea4a53c21e5c4)では、MCP（Model Context Protocol）のアーキテクチャの深層を解析し、その内部構造と通信フローを詳細に解説しました。各コンポーネントの役割や連携から見える潜在的なセキュリティホールを洗い出し、アーキテクチャ設計段階で考慮すべき基本的なセキュリティ原則について触れました。

本稿【第2回】では、その基盤を踏まえ、MCPのセキュリティリスクの中でも高度かつ実務的に重要な攻撃手法の一つである「コンテキスト汚染攻撃（Context Poisoning Attack）」を取り上げます。プロンプトインジェクション攻撃を超える巧妙な手法として、AIのコンテキスト情報への不正なデータ注入により、AIの判断や推論を長期間にわたり歪める攻撃メカニズムと、その影響・リスク、検知・防御策について解説します。

## 1. コンテキスト汚染攻撃とは
#### 1.1 MCPにおける「コンテキスト」の定義と意義
MCPにおける「コンテキスト」とは、AIモデルが応答や推論を行う際に参照する周辺情報群の総称で、単発の対話履歴だけでなく、タスクの目的、利用者の嗜好や環境設定などの中長期的記憶情報を含みます。これが正確に管理されることで、MCPは柔軟かつ高度な応答が可能になります。

#### 1.2 コンテキスト汚染攻撃の概要
コンテキスト汚染攻撃とは、AIシステムの判断基盤であるコンテキスト情報に、攻撃者が悪意ある情報を意図的に挿入・注入する攻撃を指します。これによりAIの推論や行動が誤誘導され、誤情報の生成や不適切な意思決定が発生します。

この攻撃は、単純なプロンプトインジェクション（会話プロンプトの改ざん）を凌駕し、複数セッションにまたがって長期間にわたりAIの「記憶」を汚染する特徴があります。

## 2. コンテキスト汚染攻撃のメカニズム
#### 2.1 プロンプトインジェクションとの違い
プロンプトインジェクション攻撃は、対話入力の一部として悪意のある内容を埋め込み、直近の応答を狙う短期的な操作に限られます。一方、コンテキスト汚染攻撃では、AI内部のコンテキスト情報（長期記憶や共有バッファ）そのものを標的とし、汚染された情報が以降の多くの応答や推論に影響を及ぼす点で根本的に異なります。

OWASP LLMセキュリティプロジェクトによると、プロンプトインジェクションは「ユーザープロンプトがLLMの動作や出力を意図しない方法で変更する脆弱性」と定義されています [1]。これに対し、コンテキスト汚染攻撃は、より深層のコンテキストメモリを標的とする高度な攻撃手法です。

#### 2.2 攻撃フローの具体例
**悪意ある情報の段階的挿入**
攻撃者は、一度に大量の悪意あるデータを注入するのではなく、徐々に複数の通信やイベントに分散して細かく汚染情報を差し込みます。これにより、異常検知を回避します。

**長期記憶・コンテキストバッファへの蓄積**
MCPの設計上、コンテキストはセッション間で継続的に保存・参照されることが多く、汚染した情報が消去されずに残り続けるため、時間経過で被害が拡大しやすくなります。

**コンテキスト共有環境の悪用**
複数のAIインスタンスやユーザーセッションが同一コンテキストを参照している場合、一ヵ所で汚染が発生すると、他のすべてのインスタンスにその影響が波及します。

**潜伏型の攻撃**
汚染情報は一見無害に見えることも多く、影響が顕在化するまでに時間を要し、特定が困難です。

最近の研究では、Cross-Origin Context Poisoning (XOXO)という攻撃手法が報告されており、AIコーディングアシスタントにおいて、自動的に収集されるコンテキストを悪用して、セマンティクスを保持しながらも悪意のある出力を生成させる手法が実証されています [2]。

## 3. コンテキスト汚染攻撃による具体的リスク
#### 3.1 AI判断の誤誘導
汚染されたコンテキストはAIの意思決定根拠を歪め、誤った答えや指示を導きます。例えば、金融取引や医療診断支援といったクリティカルな分野では、誤った情報が重大な損失に直結します。

#### 3.2 不正操作・権限の誤付与
攻撃者が特定の権限情報や設定パラメータを汚染すると、AIが不正アクセスを許可したり制限すべき操作を実行したりする危険があります。

#### 3.3 監査・検知の難しさ
潜伏型で断続的な攻撃のため、ログ解析やアノマリー検知で気付かれにくく、攻撃開始から被害認識までに時間がかかることが多いです。

#### 3.4 記憶の永続化による被害拡大
従来のステートレスなアプリケーションとは異なり、AIエージェントの長期記憶機能により、汚染された情報が持続し、将来の意思決定に継続的に影響を与える危険性があります [3]。

![3. コンテキスト汚染攻撃による具体的リスク - visual selection.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4058228/cf01e664-2f31-44f6-8803-de26034d282d.png)

## 4. コンテキスト汚染攻撃の検知と防御策
#### 4.1 コンテキストデータの整合性検証
**ハッシュ署名の導入**
コンテキスト保存時に暗号学的ハッシュやデジタル署名を付加し、改ざんを検知可能にします。MCPパッケージ検証システムでは、各パッケージが暗号学的に署名され、パッケージの元の状態の不変の「指紋」を作成する手法が採用されています [4]。

**変更履歴のログ記録**
コンテキスト更新には全履歴を記録し、誰がいつ何を変更したかを追跡可能とします。

#### 4.2 コンテキスト管理の強化
**アクセス制御の厳格化**
コンテキスト更新は信頼された主体に限定し、多要素認証などの保護を付加。

**コンテキストの最小化**
セッションに必要な最小限のコンテキストのみを保持し、不必要な拡散を防ぐ。

**セッション分離とタイムアウト**
明確なコンテキスト境界を定義し、セッション分離と時間制限付き保持を実装します [5]。

#### 4.3 定期的なコンテキストのリセットと再評価
**タイムアウト・リフレッシュ機能**
コンテキストを一定期間ごとにリセットまたは再評価し、汚染を一掃できる仕組みを設計に組み込む。

**AIの推論結果モニタリング**
コンテキストに基づく出力の異常検知を行い汚染の兆候を早期に発見。

#### 4.4 高度な検知システム
**動的行動監視**
静的解析を超えて、実行時の悪意ある行動を検知するシステムの導入 [6]。

**メモリ保護メカニズム**
メモリの暗号化と整合性検証、アクセス制御の実行 [5]。

![4. コンテキスト汚染攻撃の検知と防御策 - visual selection.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4058228/325962af-c6f6-4cef-b579-db9374f46588.png)

## 5. MCP設計・運用における実践的要点
#### 5.1 アーキテクチャ設計段階からの対策
**コンテキストの「信頼チェーン」を確立**
データ改ざんを検知できる設計にする。

**コンテキスト書き込み・更新権限を厳密に管理**
変更ごとに正当性を検証。

**モジュール間の権限分離（セキュアなアクセス制御）を徹底**
セキュアなアクセス制御を徹底。

#### 5.2 運用段階での監査とモニタリング
**コンテキスト管理ログの自動収集・分析ツール導入**
包括的なログ収集と分析システムの構築。

**アノマリー検知エンジンによる継続的監視**
機械学習ベースの異常検知システムの導入。

**不審なコンテキスト変化時の迅速なアラート・対応フローの策定**
インシデント対応プロセスの確立。

#### 5.3 入力検証とサニタイゼーション
**厳格な入力検証**
コンテキストに注入される全てのデータに対する検証。

**コンテキスト分析とセグメンテーション**
入力クエリを論理的セグメントに分割し、悪意のあるコマンドや文脈の注入を防止 [7]。

**境界の明確化**
内部コンテンツと外部コンテンツの明確な境界を設定 [7]。

![5. MCP設計・運用における実践的要点 - visual selection.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4058228/2749b222-a066-47bf-895b-d9b6b1a674a5.png)

## 6. 実装における技術的考慮事項
#### 6.1 暗号学的保護
**デジタル署名による完全性保証**
各コンテキストデータにデジタル署名を付与し、改ざんを検知。

**暗号化による機密性保護**
コンテキストデータの暗号化による不正アクセス防止。

#### 6.2 メモリ安全性
**メモリ安全言語の採用**
Rustなどのメモリ安全言語の使用、またはWebAssembly (Wasm)サンドボックスなどの安全な実行環境の利用 [3]。

**サンドボックス化**
エージェントコンポーネントの分離とメモリ破損や実行時改ざんの防止。

#### 6.3 検証可能なツールレジストリ
**不変レジストリの構築**
ブロックチェーンや署名付きマークルツリーを使用した改ざん不可能なツールレジストリの維持 [6]。

**バージョン管理と完全性チェック**
承認されたツール、そのバージョン、対応する暗号学的ハッシュまたは署名の安全な管理。

![6. 実装における技術的考慮事項 - visual selection.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4058228/7bb99db2-015b-4e10-a939-3edbef9db897.png)

## まとめ
本稿では、MCPの核心的資産であるコンテキストへの不正なデータ注入を狙う「コンテキスト汚染攻撃」について、その仕組みとリスクを事実ベースで解説しました。従来のプロンプトインジェクションより深刻で検知困難なこの攻撃は、AIシステム全体の信頼性に直結しています。したがって、コンテキストの整合性検証、アクセス制御強化、定期的な再評価など多層的な防御が求められます。

特に重要なのは、設計段階からのセキュリティ組み込み、暗号学的手法による完全性保証、そして継続的な監視体制の構築です。これらの対策を適切に実装することで、コンテキスト汚染攻撃のリスクを大幅に軽減できます。

次回【第3回】では、MCPの通信プロトコルレベルに潜む脆弱性を詳細に分析し、メッセージフォーマットの悪用やセッション管理の不備について技術的に掘り下げていきます。ご期待ください。

## 参考文献
[1] OWASP Gen AI Security Project. "LLM01:2025 Prompt Injection". https://genai.owasp.org/llmrisk/llm01-prompt-injection/ (参照日: 2025年6月19日).

[2] arXiv. "Stealthy Cross-Origin Context Poisoning Attacks against AI Coding Assistants". https://arxiv.org/html/2503.14281v1 (参照日: 2025年6月19日).

[3] arXiv. "Securing Agentic AI: A Comprehensive Threat Model and Mitigation Strategies". https://arxiv.org/html/2504.19956v1 (参照日: 2025年6月19日).

[4] BytePlus. "MCP Package Verification: Secure Installation & Best Practices". https://www.byteplus.com/en/topic/541971 (参照日: 2025年6月19日).

[5] XenonStack. "Mitigating the Top 10 Vulnerabilities in AI Agents". https://www.xenonstack.com/blog/vulnerabilities-in-ai-agents (参照日: 2025年6月19日).

[6] arXiv. "Enterprise-Grade Security for the Model Context Protocol (MCP)". https://arxiv.org/html/2504.08623v1 (参照日: 2025年6月19日).

[7] Sprocket Security. "How Prompt Injection Works & 8 Ways to Prevent Attacks". https://www.sprocketsecurity.com/blog/prompt-injection (参照日: 2025年6月19日).