MCPサーバーのセキュリティ。AIエージェントとツール接続の信頼境界

MCP（Model Context Protocol）は、AIアプリやAIエージェントを外部のツールやデータへ標準的な方法でつなぐオープンなプロトコルです。接続が容易になった分だけ、AIが読み込む情報と実行できる操作が増え、攻撃者が入り込む経路も広がりました。この記事では、MCP固有の信頼境界とツール接続に絞って、代表的な脅威と、利用者や開発者、組織それぞれが取れる防御を整理します。本稿は執筆時点（2026年7月）のMCP公式仕様（2025-11-25版）と、公開されている研究や実装検証を分けて参照します。仕様が定める要件と、研究者による観測や個別実験の結果は区別して扱います。

全体像をつかむ早見表#

MCPの脅威は、どこから指示や権限が入り込み、何が奪われるのかで対策の置き場所が変わります。細部に入る前に、代表的な脅威と、それが起きる機構、主な対策の対応を先に並べます。

以降で、それぞれの機構を仕組みから見ていきます。

MCPが何と何をつなぐ仕組み#

MCPはクライアントとサーバーの構成をとります。公式のアーキテクチャ解説では、AIアプリであるMCPホストが一つ以上のMCPサーバーへ接続し、その接続ごとにMCPクライアントを一つずつ作る、と説明されています。ホストの例としてClaude DesktopやVisual Studio Codeが挙げられており、たとえばVisual Studio CodeがファイルシステムのサーバーとSentryのサーバーに同時につなぐと、接続の数だけクライアントが作られます。MCPを「AIアプリ向けのUSB-Cポート」にたとえる説明があるとおり、狙いは接続方法の標準化です。

サーバーが公開するものは三つの基本要素に整理されています。AIが呼び出して操作を行うツール、文脈として読み込ませるデータであるリソース、対話のひな型であるプロンプトです。クライアントはまず一覧を取得してツールを見つけ、その後に呼び出します。通信はJSON-RPC 2.0を土台にし、ローカルで動くサーバーは標準入出力を使うstdioトランスポート、遠隔のサーバーはStreamable HTTPトランスポートを使います。認可は仕様上は任意で、HTTPベースのトランスポートで認可を実装する場合に、MCPのAuthorization仕様（OAuthベース）に従うことが推奨されています。標準入出力を使うローカルのサーバーは、この認可仕様の対象ではありません。

MCP公式のアーキテクチャ解説では、MCPホストが接続ごとにMCPクライアントを作り、サーバーがツールとリソースとプロンプトの三つの基本要素を公開すると定義しています（執筆時点）。

ここで押さえておきたいのは、AIアプリが複数のサーバーへ同時につながり、そのツール群を一つのまとまりとしてモデルに提示するという構造です。複数サーバーのツールを同じモデル文脈でまとめて扱い、サーバー間のデータフロー制御がない構成では、接続先の一つに信頼できないサーバーが混ざると、その影響が他のサーバーへの操作にまで及ぶ余地が生まれます。

攻撃面が広がる理由#

MCPで攻撃面が広がる理由は、大きく三つの機構に分けられます。

一つ目は、ツールの説明文やメタデータがモデルへの入力になることです。クライアントは各ツールの名前や説明、入力スキーマを取得してモデルに渡し、モデルはその説明を「そのツールが何をするか」の根拠として読みます。つまり説明文は単なるドキュメントではなく、モデルの判断材料そのものです。ここに攻撃者が指示を紛れ込ませると、モデルはそれを正規の手順の一部と受け取ってしまいます。

二つ目は、モデルが命令とデータを同じ自然言語として受け取る、という言語モデル共通の性質です。メッセージのロールや構造化によって形式上は分けられても、ツールの戻り値や読み込んだ外部データの中に紛れた指示を、モデルが常に正しく無視できる保証はありません。この性質はプロンプトインジェクション一般の根にあるもので、MCPはそれをツール接続という形で持ち込みます。仕組みの詳しい整理は関連記事にまとめています。

三つ目は、MCPサーバーへ委譲した権限とトークンが、そのまま被害の上限を決めることです。エージェントにファイル操作や外部通信、コマンド実行を任せているほど、乗っ取りが成立したときにできることが増えます。攻撃手法そのものより、与えた権限の広さが被害の大きさを左右する、という関係はMCPでも変わりません。

代表的な脅威#

MCPに固有の脅威を、公式のセキュリティ指針と研究の指摘をもとに四つに分けて見ていきます。攻撃の仕組みに触れるのは防御のためです。動作の検証は自分が管理を許された環境だけで行い、他者のシステムやアカウントへ無断でアクセスする行為は不正アクセス禁止法などに触れる可能性があります。

ツールポイズニングと隠された指示#

ツールポイズニングは、ツールの説明文の中に、利用者には見えずモデルには見える指示を埋め込む攻撃です。この名称はセキュリティ企業のInvariant Labsが2025年に整理したもので、同社は無害に見える計算ツールの説明文に、SSHの鍵や設定ファイルを外部へ送らせる指示を隠した例を示しています。多くのクライアントがツールの引数や説明を簡略化したUIでしか表示しないため、利用者は隠された指示に気づかず、モデルだけがそれを読んで従う、という非対称が生まれます。

Invariant Labsは、ツールポイズニングを「ツールの説明文に埋め込まれた、利用者には見えずAIモデルには見える悪意ある指示」と説明し、簡略化されたUIの裏に指示が隠れると指摘しています（執筆時点）。

この攻撃が厄介なのは、利用者がツールを普通に使っているつもりでも、モデルが説明文の指示に従って別の操作を実行してしまう点です。研究でも、悪意あるツール定義がエージェントを誘導し、機微なデータの持ち出しや他のツールの乗っ取りに至りうると指摘されています。

ツールの戻り値やメタデータ経由の間接プロンプトインジェクション#

ツールポイズニングは、外部から来た指示が発動する間接プロンプトインジェクションの一種として捉えられます。指示の入口は説明文だけではありません。ツールが返す戻り値や、ツールがWebやファイルから取り込んだ内容にも、攻撃者があらかじめ指示を仕込めます。エージェントがその戻り値を読み、次の行動を決める段でその指示に従うと、要約や検索のつもりが情報送信や設定変更に化けます。

このリスクは、MCPが広まった初期から公開の場で議論されてきました。たとえば技術者のSimon Willison氏は2025年4月の記事で、MCPが強い権限を持つツールと信頼できない入力を組み合わせる以上、プロンプトインジェクションの問題を避けて通れないと述べています。攻撃者が人間をだますのではなくAIの判断をだます点で、これはソーシャルエンジニアリングをAIに向けたものと見ると理解しやすいでしょう。

過剰な権限とOAuthトークンの取り扱い#

ここで扱う権限は、大きく四つの層に分かれます。クライアントからMCPサーバーへのアクセス（MCPのAuthorizationトークン）、MCPサーバーが下流のAPIへ使う資格情報、ローカルで動くサーバープロセスのOS権限、そしてモデルによるツール呼び出しの承認です。それぞれ別の信頼境界なので、層ごとに最小化します。とくにMCPサーバーやトークンに広いスコープを与えると、乗っ取り時の被害範囲が広がります。公式のセキュリティ指針は、あらゆるスコープを最初にまとめて渡す設計を避け、低リスクな読み取りなどの最小限から始めて、必要になった時点で段階的に権限を上げる最小権限の方針を勧めています。広いトークンが漏れたときに、無関係なツールやリソースへ横断的に手が届いてしまう事態を抑えるためです。

トークンの扱いでは、素通し（token passthrough）が明確に禁じられています。これは、MCPサーバーがクライアントから受け取ったトークンを、自分宛てに発行されたものか検証せずに下流のAPIへそのまま渡す設計を指します。公式仕様は、この構造がレート制限や監査などの制御を回り込ませ、盗まれたトークンでサーバーがデータ持ち出しの踏み台にされうるとして、自分宛てに発行されたトークン以外を受理してはならないと定めています。

MCP公式のセキュリティ指針は、MCPサーバーが自分宛てに発行されたトークン以外を受理してはならないとし、トークンの素通しを禁止しています（2025-11-25版）。

OAuthのプロキシを挟む構成では、混乱した代理（confused deputy）と呼ばれる問題も指摘されています。静的なクライアントIDと動的なクライアント登録、同意クッキーが重なると、攻撃者が同意画面を回り込んで認可コードを奪える、という筋です。公式仕様はこれを防ぐため、サードパーティの認可へ進む前に、クライアントごとの同意をサーバー側で確認する実装を求めています。トークンや鍵などの認証情報を安全に持つ考え方は、関連記事も参考になります。

信頼できないサードパーティサーバーとrug pull#

MCPサーバーは誰でも作れて配布できるため、提供元が不明なサーバーや、悪意を持って作られたサーバーが紛れ込む余地があります。ローカルで動くサーバーは利用者の端末で任意のコマンドを実行できるため、公式仕様は、起動コマンドの内容を省略せず表示して明示的な同意を取ることや、サンドボックスで最小権限にすることを勧めています。

さらに警戒すべきなのがrug pullです。Invariant Labsは、MCPサーバーがクライアントに一度承認された後でツールの説明文を書き換えられると指摘しています。利用者が最初は信頼したサーバーでも、後からの変更で悪意ある指示を注ぎ込めるため、PyPIなどで見られる後出しのサプライチェーン攻撃と同じ構図です。同社は対策として、ツールの定義を利用者にはっきり見せること、ハッシュやチェックサムでサーバーとツールのバージョンを固定して無断の変更を防ぐこと、サーバー間の境界を厳しくすることを挙げています。

こうした後出しの挙動変更は、依存先の信頼をどう保つかという、サプライチェーン全般の問題と地続きです。取り込む部品や接続先の管理という観点は、関連記事で整理しています。

利用者ができる防御#

MCPを使う利用者が現実に取れる対策は、接続するサーバーの吟味と、承認の運用に集約されます。

承認を省略しない運用は前提ですが、それだけでは不十分です。Invariant Labsの実験では、承認画面が出ても完全な引数や持ち出し先のデータが表示されず、利用者が危険を判断できなかった例が示されています。確認のステップを自動で通す設定は避けたうえで、正確な引数と送信先や変更差分を表示できるクライアントを選び、権限の分離、データフローの制御、サンドボックス化を併せて用います。人間の承認は多層防御の一枚であって、単独の防壁ではありません。

開発者と組織が備えること#

サーバーやクライアントを作る側、そしてエージェントを組織で使わせる側は、公式のセキュリティ指針を設計の物差しにできます。

公式仕様は、悪意あるサーバーがOAuthの探索でクライアントに内部アドレスへ通信させるSSRFや、推測されやすいセッションIDを使うことによるセッション乗っ取りといった攻撃も具体的に挙げ、それぞれに対策を示しています。設計の初期から、境界を越えた通信の遮断とセッションの堅牢化を織り込んでおくと、後からの手当てより漏れが少なくなります。

MCP公式のセキュリティ指針は、混乱した代理、トークンの素通し、SSRF、セッション乗っ取り、ローカルサーバーの侵害、スコープの最小化を攻撃と対策の組として整理しています（2025-11-25版）。

AIを攻撃の道具として使う動きと、AIそのものを狙う動きは地続きです。攻撃者がAIをどう悪用しうるかの整理は、関連記事も参考になります。

まとめ#

MCPは、AIエージェントを外部のツールへ標準的につなぐことで利便を大きく広げ、その同じ経路で攻撃面も広げました。ツールの説明文がモデルへの入力になること、命令とデータを区別できないこと、委譲した権限がそのまま被害の上限になることという三つの機構を押さえれば、対策の置き場所は見えてきます。防御の重心は、接続先とツールの固定、権限とトークンの最小化と検証、高リスク操作への人間の承認というシステム側の設計です。最新の仕様はMCPの一次情報で版と時点を確かめながら、設計の物差しとして使っていきましょう。