MCPが接続できれば安全？トークンの宛先と権限を確認する

公開日2026.10.15

更新日2026.10.17

約8分で読めます

※本ページのリンクにはプロモーションが含まれています。

AIからWordPressや業務サービスへ接続できるようになったとき、最初に目に入るのは「認証成功」です。しかし、接続に成功したことは、受け取ったトークンの用途や、公開・削除まで含む権限が適切だという証明にはなりません。

情報確認日は2026年10月15日です。本記事はMCPの2026年7月28日版の公式認証資料などを確認した設計解説です。特定の侵害事件や、新しい脆弱性の発見を報告するものではありません。以下のWordPress構成と点検手順は、本サイトからの提案です。

MCPは操作の共通言語。業務の権限は別に必要

MCPはAIアプリから外部のツールや情報を使うためのプロトコルです。例えば「記事を読む」「下書きを保存する」という機能をサーバー側で提供できます。ただし、機能一覧へ載せたことと、すべての接続利用者に実行を許可したことは別です。

考える境界は、AIアプリ、MCPサーバー、接続先の業務APIです。認証を担当するサービスが別にある場合は、その役割も加わります。どこで利用者を識別し、どこで権限を判定し、どの資格情報で次のサービスへ進むかを書き出してください。

WordPress内で動くMCPサーバーなら、外部接続のスコープだけでなく、WordPressの現在のユーザー権限を検査する設計が考えられます。接続時に管理者だった人が後で役割を変更されたとき、古い判断を保持し続けないかが重要です。

トークンには「誰向けか」という境界がある

公式のAuthorization Security Considerationsは、MCPサーバーに提示されたトークンが、そのサーバー向けに発行されたものかを確認するよう求めています。クライアント側のresource指定と、サーバー側の宛先検証を対応させる考え方です。根拠資料：Model Context Protocol：Authorization Security Considerations（2026-07-28版）。

JWTを採用する場合、署名が正しいという確認だけでは十分ではありません。発行元、宛先、有効期限など、その用途に必要な検証が残ります。署名が同じ認証基盤で発行されたとしても、別サービス用のトークンを受け付けてよい理由にはなりません。

一方、トークンは必ずJWTであるとは限りません。ランダムな値をサーバー側の保存情報と照合する方式もあります。その場合も、保存した利用者、対象サービス、期限、失効状態との結び付きを確認します。「audという文字列を読めるか」だけのチェックへ狭めないでください。

下流APIのトークンを、そのまま入口で使わない

公式Security Best Practicesは、適切に検証しないトークンをMCPサーバーが受け取り、下流へそのまま渡すtoken passthroughを問題として説明しています。宛先の分離が崩れると、認証の境界や操作の追跡が不明確になります。根拠資料：Model Context Protocol：Security Best Practices（2026-07-28版）。

説明用に、外部ストレージのAPIへアクセスできるトークンを考えます。その値をMCPサーバーへ持ち込めば無条件に使える設計では、MCP側で利用者を区別する仕組みや、独自の操作制限が機能しないおそれがあります。下流が受け付けたから入口の認証も正しい、とは言えません。

本サイトでは、クライアントからMCPへの認証と、MCPから下流サービスへの認証を分け、各境界で用途を限定する方法を提案します。製品ごとに実装方法は違うため、単純なトークンの複製を連携設計として採用しないことが出発点です。

スコープは大きな許可。対象ごとの判定も残る

読む権限、保存する権限、公開する権限を分けると、業務上の許可を整理できます。ただし、wp.readのような独自名のスコープを付けただけで、「他の利用者の非公開記事を読んでよい」とは決まりません。これは説明用の名前で、MCP共通の標準スコープではありません。

実行時には、要求された機能、投稿の所有者、投稿状態、利用者の現在の権限を確認します。公開済みの記事本文を更新できるツールと、下書きだけを保存できるツールでは影響が違います。対象の条件をツールの説明文だけに書かず、サーバーで強制する必要があります。

AIに「削除しないで」と指示しても、削除APIの実行権限は消えません。不要な機能を提供しないこと、必要な機能の対象を狭めること、資格情報の権限を絞ることを組み合わせます。モデルの意図解釈が正しい場合だけ安全な構成を避けます。

同意画面と認可コードの保護は別の段階

公式仕様は認可コードを保護するPKCEを求め、対応可能な場合にS256を使うとしています。これはコードと交換要求を結び付ける仕組みであり、利用者が何を許可したかという業務上の判断そのものを代わりに行うわけではありません。

同意画面では、接続先、利用者、操作範囲を確認できるようにします。コールバックURLは登録済みの値と正確に照合し、状態を確認する値が食い違う応答を捨てます。認可コードやトークンを、問い合わせ用のスクリーンショットへそのまま載せないことも運用上の基本です。

複数の下流サービスやクライアントを扱うプロキシでは、どのクライアントへの同意かが曖昧にならないようにします。一度のログインやCookieが、別の接続に対する包括的な許可へ広がらないかを、採用する認証方式に沿って点検してください。

短い有効期限と、今すぐ止める仕組みを両立する

有効期限は、漏れた資格情報が利用できる時間を制限するために役立ちます。ただし、期限まで待てない事故もあります。接続の無効化、利用者の権限取消、資格情報の失効が、次の呼び出しでどこまで反映されるかを確認します。

更新トークンを使う場合は、その管理も対象です。短いアクセストークンだけを見て安全と判断すると、漏れた更新資格情報からアクセスを継続される可能性を見落とします。保存先、更新方式、再利用への対応、接続解除時の扱いを提供元へ照会してください。

本サイトでは、接続単位で止められることと、サービス全体の緊急停止を分ける構成を提案します。一人の接続を取り消すために全利用者の設定を壊す必要があると、初動が遅れます。通常の運用画面から判断できる状態にしておくと対応しやすくなります。

接続テストは、成功系より境界を確認する

動作確認では、正しい認証で記事一覧を取得できることに加え、別用途の資格情報、期限切れ、失効済み、対象外の投稿、許可外の操作を拒否することを確認します。検証用環境と架空の内容を使い、実際の公開や削除は必要な範囲に限定します。

宛先：他サービス用のトークンを、MCP向けとして受け付けない。
機能：読み取りだけの接続で、保存や公開を実行しない。
対象：非公開記事や他人の下書きの境界を保つ。
変更：役割変更と接続取消が、その後の実行へ反映される。
再送：コード交換や変更処理の繰り返しで、権限拡大や重複を起こさない。

失敗時に返す文言も確認します。利用者には再接続が必要か、権限不足かが分かる程度に伝え、内部には追跡できる診断コードを残します。調査を容易にする目的でも、認可コードやBearer値を丸ごと保存するべきではありません。根拠資料：OWASP：REST Security Cheat Sheet。

接続先のURLと、信頼する認証サービスを固定する

MCPのURLが分かっていても、認証の途中で参照するメタデータやリダイレクト先まで無制限に信用してよいわけではありません。本サイトでは、採用する接続方式の公式手順に従い、発見した認証サービスと要求しているサーバーの関係を確認することを提案します。エラーを解消するために、証明書や宛先の検証を外さないでください。

複数サイトを運用する場合は、本番と検証、顧客AとBの設定が混ざらないようにします。設定名だけで区別せず、対象URLと認証の発行元を管理画面で確認できると便利です。別サイトへ接続したまま下書きを保存するような事故は、トークンの暗号処理だけでは防ぎきれません。書き込み前の対象確認も別に持たせます。

連携をやめるときの片付けを決めておく

AIアプリ側の接続削除と、WordPress側の許可解除がどこまで連動するかを確認します。クライアントに表示がなくなっても、サーバーに残る資格情報が即座に失効するとは限りません。提供する解除機能の範囲と、残存する保存物を把握することを提案します。

廃止時には、接続単位の資格情報、不要な専用ユーザー、定期実行、外部サービスの登録を順に点検します。監査に必要な最小限の記録は定めた期限まで保持し、秘密そのものは広く残しません。新規接続が成功するテストだけでなく、廃止した接続で操作できなくなるテストも、導入時の確認へ含めると運用の最後まで説明できます。