MCPサーバーを企業へ導入するとき、Registry上の表示名、配布元、SBOM、署名、固定版を確認することは重要です。しかし、それだけでは実行時の安全性を説明できません。正規のMCPサーバーであっても、広すぎるtokenを受け入れたり、別の接続先向けのtokenを使えたりすれば、意図しない権限行使につながります。
結論は、リモートMCPでは「どのserver向けのtokenか」をresourceで固定し、必要最小限のscopeを段階的に要求し、盗まれたtokenの再利用を短命化・sender constraint・失効で抑えることです。人の承認は、この機械的な認可境界を通った後の高リスク操作に置きます。
本記事は、9月7日に確認したMCP Authorization specification version 2025-11-25 を対象にします。ローカルstdio接続にはHTTP/OAuthのdiscoveryをそのまま当てはめられないため、transportごとに境界を分けてください。
サプライチェーン対策と実行時認可は別の問題
配布元や署名を確認するのは、「何を導入するか」の検査です。OAuth認可は、「導入済みのserverに、誰が、どの範囲で、どのtokenを使って要求するか」の制御です。
両方が必要です。正規のMCP serverでも、全社共有の管理tokenをそのまま渡せば、利用者・接続先・操作範囲を限定できません。逆に認可フローが正しくても、悪意あるserverを導入してよい理由にはなりません。導入前の供給経路と、導入後の一回ごとの実行権限を別のチェックリストで扱います。
Protected Resource Metadataで正しい認可先を発見させる
現行MCP Authorization specificationでは、MCP serverはOAuth 2.0 Protected Resource Metadata（RFC 9728）を実装し、clientはそこから認可serverを発見します。MCP endpointに対する401応答のWWW-Authenticate header、またはwell-known URIがdiscoveryの入口です。
重要なのは、clientが任意の認可serverや偽のmetadataへ誘導されないことです。MCP server側は正しいmetadataを公開し、client側は仕様に沿ってendpointとauthorization serverの対応を検証します。metadataは便利な設定ファイルではなく、認可境界の一部として扱うべきです。
resourceはtokenの宛先を示す
MCP clientは、authorization requestとtoken requestの双方で、対象MCP serverを表すcanonical URIをresourceとして送ります。RFC 8707のresource indicatorは、tokenを特定のresourceへ結び付け、別resourceへの転用を防ぐための仕組みです。
複数のMCP serverに一つの広いtokenを渡すのではなく、接続先ごとにresourceを分けます。テナントをURIのpathなどで区別できる設計では、tokenのaudienceもテナント境界まで絞れるかを確認します。ただし、URI設計は既存の認可モデルと一緒に決める必要があり、単にpathを増やすだけで隔離が成立するわけではありません。
scopeは最初から全権限を渡さない
scope名そのものに万能の標準はありません。だからこそ、業務上の操作に対応させて小さく定義します。たとえば検索だけなら読取、下書き保存なら保存、外部送信・支払い・削除は別scopeか、scopeに加え人の承認を必要にします。
MCP仕様では、clientが必要なscopeを段階的に要求する考え方が示されています。最初の接続で「将来必要になるかもしれない」権限まで要求せず、追加操作の直前に必要な権限を求める方が、利用者への説明と監査がしやすくなります。
一方でscopeを細かくし過ぎると、実装・運用・利用者体験が壊れます。現実の業務単位で、読取、下書き保存、外部作用、管理操作のような少数の境界から始め、実際の権限昇格を観測して見直します。
tokenの盗用と再利用を前提にする
OAuth 2.0 Security Best Current Practice（RFC 9700）は、redirect URIの完全一致、PKCE、refresh tokenのrotation、sender-constrained tokenを重要な対策として示しています。
PKCEは、認可codeを途中で盗まれても、code verifierを持たない第三者がtokenへ交換しにくくする仕組みです。DPoPは、tokenを特定の鍵へ結び付け、盗んだtokenを別環境で再利用しにくくします。DPoPを使うresource serverは、要求中のproofとtokenに結び付く公開鍵を検証する必要があります。
ただし、DPoPはHTTPSの代替ではありません。client本体が侵害され、tokenと鍵の両方を盗まれた場合まで解決するものでもありません。短い有効期限、refresh tokenのrotation、失効手順、異常利用の検知を組み合わせます。
service tokenを人の委任権限として使わない
Cloudflare Accessのservice tokenは、ブラウザでログインしない自動処理を保護するためのcredentialです。期限、rotate、renew、disable、revokeを管理できます。定期同期やCIのように、明確な無人処理には有用です。
しかしservice tokenは、「誰が、今回この操作を許可したか」を表すものではありません。利用者ごとの委任、操作内容の確認、承認履歴が必要なMCP toolには、共有の静的credentialを流用しない方がよいでしょう。無人処理、利用者委任、高リスク操作を同じtokenで処理しないことが基本です。
導入前チェックリスト
- 対象がremote HTTP MCPか、local stdio MCPかを区別しているか
- MCP endpointごとにProtected Resource Metadataと認可serverの対応を確認したか
- clientがauthorization requestとtoken requestの双方に正しい
resourceを送るか - serverが自分向けに発行されたtokenだけを受け入れるか
- scopeを読取、保存、外部作用、管理操作などの業務境界で分けたか
- redirect URIの完全一致とPKCEをテストしたか
- token期限、refresh rotation、revoke時の失効確認を運用手順へ入れたか
- 401、期限切れ、scope不足、別resource向けtoken、DPoP proof不正を自動テストしたか
- 外部送信・削除・支払いには、認可とは別に承認ゲートを置いたか
限界：正しい認可だけでは危険な操作を安全にできない
正しいscopeを持つtokenでも、prompt injectionによって危険な操作を選ぶことはあります。認可は「許可された操作か」を判定する境界であり、「その操作を今実行してよいか」を判断するものではありません。外部送信、削除、支払い、顧客データの公開には、操作内容を固定した人の承認、監査ログ、fail-closeのtimeout設計が必要です。
また、MCP仕様と各clientの実装対応は更新されます。仕様に書かれた要件と、利用するclient・identity provider・proxyが実際に対応しているかを、導入前に接続テストで確認してください。
MCP・AIエージェントのセキュリティレビュー
MCP serverの配布元、接続先、scope、OAuth認可、承認ゲートを導入前に整理したい方は、MCP・AIエージェントのセキュリティレビューをご利用ください。
一次情報と確認範囲
確認日：2026年9月7日。仕様・実装対応状況は更新され得るため、公開・導入時に最新の原典を再確認してください。
| 機関・仕様 | 確認した範囲 | URL |
|---|---|---|
| Model Context Protocol | OAuth 2.1、Protected Resource Metadata、resource parameter要件 | Authorization specification 2025-11-25 |
| IETF | metadataの構成、discovery、scope、DPoP-bound tokenの表現 | RFC 9728 |
| IETF | resource parameterとaudience restriction | RFC 8707 |
| IETF | redirect URI、PKCE、refresh token rotation、sender constraint | RFC 9700 |
| IETF | DPoP proofとresource serverの検証要件、HTTPSとの関係 | RFC 9449 |
| IETF | authorization code interceptionに対するPKCEの目的 | RFC 7636 |
| Cloudflare | service tokenの期限、rotate、renew、disable、revoke | Service tokens |
一次情報と確認範囲
確認日：2026年9月7日。製品仕様・制度は更新されるため、導入時はリンク先の最新版を再確認してください。海外の制度・職業規範は日本へ直接適用せず、相違点と限界を本文に明記しています。