MCPセキュリティ対策チェックリスト25項目：脅威モデルと本番運用の守り方【2026-07-28仕様対応】

最終更新：2026年10月13日／対象：MCP仕様 2026-07-28版（認可・セキュリティベストプラクティス）、OWASP MCP Top 10（2025年版リスト、ベータ）

結論（30秒で読める要約）

MCPセキュリティとは、AIエージェントが使うツールを「誰が呼べるか」「どのツールまで呼べるか」「サーバーがどこへ通信できるか」を制御し、あとから「何が起きたか」を証明できる状態にすることです。やるべきことは次の6層に整理できます。

すべてのリクエストを認証する。リモートサーバーはMCP仕様のOAuth 2.1ベースの認可に従い、トークンは毎回 Authorization ヘッダーで送ります。URLのクエリに載せるのは仕様上MUST NOTです。
トークンを1つのサーバーに紐づける。クライアントはRFC 8707の resource パラメーターを必ず送り、サーバーは自分宛てでないトークンを拒否します。トークンの素通し（token passthrough）は明確に禁止されています。
権限はサーバー単位ではなくツール単位で切る。最小限のスコープで始め、危険なツールを初めて使うときに 403 insufficient_scope で追加の権限を求めます。
ツールの説明文と出力は信用しない入力として扱う。tool poisoningやプロンプトインジェクションはサーバー側だけでは防ぎきれないので、乗っ取られても被害が小さい設計にします。
入れるサーバーを確かめ、バージョンを固定する。実際に見つかった最初の悪意あるMCPサーバー（postmark-mcp 1.0.16、2025年9月）はnpm経由でした。
分離・Egress制限・ログ。サンドボックス化した実行環境、暗号化したシークレット、IP許可リスト、送信先の許可リスト、そして「どのツールが呼ばれたか」を残すリクエストログを用意します。

9章のチェックリスト（25項目）を使えば、今動いているサーバーをその場で点検できます。

MCPセキュリティとは
MCPの脅威モデル早見表
2026-07-28版で変わったセキュリティ要件
認証と認可：OAuth 2.1・APIトークン・audienceの検証
最小権限：ツール単位のスコープ設計
プロンプトインジェクションとtool poisoning：防げること・防げないこと
サプライチェーン：怪しいMCPサーバーの見分け方
実行環境の対策：シークレット・分離・IP制限・Egress・ログ
MCPセキュリティチェックリスト（25項目）
実際の脆弱性・事件から学ぶ
よくある失敗（症状→原因→対処）
NodeFlareならこう解決できる
よくある質問（FAQ）

1. MCPセキュリティとは

MCPセキュリティとは、MCPクライアント、その裏にいるモデル、接続しているすべてのMCPサーバーが「何にアクセスでき、何を実行できるか」を制御し、その制限が実際に効いていることを確かめる取り組みです。MCP（Model Context Protocol）はAIアプリが外部のツールを呼び、リソースを読み、プロンプトを取得するためのプロトコルです。つまりMCPサーバーは、社内SaaSやデータベース、ファイルの認証情報を持ち、しかも読んだ文章に影響されうるモデルから指示を受ける、新しい特権的な連携ポイントになります。

前提として押さえたい事実は3つです。

認可はプロトコル上オプションです。仕様では認可はOPTIONALで、対応する場合はHTTP系のサーバーがMCPの認可仕様に従うSHOULD、stdioのサーバーは従わずに環境変数などから資格情報を得るSHOULDとされています。
モデルは構造的に「混乱した代理人（confused deputy）」になりえます。GitHubのissue、メール、Webページ、ツールの説明文など、モデルが読むあらゆる文章が次のツール呼び出しをねじ曲げようとする可能性があります。
サーバーは自分でインストールするソフトウェアです。ローカルのサーバーはクライアントと同じ権限で動くため、悪意ある、または脆弱なパッケージはそのままPCやトークンへの侵入経路になります。

MCPセキュリティは1つの機能ではなく、ID（誰が）、認可（何を）、分離（どこで）、可観測性（証拠）の組み合わせです。

2. MCPの脅威モデル早見表

主な脅威と、それを定義している一次情報、被害を抑える対策を表にまとめました。OWASP列はOWASP MCP Top 10の2025年版リスト（現在ベータ）の番号です。

脅威	何が起きるか	一次情報	OWASP MCP Top 10	主な対策
認証なし・弱い認証	URLを知った人が誰でもツールを呼べる	MCP認可仕様	MCP07 認証・認可の不備	すべてのリクエストでOAuth 2.1か呼び出し元ごとのAPIトークン
トークンの素通し・audience違い	別サービス向けのトークンを受け入れたり転送したりする	MCPセキュリティベストプラクティス	MCP01 トークンの管理不備とシークレット露出	audience検証（RFC 8707）、クライアントのトークンを下流へ渡さない
広すぎるスコープ	1つのトークン漏えいで全ツールが使われる	同上（Scope Minimization）	MCP02 スコープ肥大による権限昇格	ツール単位のスコープ、段階的な権限追加
tool poisoning	ツール説明文に隠した指示でモデルが操られる	Invariant Labs（2025年4月）	MCP03 Tool Poisoning	ツール定義の固定とレビュー、危険なツールは人が承認
コンテンツ経由のプロンプトインジェクション	ツールが返したデータで次の呼び出しが乗っ取られる	OWASP LLM01	MCP06／MCP10	最小権限、サーバー間の分離、確認ステップ
サプライチェーン	名前を似せた、またはバックドア入りのパッケージ	Koi Security（postmark-mcp）	MCP04 サプライチェーン攻撃	提供元の確認、バージョン固定、差分レビュー
コマンドインジェクション	細工した入力がシェルに届く	CVE-2025-6514（mcp-remote）	MCP05 コマンドインジェクション	URLをシェルで開かない、入力検証、パッチ適用
OAuthプロキシのconfused deputy	残った同意Cookieを悪用して認可コードを奪われる	MCPセキュリティベストプラクティス	MCP07	クライアントごとの同意、`redirect_uri` の完全一致、`state` の検証
ディスカバリ時のSSRF	悪意あるサーバーがクライアントに内部URLを取得させる	同上	―	HTTPSのみ、プライベートIP帯の遮断、Egressプロキシ
認証なしのローカルサーバー	ブラウザや他プロセスから `localhost` のサーバーに到達される	CVE-2025-49596（MCP Inspector）	MCP07	`127.0.0.1` にバインド、トークン必須、`Origin` 検証
野良サーバーとログ不在	どのサーバーがあり何をしたか誰も分からない	OWASP	MCP08 監査・テレメトリ不足、MCP09 Shadow MCP Servers	棚卸し、ゲートウェイへの集約、リクエストログ

3. 2026-07-28版で変わったセキュリティ要件

2026-07-28版では、セキュリティに関わるルールがいくつか厳しくなりました。参考にしている記事がこれより古い場合は、次の点を確認してください。

項目	2025年版まで	2026-07-28版
クライアント登録	Dynamic Client Registration（RFC 7591）がよく使われた	Client ID Metadata Documentsへの対応がSHOULD。Dynamic Client Registrationは非推奨となり、後方互換のためだけに残る
認可レスポンス	`iss` の検証は必須ではなかった	認可コードをトークンエンドポイントへ送る前に、RFC 9207の `iss` 検証がMUST（mix-up攻撃対策）
セッション	`Mcp-Session-Id` のセッションハイジャック対策	プロトコルはステートレスに。代わりに「state handleの乗っ取り」対策として、handleを持っていること自体を認証とみなすのはMUST NOT
SSRF	記述が少なかった	クライアント向け、およびClient ID Metadata Documentを取得する認可サーバー向けの対策が明記された
スコープ	step-upの説明のみ	サーバーは今の操作に必要なスコープを1回のチャレンジでまとめて返すSHOULD。クライアントは既存と新規のスコープの和集合を要求するSHOULD

同じ版でのトランスポート側の変更（ヘッダー、ステートレス化、Origin 検証）は、MCP Streamable HTTPの解説記事にまとめています。

4. 認証と認可：OAuth 2.1・APIトークン・audienceの検証

リモートのMCPサーバーでは、利用者が自分のIDで操作する場合は仕様のOAuth 2.1ベースのフローを、社内エージェントやCI、スクリプトのように両端を自分たちで管理する場合は呼び出し元ごとのAPIトークンを使うのが基本です。どちらの場合も、次のルールはすべてのトークンに当てはまります。

4-1. すべてのアクセストークンに共通するルール

ルール	仕様の内容（2026-07-28版）
ヘッダーで送る	クライアントは `Authorization: Bearer <access-token>` を使うMUST。すべてのHTTPリクエストに付けるMUST
URLに載せない	アクセストークンをURIのクエリ文字列に含めるのはMUST NOT
audienceの検証	サーバーは、トークンが自分宛てに発行されたものかを検証するMUST（RFC 8707）
素通しの禁止	サーバーは他のトークンを受け入れたり中継したりするのはMUST NOT
無効なトークン	無効・期限切れのトークンにはHTTP 401を返すMUST
スコープ不足	`403` と `WWW-Authenticate: Bearer error="insufficient_scope", scope="..."` を返すSHOULD

4-2. OAuthフローの全体像

クライアントがトークンなしでサーバーを呼ぶと、401 と WWW-Authenticate: Bearer resource_metadata="..." が返ります。
クライアントはサーバーのProtected Resource Metadata（RFC 9728。MCPサーバーは実装がMUST）を読み、認可サーバーの場所を知ります。
RFC 8414またはOpenID Connect Discoveryで認可サーバーの情報を取得します（クライアントは両方への対応がMUST）。
クライアントは自分を名乗ります。推奨はClient ID Metadata Document（HTTPSのURLを client_id として使う方式）です。
PKCEと、サーバーの正規URI（例：https://mcp.example.com/mcp）を入れた resource パラメーターを付けて認可リクエストを送り、想定する発行者（issuer）を記録しておきます。
コールバックで iss を検証（RFC 9207）し、code_verifier と resource を付けてコードをトークンに交換し、そのアクセストークンでサーバーを呼びます。

4-3. OAuthとAPIトークンの使い分け

状況	推奨する資格情報	理由
社外・社内の利用者がClaude、ChatGPT、IDEから自社SaaSにつなぐ	OAuth 2.1（利用者ごと）	呼び出しごとに本人のIDと同意が付き、利用者単位で取り消せる
社内エージェント、定期ジョブ、CI	呼び出し元ごとの、スコープを絞ったAPIトークン	ブラウザ操作が要らず、トークンを分ければログで誰の操作か分かる
サーバーが外部APIを呼ぶ	サーバー自身の資格情報を暗号化したシークレットとして保持	クライアントのトークンを下流で使い回すのは素通しにあたる
ローカルのstdioサーバー	環境変数などから取得	仕様上、stdioはHTTPの認可フローに従わないSHOULD

APIトークンの管理で本当に効くのは、次の5つです。呼び出し元ごとに1本発行する（チームで共有しない）、漏えい時に検出しやすい接頭辞を付ける、サーバー側ではハッシュ化して保存する、有効期限か定期ローテーションを設ける、人の異動やジョブの廃止に合わせてすぐ失効させる。加えて、認証失敗が続くIPを制限し、総当たりを防ぎます。

4-4. サーバーが外部APIへのOAuthプロキシになる場合

仕様の「Confused Deputy Problem」の節がそのまま当てはまります。MCPプロキシサーバーは、クライアントごとの同意を保持すること、クライアント名・要求スコープ・redirect_uri を表示する同意画面を出すこと、redirect_uri を文字列の完全一致で検証すること、使い捨てで短い有効期限（仕様の例では10分）の state を、利用者が同意した後にだけ発行することがMUSTです。

5. 最小権限：ツール単位のスコープ設計

スコープはサーバー単位ではなく、ツールとそのリスクの大きさを軸に設計します。仕様のScope Minimizationの節は、よくある失敗として「scopes_supported に全スコープを並べる」「* や full-access のようなワイルドカードを使う」「トークンにスコープが書いてあるだけでサーバー側で確認しない」を挙げています。

社内SaaSをMCPで公開する場合の実用的な分け方は次のとおりです。

区分	ツールの例	スコープの形	付与する相手
探索	ツール一覧、ドキュメント検索	`tools:list`、`mcp:tools-basic`	全員
読み取り	`get_invoice`、`get_customer`	ツールごとの読み取りスコープ	分析・サポート担当
書き込み	`create_ticket`、`update_customer`	ツールごとの書き込みスコープ、初回利用時にstep-up	特定のチーム
破壊的・外部送信	`delete_record`、`send_email`、`transfer_funds`	ツールごとのスコープ＋人による確認	ごく一部、短命なトークン

設計のルールは3つです。

読み取りと書き込みのツールを分ける。manage_customer のようにまとめると、閲覧だけしたい人にも書き込み権限を渡すことになります。
危険なツールは用途を狭くする。send_email(to, body) より send_email_to_customer(customer_id) の方が安全です。宛先を決めるのがモデルではなくサーバーになるからです。
チェックはサーバーで行う。モデルやクライアントはセキュリティ境界ではありません。ツールを実行する前に必ずサーバー側で判定します。

6. プロンプトインジェクションとtool poisoning：防げること・防げないこと

プロンプトインジェクションを完全に防ぐサーバー側の設定はありません。目標は「乗っ取られても実害が出ない」状態にすることです。tool poisoningは、2025年4月にInvariant Labsが定義した間接プロンプトインジェクションの一種で、ツールの説明文に、利用者には見えずモデルには見える指示を仕込むものです。コンテンツ経由のプロンプトインジェクションも仕組みは同じで、issueの本文やメールなど、ツールが返すデータに指示が入っています。

効果の大きい順に、対策は次のとおりです。

呼び出し元ごと・ツールごとの最小権限（5章）。send_email を呼べないエージェントは、メールでの持ち出しを指示されても実行できません。
信用できない入力と機密性の高いツールを、同じエージェントのセッションに混ぜない。Invariant Labsが2025年5月に公表したGitHub MCPの研究では、公開リポジトリの悪意あるissueをきっかけに、権限の広いエージェントが非公開リポジトリの情報を漏らしうることが示されました。
取り消せない操作や外部への送信は、人が確認してから実行する。
ツール定義を固定する。導入時に説明文をレビューし、変わったら気づけるようにします（Invariant Labsはハッシュやチェックサムでの確認を推奨）。
サーバーがデータを送れる先を制限する。送信先の許可リストがあれば「任意のホストへ持ち出し」が「遮断されてログに残る」に変わります。
ツール呼び出しをログに残し、不自然な呼び出しの流れをあとから見つけられるようにする。

7. サプライチェーン：怪しいMCPサーバーの見分け方

MCPサーバーは、認証情報を預ける依存パッケージとして扱います。つまり、提供元を確かめ、バージョンを固定し、更新時は差分を読むことです。代表例が postmark-mcp です。Postmarkの公式ライブラリと同じ名前のパッケージが2025年9月15日にnpmへ公開され、9月17日のバージョン1.0.16で、送信するすべてのメールを攻撃者のアドレスにBCCする1行が加えられました。Koi Securityが9月29日に報告した時点で、累計ダウンロードは1,643件でした。

確認すること	危険なサイン
提供元	ベンダーの公式組織ではない。公式プロジェクトの名前をまねている
ソース	公開リポジトリがない、または公開パッケージと中身が一致しない
バージョン履歴	新しいアカウントから短期間に多数のリリース。パッチ版で挙動が変わる
導入コマンド	`npx` や `uvx` で最新版を取得し、バージョンを固定していない
ツールの説明文	長い、隠れている、ツールの目的と無関係な指示のような文がある
通信先	ラップしているサービスと関係のないホストに通信する
権限	ツールに必要な範囲より広いトークンを求める

8. 実行環境の対策：シークレット・分離・IP制限・Egress・ログ

いつか1つのサーバーは侵害される、という前提で、到達できる範囲を絞ります。

対策	防ぐもの	最低ライン
シークレット管理	コード、イメージ、ログ経由での鍵の漏えい	保存時に暗号化、実行時だけ注入、ログからは伏せ字にする
分離	あるサーバーが別のサーバーのメモリやファイルを読む	サーバーごとに別のサンドボックス。ローカルサーバーも仕様は最小権限でのサンドボックス実行を推奨
送信元IPの許可リスト	正しいトークンを持っていても、知らないネットワークから呼ばれる	オフィス、VPN、CIのCIDRだけ許可し、既定は拒否
Egress制御	持ち出しや、内部・メタデータアドレスへのSSRF	サーバーごとに必要なホストだけ許可。`169.254.0.0/16` やプライベート帯は遮断
レート制限と支出上限	総当たり、暴走するエージェント、想定外の請求	IP単位とワークスペース単位の制限、月額の上限
リクエストログ	「エージェントが何をしたか」に答えられない	呼び出し元、ツール名、結果、ステータス、時刻。個人情報を含みうる引数の値は保存しない

ローカルサーバーについて、仕様はさらに 127.0.0.1 へのバインド、HTTPを使う場合のトークン必須化、DNSリバインディング対策としての Origin 検証を求めています。

9. MCPセキュリティチェックリスト（25項目）

ID・トークン

[ ] すべてのHTTPリクエストで資格情報を必須にしており、tools/call に匿名で届く経路がない
[ ] トークンは Authorization ヘッダーだけで送り、URLには載せていない
[ ] サーバーがトークンのaudienceを検証し、他サービス向けのトークンを拒否している
[ ] クライアントのトークンを下流のAPIへ転送していない
[ ] トークンは呼び出し元ごとに1本で、共有トークンがない
[ ] トークンはハッシュ化して保存し、すぐ失効でき、期限かローテーションがある
[ ] 認証失敗の繰り返しにレート制限かロックアウトがある
[ ] OAuthクライアントが iss（RFC 9207）を検証し、resource（RFC 8707）を送っている

認可

[ ] スコープをツール単位で定義し、読み取りと書き込みのツールを分けている
[ ] 本番で * などの包括的なスコープを持つ呼び出し元がいない
[ ] 破壊的な操作と外部送信は人の確認を挟んでいる
[ ] 認可の判定をツール実行前にサーバー側で行っている

サプライチェーン

[ ] 外部のサーバーはすべて、提供元とソースリポジトリが分かっている
[ ] バージョンを固定し、ツール説明文の変更も含めて更新をレビューしている
[ ] mcp-remote やMCP Inspectorなどのクライアント側ツールが修正済みのバージョンになっている

実行環境

[ ] シークレットは保存時に暗号化され、イメージやログに含まれない
[ ] サーバーごとに分離して動いている
[ ] 可能な範囲で、受信を既知のIP帯に限定している
[ ] 送信先を、各サーバーに必要なホストだけに限定している
[ ] サーバーとOAuthディスカバリの両方で、プライベート帯とリンクローカル帯を遮断している
[ ] ローカルのHTTPサーバーは 127.0.0.1 にバインドし、Origin を検証している

監視と対応

[ ] すべての呼び出しについて、呼び出し元・ツール・結果・ステータスをログに残している
[ ] インシデント対応に必要な期間、ログを保持している
[ ] 利用中のMCPサーバーを棚卸しできている（野良サーバーがない）
[ ] トークンの失効とサーバーの停止を数分で行う手順が文書になっている

10. 実際の脆弱性・事件から学ぶ

時期	事例	影響	教訓
2025年4月	Invariant Labsがtool poisoningを公表	ツール説明文に隠した指示でモデルが操られる	ツール定義をレビューして固定する
2025年5月	GitHub MCPのプロンプトインジェクション研究（Invariant Labs）	公開issueをきっかけに非公開リポジトリの情報が漏れうる	トークンを絞り、信用できない入力と機密アクセスを混ぜない
2025年6月	CVE-2025-49596（MCP Inspector 0.14.1未満）	Inspectorのクライアントとプロキシ間に認証がなく、認証なしのリクエストでstdio経由のMCPコマンドを起動できた（CVSS v4.0で9.4）	開発用のローカルツールにも認証が必要。0.14.1以上に更新
2025年7月	CVE-2025-6514（`mcp-remote` 0.0.5以上0.1.16未満）	信頼できないサーバーに接続すると、細工した `authorization_endpoint` でOSコマンドインジェクション（CVSS 3.1で9.6）	サーバーから来たURLをシェルに渡さない。0.1.16以上に更新
2025年9月	npmの `postmark-mcp` 1.0.16	送信メールがすべて攻撃者にBCCされた	提供元の確認、バージョン固定、送信先の制限

11. よくある失敗（症状→原因→対処）

症状	原因	対処
トークン1本の漏えいで全ツールが使われた	サーバー全体、または `*` のスコープ	ツール単位のスコープにし、絞ったトークンを再発行
ログ上、全エージェントが同じIDに見える	チーム共有のトークン	呼び出し元ごとにトークンを分ける
下流APIのログに、自社サーバーではなく利用者のトークンが出る	トークンの素通し	下流への呼び出しはサーバー自身の資格情報で行う
プロキシやCDNのログにトークンが残っている	クエリ文字列にトークンを載せている	`Authorization` ヘッダーに移し、トークンを再発行
想定外の国からサーバーが呼ばれている	公開URLをトークンだけで守っている	送信元IPの許可リストを追加
知らないホストにデータが送られていた	送信先が無制限	まず観測モードで通信先を把握し、許可リストを強制
「どのツールがこれを消したか」に答えられない	リクエストログがない	すべての呼び出しで呼び出し元・ツール・結果を記録

12. NodeFlareならこう解決できる

NodeFlareはMCPサーバーをプロキシの後ろでホストし、ここまでに挙げた対策の多くを、リクエストがサーバーのコードに届く前に適用します。この記事で取り上げたリスクごとに、対応する機能を整理します。

この記事のリスク	NodeFlareの機能	内容
認証なし	認証付きのHTTPS URL	公開範囲は既定でプライベート。呼び出しには `mcp_*` 形式のAPIキーかOAuthアクセストークンを使います。OAuthのディスカバリメタデータ（RFC 8414／9728）も配信するので、標準準拠のクライアントは認証方式を自動で見つけられます
トークンの総当たり	IP単位のロックアウト	APIキーはハッシュ化して保存。同じIPから誤ったキーが繰り返されると、そのIPを10分間ロックします
広すぎるスコープ	リクエスト単位のスコープ判定	プロキシが呼び出し元のスコープを、MCPのメソッドと対象に照らして転送前に判定します。`tools:list`、`tools:call`（全ツール）、`tools:call:<ツール名>`（例：`tools:call:get_weather` で `get_weather` だけ）、`resources:read:<uri>`、`prompts:get:<name>`。拒否された呼び出しはJSON-RPCエラーになり、サーバーには届きません
シークレットの漏えい	暗号化されたシークレット	環境変数は保存時に暗号化され、VMの起動時にだけ注入されます。ビルド引数には渡さず、ビルドログは既知のトークン形式を伏せ字にしてから表示します
サーバー間の侵害	Firecracker microVMによる分離	各サーバーは専用のFirecracker microVMで動き、基盤はNodeFlareが運用する専用の物理サーバーです
知らないネットワークからの呼び出し	送信元IPの許可リスト	ポリシーを `restricted` にしてIPv4／IPv6のCIDRを指定します。認証やVM起動より前に判定し、リストが空なら全拒否（fail closed）になります
持ち出しとSSRF	Egress制御	モードは `off`（既定）、`observe`（通信先を記録のみ）、`enforce`（リスト外を遮断）。許可リストは最大100件で、完全一致のホスト名、先頭ワイルドカード1つ（`*.example.com` など）、IPを指定でき、ホスト側のDNSとnftablesで強制します
監査の証拠がない	リクエストログ	呼び出しごとに `caller_kind`（api_key／oauth／anonymous）、`client_ip`、ツール名、引数のキー名（値は記録しない）、`outcome`（`scope_denied`、`rate_limited` など）、`http_status` を記録します。保持期間はFreeが7日、Pro／Teamが30日です
エージェントの暴走と想定外の請求	レート制限と支出上限	IP単位のレート制限とワークスペース単位の月次クォータに加え、任意で月額の支出上限を設定でき、上限に達するとHTTP 402でサーバーを一時停止します

NodeFlareでも防げないこともあります。モデル内部で起きるプロンプトインジェクションやtool poisoningそのものは止められません。ツール単位のスコープ、Egressの許可リスト、調査用のログで被害を小さくすることはできますが、外部サーバーのレビューや危険な操作の確認は利用者側で行う必要があります。

最小の始め方：サーバーをデプロイし、呼び出し元ごとに必要な tools:call:<ツール名> だけを付けたAPIキーを発行します。次にEgress制御を observe で1週間ほど動かして通信先を把握し、enforce に切り替えます。

1サーバーまでは無料で試せます。NodeFlareを始める

13. よくある質問（FAQ）

MCPセキュリティとは何ですか？

MCPのクライアント、モデル、サーバーがアクセス・実行できる範囲を制限するための対策の総称です。認証、ツール単位の認可、分離、ネットワーク制限、ログが含まれます。MCPサーバーは実際の認証情報を持ち、読んだ文章に影響されうるモデルから指示を受けるため、重要になります。

MCPの仕様で認証は必須ですか？

仕様上、認可はOPTIONALです。対応する場合、HTTP系のサーバーはOAuth 2.1ベースのMCP認可仕様に従うSHOULD、stdioのサーバーは環境変数などから資格情報を得るSHOULDとされています。実務では、ネットワーク越しに届くサーバーには必ず認証を付けるべきです。

MCPはOAuth 2.1を使うのですか？

はい。MCPの認可仕様はOAuth 2.1のドラフトを土台に、RFC 8414、RFC 8707、RFC 9728、RFC 9207、Client ID Metadata Documentsを組み合わせています。MCPサーバーはOAuthのリソースサーバー、MCPクライアントはOAuthクライアントとして振る舞います。

MCPのトークンパススルー（token passthrough）とは？

MCPサーバーが、自分宛てに発行されたかを確かめずにクライアントのトークンを受け取り、そのまま下流のAPIへ転送することです。仕様では禁止されており、サーバーは自分宛てでないトークンを受け入れたり中継したりしてはいけません。下流への呼び出しにはサーバー自身の資格情報を使います。

リモートMCPサーバーはOAuthとAPIキーのどちらを使うべき？

利用者が自分のIDと同意でつなぐならOAuthです。社内エージェント、定期ジョブ、CIには、スコープを絞った呼び出し元ごとのAPIトークンが向いています。どちらでも、1本のトークンを複数の呼び出し元で共有しないでください。

MCPのトークンを特定のツールだけに制限するには？

ツールごとのスコープ（1つのツールだけを許可するスコープなど）を発行し、ツールの実行前にサーバー側で判定します。仕様は、最小限の初期スコープで始め、危険なツールを初めて使うときに 403 insufficient_scope で追加の権限を求める方式を推奨しています。

tool poisoningとは何ですか？

ツールの説明文に、利用者には見えずモデルには見える指示を隠す、間接プロンプトインジェクションの一種です。ツール定義のレビューと固定、エージェントごとの権限の最小化、危険な操作の確認で対策します。

MCPのプロンプトインジェクションは完全に防げますか？

現時点で完全に防ぐ方法はありません。モデルはそもそも信用できない文章を処理する仕組みだからです。最小権限のスコープ、信用できない入力と機密ツールの分離、送信先の許可リスト、人による確認、ログで影響を小さくします。

悪意あるMCPサーバーを見分けるには？

提供元が公式ベンダーか既知の開発者か、ソースリポジトリと公開パッケージが一致しているか、バージョンを固定できているかを確認します。ツール説明文に指示のような文がないか、関係のないホストへ通信していないかにも注意します。

まず対応すべきMCPの脆弱性は？

最低限、MCP Inspectorを0.14.1以上（CVE-2025-49596）、mcp-remote を0.1.16以上（CVE-2025-6514）に更新してください。そのうえで、パッケージレジストリから入れたサーバーを公式のソースと照らし合わせます。

MCPの監査ログには何を記録すべき？

少なくとも、呼び出し元のID、ツールまたはメソッド名、結果（許可・拒否・レート制限）、ステータスコード、送信元IP、時刻です。個人情報やシークレットを含みうる引数の値は、そのまま保存しないようにします。

まとめ

MCPセキュリティは、ヘッダーでのトークン送信、audienceの検証、トークンの素通し禁止という仕様上の必須事項から始まり、ツール単位の最小権限で実効性が出ます。プロンプトインジェクションやtool poisoningはサーバー側だけでは解決できないため、残りの層、つまり確認済みでバージョンを固定したサーバー、暗号化したシークレット、分離、IPとEgressの許可リスト、リクエストログが重要になります。運用している各サーバーを25項目のチェックリストで点検し、穴を順に埋め、仕様やツールが変わったら見直してください。