3行でいうと

  • ツールの説明文はモデルにとって「読む文章」です。そこに隠された指示が、利用者に見えないまま働く事例が公開されています。
  • 公式仕様は、ツールを任意のコード実行に等しいと扱い、実行前の同意を求めています。見知らぬサーバーは、手元のコードを動かすのと同じ重さです。
  • 対策の中心は、権限を最小にする、人の承認を残す、隔離する、信頼できる提供元に限る、の4つです。

この記事は、実際に使って確かめた記録ではありません。この記事は公式の文書や論文を読んでまとめたものです。また、攻撃の手順は書きません。何が起きうるかと、どう備えるかに絞ります。

先に結論

前提：用語を先にそろえる

何が起きうるか：公開された5つの型

1. ツール汚染（説明文に仕込まれた指示）

Invariant Labs（セキュリティ会社）は、2025年4月1日の記事で次の実験を公開しました。2つの数を足すだけの偽のツールの説明文に、AIへの指示を隠し、Cursor（コーディング用のAIアプリ）で試した、という内容です。AIが利用者の設定ファイルや秘密鍵を読み、ツールの引数に載せて悪意あるサーバーへ送った、と書かれています。

記事の指摘で重要なのは、見え方の差です。利用者の確認画面には、簡略化されたツール名しか出ず、引数の全体は見えません。モデルには説明文の全文が見えます。記事は、Cursorが拡張表示でも入力の全体を見せなかった、としています。ほかのAIアプリでも、説明文を適切に検証・表示しなければ同じことが起きうる、というのが記事の主張です。

2. ラグプル（承認したあとで中身が変わる）

同じ記事は、サーバーが、承認された後にツールの説明文を書き換える可能性を挙げています。最初に信頼して入れたサーバーでも、後から危険になりえます。

3. シャドーイング（別のサーバーの振る舞いを変える）

複数のサーバーをつなぐと、AIはすべての説明文を同時に読みます。同記事の実験では、悪意あるサーバーの説明文が、信頼できるメール送信ツールの使い方を書き換え、宛先を攻撃者に変えました。攻撃者のツールを実際に呼ばせなくても、他のツールの挙動を変えられる、と記事は述べています。

4. 正規のツールを通じた情報の持ち出し

Invariant Labsの2025年5月26日の記事は、GitHubのMCPサーバーでの例を示しています。攻撃者が公開リポジトリに悪意ある課題（issue）を書き、利用者のAIが「未対応の課題を見て」と頼まれて読むと、非公開リポジトリの情報を引き出して公開側の変更依頼（プルリクエスト）に書いてしまう、という流れです。記事は、ツール自体は侵害されておらず、これは設計上の問題でありサーバー側の修正だけでは解決しない、としています。また、確認画面が出ても、利用者が「常に許可」を選ぶことが多く、監視が弱まる点を挙げています。

5. 実装の欠陥（CVE）

どちらも修正済みの版があります。ここで押さえておきたいのは、MCP周辺の道具そのものが攻撃の入口になった実例だ、という点です。

公式は何と言っているか

MCPの仕様

MCP公式仕様の「Security and Trust & Safety」は、要点を次のように書いています。

ツールの仕様のページには、安全のための推奨が並びます。人が拒否できる状態を必ず作ること（SHOULD）、ツールの入力を呼ぶ前に利用者へ見せて、意図しない流出を防ぐこと（SHOULD）、結果をモデルに渡す前に検証すること（SHOULD）。サーバー側には、入力の検証、アクセス制御、呼び出しの速度制限、出力の無害化がMUST（必須）です。

安全のベストプラクティスのページは、次を攻撃として扱っています。

OWASPの「MCP Top 10」

OWASP（Webなどの安全に関する非営利の団体）は、MCP向けの10項目のリストを出しています。公式ページは、プロジェクトがベータ段階（ロードマップ上の「Phase 3」）にあるとしており、版の番号や日付は書かれていません。項目は次の10個です（見出しの意訳）。

ID 項目
MCP01 トークンの管理不備と秘密情報の露出
MCP02 権限の少しずつの肥大による昇格
MCP03 ツール汚染
MCP04 ソフトウェア供給網の攻撃と依存関係の改ざん
MCP05 コマンドの注入と実行
MCP06 文脈に埋め込まれた内容によるプロンプトインジェクション
MCP07 認証・認可の不足
MCP08 監査と記録の欠如
MCP09 無許可のMCPサーバー（シャドーMCP）
MCP10 文脈の混入と共有しすぎ

OWASPの「LLMアプリ向けTop 10（2025年版）」のLLM06 Excessive Agency（過剰な裁量）は、危険の根を3つに分けています。機能が多すぎる、権限が多すぎる、人の確認なしに大きな行動をとる自律性が高すぎる、の3つです。対策として、拡張（ツール）の数を絞る、シェルやURL取得のような何でもできるツールを避ける、利用者本人の最小権限で動かす、影響の大きな操作は人が承認する、下流の側でも許可を確かめる、が挙がっています。ログや速度制限は、被害を抑えるが予防にはならない、との整理です。

各社の公式ガイドに書かれていること

Claude Code（Anthropic）：セキュリティの頁は、MCPについて「自分で書くか、信頼できる提供元のサーバーを使うよう勧める」と書いています。Anthropicは、掲載の基準に照らしてコネクタを審査するが、MCPサーバー自体の安全監査や管理はしない、とも明記しています。プロジェクトの.mcp.jsonにあるサーバーは、対話の起動時に承認を求められます。ただし、非対話の実行（claude -p、Agent SDK、プロジェクトのスレッド以外のクラウドのセッション）ではこの確認が出ずに読み込まれると書かれています。MCPの頁には「各サーバーを信頼できるか確認すること。外部の内容を取得するサーバーは、プロンプトインジェクションの危険にさらす」とあります。組織向けには、許可・拒否するサーバーを管理設定で絞る方法が用意されています。

OpenAI：エージェント構築の安全の頁は、リスクとしてプロンプトインジェクションと、攻撃者がいなくても起こる「私的データの意図せぬ漏えい」を挙げています。後者について、モデルが何をMCPに送るかは完全には制御できない、と書かれています。対策の中心は、MCPツールの承認を有効にしておき、読み取りも書き込みも利用者が確認すること、信頼できない入力を開発者メッセージに入れないこと、ノード間で構造化された出力（列挙型など、自由記述を許さない形）を使うこと、ガードレールを第一の層として置くこと、です。ガードレールは万全ではない、とも書かれています。同じ頁に、Agent Builderを2026年11月30日に終了する予定、という記載があります。

Google Cloud：MCPのAI安全の頁は、エージェントの識別子を作り最小権限を与えること、データと指示を分けること、MCPの呼び出しと応答をModel Armorで検査すること、使えるツールを絞ること、IAMで組織・プロジェクト・フォルダ単位でMCPの利用を制限すること、本番の資源には読み書きを拒否する方針（deny policy）を使うことを挙げています。リスクとしては、信頼したMCPサーバーが黙ってツールを追加する「動的ツール」、人の承認での誤り、取り消せない変更などを挙げています。

対策の組み立て方

見立てです。上の資料を並べると、守りは4つの層にまとめられると思います。どれか1つで足りるとは、どの資料も言っていません。

  1. 入れるものを絞る：見知らぬサーバーを入れない。入れるなら、提供元、更新の履歴、要求する権限を確かめる。MCPの仕様やOWASPが挙げる供給網の問題は、ここで効きます。
  2. 渡す権限を絞る：読み取り専用の通行証から始める。範囲は必要になってから広げる。1つのセッションで、触れるリポジトリや資料を限る（Invariantの記事の提案）。
  3. 人の承認を残す：書き込み、送信、削除、支払いは確認を挟む。「常に許可」は、影響の小さい操作に限る。
  4. 隔離と記録：コンテナやVMの中で動かす。ネットワークの出口を絞る。ツールの呼び出しを記録する（OWASP MCP08、MCPの仕様のクライアント向けの推奨）。

もう1つ。見立てです。ツール汚染は「説明文を読ませない」ことでは防げません。説明文がモデルの入力である以上、読ませないと使えないからです。だから、承認画面でツールの入力の全文を見られること、説明文が変わったら再承認になること、がクライアントを選ぶときの確認点になると思います。この2点を各クライアントが満たしているかは、僕らは確認できていません。

よくある失敗・つまずき

見立てです。公開された資料から、起きやすいと思う点を挙げます。

気をつけること

出典

更新履歴