AIエージェントが外部サービスを操作するMCPでは、「ログインできた」だけでは安全とは言えません。盗まれたトークンが別のサーバーでも通る、必要以上の権限を持つ、上流APIへそのまま転送される——こうした設計は、エージェントの行動範囲を一気に広げます。
本記事では、2026年7月28日版のMCP認可仕様にある要件を、①権限、②宛先、③サービス間のトークン分離、④寿命と交換経路という4つの原則に整理します。
「認証」と「認可」は別物です
認証は「誰か」を確かめ、認可は「何を許すか」を決めます。MCPのHTTPトランスポートで認可を実装する場合、保護されたMCPサーバーはOAuth 2.1ドラフト上のリソースサーバー、MCPクライアントはOAuthクライアントとして動きます。
なお、MCPの認可機能そのものは任意です。ただし公式仕様は、HTTPで認可を扱う実装には仕様への準拠を推奨し、STDIOではこの仕組みを使わず環境から資格情報を取得するよう推奨しています。接続方式を無視して、すべてを同じ「APIキー」で済ませる設計ではありません。
1. scopeは「何ができるか」を狭める
scope（スコープ）は、たとえばfiles:readのように操作範囲を表します。公式仕様は、サーバーが401応答のWWW-Authenticateヘッダーで現在の操作に必要なscopeを示し、クライアントは最小権限の原則に従って必要なscopeだけを要求する流れを示しています。
最初から「read/write/admin」を全部渡すより、読み取りから始め、必要になった操作だけ追加認可する方が安全です。これは機能を削るのではなく、故障時の影響範囲を設計する考え方です。
2. resourceとaudienceは「どこで使えるか」を固定する
scopeが「何を許すか」なら、resource（リソース）は「どのサーバー向けのトークンを要求するか」です。MCP仕様では、クライアントは認可要求とトークン要求の両方にresourceを含め、対象MCPサーバーの正規URIを指定しなければなりません。サーバー側は、発行済みトークンのaudience（オーディエンス、宛先）を検証し、自分向けかを確かめる必要があります。
IETFのRFC 8707は、リソースを明示すると認可サーバーがトークンの利用先を限定でき、別サービスへの転用を防ぎやすくなると説明しています。つまり、scopeだけ合っていても宛先が違えば拒否する設計です。
3. 上流APIには「別のトークン」を使う
MCPサーバーがGoogle DriveやGitHubなどの上流APIを呼ぶ場合、クライアントから受け取ったトークンをそのまま転送してはいけません。MCPのセキュリティ考慮事項は、上流API用には上流の認可サーバーが発行した別トークンを使い、受信トークンのパススルーを禁止しています。
ここを分けないと、MCPサーバーが本来の権限境界を飛び越える「混乱した代理人」になり得ます。車載ネットワークで例えるなら、診断機の入場証を、そのまま各ECUの書き換え許可証として使わないのと同じです。
4. 盗難前提で寿命と交換経路も守る
Bearerトークンは、持っている者が使える性質があります。公式仕様は、認可サーバーに短命なアクセストークンの発行を推奨し、公開クライアントではリフレッシュトークンのローテーションを必須としています。
さらに、認可コードの横取りや差し替えを防ぐため、MCPクライアントにはPKCEの実装が求められます。PKCE対応をメタデータで確認できない認可サーバーに対しては、処理を中止しなければなりません。アクセストークンをURLのクエリ文字列へ入れることも禁止です。ログや履歴に残りやすいからです。
実装前に確認したい5項目
- 最小scope：最初の要求は本当に必要な操作だけか
- 宛先固定：
resourceを送り、サーバーでaudienceを検証しているか - トークン分離：MCP受信トークンを上流APIへ転送していないか
- 盗難対策：短命化、安全な保存、更新時のローテーションがあるか
- 交換経路：HTTPS、PKCE、正確なredirect URI検証を実装しているか
まとめ
MCPの安全性は、「OAuthを使った」という部品名では決まりません。scopeで操作を絞り、resourceで宛先を固定し、トークンをサービスごとに分離し、寿命を短くする。この4点がそろって、初めて権限境界になります。
AIエージェントは、正常時の便利さより異常時の行動半径で評価すべきです。万能鍵を賢く管理するより、最初から万能鍵を作らない。これがMCP認可設計の要点です。