10月13日、GBhackersのDivyaが「Researchers Discover 253 Security Vulnerabilities Across 343 AI Agent Tools in MCP Servers」と題した記事を公開した。AIエージェント基盤として急速に普及するMCPサーバーのツール実装に、深刻なセキュリティ上の欠陥が大量に存在することを示した研究を紹介している。

118件のMCPサーバー、343ツールで253件の脆弱性

ペンシルバニア州立大学・モンペリエ大学・ダートマス大学の研究者らが、273件のオープンソースMCPサーバー（計3,405ツール）を対象にセキュリティ評価を実施した。その結果、118サーバー・343ツールで253件の脆弱性が確認された。研究論文「ToFu: Exploiting and Fuzzing the LLM–Orchestrator–Tool Trust Boundary」としてarXivで公開されている。

MCP（Model Context Protocol）は、LLMが外部ツールを呼び出すための標準インターフェースとして、AnthropicのClaudeをはじめ各種AIエージェント実装で採用が広がっている。「LLMに外部機能を持たせる」アーキテクチャが現実の本番環境に展開され始めたタイミングで、その信頼境界に根本的な問題があることが示された。

確認された脆弱性の種類は以下のとおりだ。

• 任意パストラバーサル（arbitrary path traversal）
• ログインジェクション（log injection）
• データ流出（data exfiltration）
• コマンドバイパス（command bypass）

「スキーマが正しければ安全」という前提が崩れる

研究の核心は、LLMが生成した引数をツール実装が無条件に信頼してしまうという構造的問題にある。

AIエージェントは通常、「LLM → オーケストレーター → ツール」という流れで動作する。LLMがツールの説明とスキーマを受け取り、構造化されたリクエストを生成し、オーケストレーターがそれを実行する。問題は、フォーマットが正しいからといって、その引数が安全とは限らない点だ。

研究者らはこれを「Repeat-After-Me攻撃」で実証した。攻撃者がターゲットのツール名と引数を含むテキストを提供し、モデルにそれを再現させる。すると出力がオーケストレーターの認識するフォーマットと一致し、通常のテキストではなく実行可能なツール呼び出しとして誤解釈される。

この挙動は以下の6つのオーケストレーションフレームワークで再現された。

• LangGraph
• Microsoft MAF（Microsoft提供のマルチエージェント基盤フレームワーク）
• Google ADK 2.0（Google提供のエージェント開発キット。公式ドキュメント）
• AutoGen
• AWS Strands
• CrewAI

主要フレームワーク全般にわたる問題であることがわかる。

ToFu：ツールのメタデータ自体をテストケースに変換するファジング手法

ToFuの処理概要（出典: arXiv）

研究チームが開発したファジングフレームワーク「ToFu」は、ツールのメタデータをそのままセキュリティテストの入力として活用する点が特徴的だ。

従来のクラッシュベースのファジングは、例外や異常終了をトリガーに脆弱性を検出する。しかし、パストラバーサルのように実行が成功してしまう違反は検出できない。「ワークスペース外のファイルを読み込んでも、処理自体はエラーなく完了する」といったケースがこれに当たる。

ToFuは74個のセマンティクス対応サニタイザーを備え、引数の意味（ファイルパス、URL、SQLクエリなど）に応じた適切なチェックを自動選択する。チェック内容はCWE（共通脆弱性タイプ一覧）に準拠する。スキーマ上は同じ「文字列型」でも、ファイルパスとSQLクエリでは必要なセキュリティチェックが異なる、という点を明示的に扱う。

LLMはメタデータの解釈と初期テストシードの生成に使われるが、脆弱性の判定はLLMではなく実行可能なサニタイザーが行う。カバレッジガイドファジングにはAtheris（Googleが開発するPython向けカバレッジガイドファジングエンジン）を利用し、ツールの内部実装が参照できる場合はファイルシステム・プロセス・ネットワーク操作をランタイムトレーサーで監視する。

問題の本質：ツールの説明と実装のズレ

研究が指摘する根本的な問題は明快だ。ツールのドキュメント（説明）が、実際のコードの動作と一致していない。「特定のワークスペース内のファイルのみアクセスする」と説明されているツールが、実装ではその制約を強制していない、というケースが多数見つかった。

論文の結論は、実装者へのシンプルな指針に収まる。ドキュメントに記載した制約を実行時に必ず強制すること、そしてスキーマ適合の引数であっても、信頼できない入力として扱うことの2点だ。プロンプトフィルタリングやモデル側の改善は、ツール実装内のセキュリティチェックの代替にはならない。ファイルシステム、ネットワーク、コマンド操作を行うソフトウェア側で、入力を適切にサニタイズする必要がある。

MCPの普及によってAIエージェントと外部システムの接点は急速に広がっている。今回の研究は、その接点における信頼モデルの見直しを、フレームワーク開発者・ツール実装者の双方に促すものといえる。

詳細はResearchers Discover 253 Security Vulnerabilities Across 343 AI Agent Tools in MCP Serversを参照していただきたい。