MCPツールにはアクション単位の認可が必要です

2026年5月17日、NVDはWordPressサイトにAIとMCP機能を提供するWordPressプラグイン、AI Engine 3.4.9についてCVE-2026-8719を公開しました。¹³

この失敗の形は、MCPを作るすべての人にとって見過ごせないものです。Wordfenceは、MCPのOAuthベアラートークン認可経路でWordPressの権限確認が欠けていたと説明しています。有効なOAuthトークンであれば、管理者権限を検証しないまま、管理者レベルのMCPツールに到達できました。² Wordfenceはこの問題を8.8 Highと評価し、修正版を3.5.0としています。² プラグインの変更履歴では、3.5.0で管理者権限を必須にし、MCP OAuth認可とトークン検証を修正したとされています。³

MCPの認可は、サーバーがベアラートークンを持っていることを、すべてのツールを使う許可だと扱った時点で破綻します。OAuthは、トークンが認可フローを通って届いたことを証明できます。それでもMCPサーバーは、その主体が、そのツールを、そのリソースに対して、その影響範囲で実行してよいかを判断しなければなりません。

要約

MCPのHTTP認可仕様は、実装者に必要な土台を与えています。保護対象リソースのメタデータ、OAuth 2.1フロー、ベアラートークンの扱い、トークン検証、オーディエンス確認、スコープや権限が不足している場合の明示的な403 Forbidden応答です。⁴ MCPのセキュリティチュートリアルでは、認可を、MCPサーバーが公開する機密リソースや操作を守る層として位置づけています。⁵ ただし、これらの仕組みがアプリケーションレベルの認可判断を不要にするわけではありません。サーバーはなお、トークンをユーザー、ロール、テナント、ツール、リソース、アクション、ポリシーへ対応づける必要があります。

CVE-2026-8719は、この違いを具体的な失敗として示しました。AI Engineは5月12日にバージョン3.4.9でMCPサーバー向けにOAuth 2.1とDynamic Client Registrationを追加し、5月16日にバージョン3.5.0で管理者権限を必須にすることでMCP OAuth認可とトークン検証を修正しました。³ この教訓はWordPressに限りません。データを変更する、コンテンツを公開する、設定を変える、非公開レコードを読む、支払いを発生させる、特権的なAPIを呼び出す。そうしたMCPサーバーには、モデルやクライアントより下の層で、アクション単位の認可が必要です。

ツール配布はリスクをさらに高めます。2026年5月のツール複製に関する論文は、8,861件のMCPおよびSkillsリポジトリ、100,011件のツール項目を測定し、高い類似度の範囲で検証済みの複製率が高いことを示しました。⁶ 再利用テンプレートは良いパターンを広げられます。同時に、欠けた確認も広げてしまいます。

重要なポイント

MCPサーバー実装者へ: - トークンを検証し、その後に具体的なアクションを認可してください。この2つは別の関門として扱います。 - 無効または欠落したトークンには401を返し、有効だがスコープや権限が不足しているトークンには403を返します。 - 低権限トークンで、管理、書き込み、公開、削除、エクスポート、設定変更の各ツールをすべてテストしてください。

セキュリティチームへ: - MCPサーバーをチャットプラグインではなく、アプリケーションエンドポイントとしてレビューしてください。 - 各ツール呼び出しが、どのユーザー、ロール、テナント、リソース、アクションに対応するのか確認します。 - トークン主体、ツール名、リソース、認可結果、拒否理由が分かるログを必須にしてください。

エージェントプラットフォームチームへ: - マーケットプレイス上の件数は、独立した実装の証明にはなりません。 - 複製されたツールは脆弱な認可ロジックもコピーし得るため、類似性と出所の確認が重要です。 - サーバーテンプレートは、セキュリティ上重要なインフラとして扱ってください。

運用者へ: - 影響を受けるWordPressプラグインを使っている場合は、AI Engineを3.5.0以降へ更新してください。²³ - どのWordPressロールがどのツールに到達できるか分かるまで、MCPの公開を無効にしてください。 - 新しいMCP接続は必ず読み取り専用で開始し、拒否経路がテストで確認できてから権限を広げてください。

AI Engineで何が壊れたのか

AI Engineは、URL、サインインフロー、承認ステップを通じて、Claude Code、Claude、ChatGPT、OpenClawなどのクライアントをWordPressサイトにつなぐ方法としてMCPを打ち出しています。³ バージョン3.4.9では、ブラウザ駆動のクライアントが共有ベアラートークンなしで接続できるように、MCPサーバー向けのOAuth 2.1とDynamic Client Registrationが追加されました。³

この製品の方向性自体は理にかなっています。共有の静的トークンは、ユーザー向けのMCP連携には向きません。OAuthフローなら、コピーされたシークレットよりも、クライアント、ユーザー、サーバーをきれいに結びつけられます。

バグはその1つ下の層にありました。NVDとWordfenceによると、脆弱な経路では、管理者レベルのMCPツールへのアクセスを許可する前に管理者権限を検証せず、MCPアクセスに対して有効なOAuthトークンであれば受け入れていました。¹² この違いが重要です。

WordPressプラグインページの修正説明は、正しい言葉を使っています。MCP OAuth認可とトークン検証で管理者権限を必須にし、非管理者ユーザーによる権限昇格を防いだ、という説明です。³ この一文は、欠けていた層を名指ししています。トークンは権限確認の代わりにはなりません。

OAuthは必要ですが、それだけでは足りません

MCPの認可仕様は、HTTPベースのトランスポートにおける通信レベルのフローを扱います。この仕様では、MCPクライアントがリソース所有者の代理として制限付きMCPサーバーへリクエストを行うとされており、その流れはOAuth 2.1、保護対象リソースのメタデータ、認可サーバーのメタデータ、Dynamic Client Registration、ベアラートークンの使用に基づいています。⁴

これらの要素は、実際の問題を解決します。

MCP仕様は、混乱した代理者問題やトークン中継リスクについても警告しています。MCPサーバーは、提示されたトークンがそのMCPサーバーを対象にしていることを検証しなければならず、MCPクライアントから受け取ったトークンを上流のAPIへそのまま渡してはいけません。⁴ この指針は、サービス間の境界を守ります。

アクション単位の認可が守るのは、MCPサーバー内部の境界です。

MCPサーバーは、10個のツールを公開することも、100個のツールを公開することもあります。公開メタデータを読むだけのツールもあれば、非公開レコードを読むものもあります。変更案を作るもの、本番状態を変更するもの、ユーザー、プラグイン、支払い、ジョブ、メッセージ、インフラを管理するものもあります。サーバーがセッションを受け入れたからといって、有効なトークンが自動的にすべてのツールへ到達できてよいわけではありません。

正しい流れは次のとおりです。

1. トークンの発行者、署名、有効期限、オーディエンス、トランスポート規則を検証します。
2. トークンをローカルの主体へ解決します。ユーザー、サービスアカウント、組織、テナント、自動化などです。
3. その主体のロール、スコープ、許可、予算、ポリシーを読み込みます。
4. 要求されたMCPツールを、アクション種別とリスクで分類します。
5. ツール名だけでなく、対象リソースを確認します。
6. トークンは有効でも、アクションが権限を超える場合は403を返します。
7. 後からレビューできるだけの詳細を含めて判断をログに残します。

OAuthは、リクエストを判断地点まで運びます。認可は、そのアクションが許されるものかを決めます。

ツール呼び出しには権限マトリクスが必要です

エージェントツールは、従来のエンドポイント設計の癖をより危険にします。通常のWebルートには、狭いUI経路が周囲にあることが多いものです。一方、モデル向けツールはプランナーの中に置かれます。エージェントは再試行し、呼び出しを連鎖させ、ツール説明を読み、読み取り結果と書き込みアクションを組み合わせ、信頼できないコンテンツから得た指示を後続の手順へ持ち越すことができます。

この振る舞いにより、最低限必要な権限モデルが変わります。サーバーは「このユーザーはMCPにアクセスできるか」だけを問うべきではありません。「このユーザーは、今、このツールを通じて、このリソースに対して、このアクションを実行してよいか」を問うべきです。

マトリクスを使います。

このマトリクスは、エージェントキーにはリスク予算が必要ですで述べたパターンに合います。認証情報は、万能のベアラー文字列のように振る舞うべきではありません。サーバー側の制限、活動ログ、失効、保守的な初期値を持つ、境界づけられた権限オブジェクトとして振る舞うべきです。

また、AIエージェントの所有者こそ信頼の基本単位ですで述べた所有者の考え方にも合います。特権的なツール呼び出しはすべて、責任を持つアカウント、作業回、権限の束、レビュー経路、停止経路へ対応づけられるべきです。

複製されたツールは同じ確認漏れをコピーします

AI Engineのバグは、すべてのMCPサーバーが慎重な独立実装から生まれていたとしても重要です。しかし、ツールのエコシステムはそれほどきれいではありません。

Kim、Jiang、Hu、Jia、Gongは、エージェント型AIエコシステムにおけるツール複製を測定した論文を2026年5月10日に公開しました。データセットには、7,508件のMCPリポジトリから抽出した87,564件のツールと、1,353件のSkillsリポジトリから抽出した12,447件のツールが含まれ、合計で8,861件のリポジトリ、100,011件のツール項目を対象にしています。⁶ 著者らはトークン単位のJaccard類似度とssdeepによるファジーな構造類似度を使い、類似度ごとのサンプルペアを手動で検証しました。⁶

論文の要旨では、MCPエコシステムにおいて、高Jaccard候補の60%、高ssdeep候補の85%が手動検証で複製と確認されたと報告されています。⁶ 論文は、隠れた重複がベンチマーク分割を汚染し、脆弱な実装を広げ、ツール利用の汎化に関する測定を偏らせ、出所、帰属、ライセンス上の懸念を高めると論じています。⁶

この発見は、MCPマーケットプレイスの成長をどう読むべきかを変えます。ツールが増えたからといって、独立したセキュリティレビューが増えたとは限りません。繰り返し使われるサーバーのひな型は、エコシステムに一貫性を与えます。同じ繰り返しが、弱い認証・認可パターンを多数のパッケージへコピーすることもあります。

したがって、セキュリティレビューには出所確認を含める必要があります。

エージェントのSkillsにはパッケージマネージャーが必要ですでは、skillsに対してパッケージ形式の配布、出所、ポリシーが必要だと論じました。MCPサーバーにも同じ規律が必要です。さらに、実行時の認可テストも必要になります。

MCP認可に必要な最低限のテストスイート

非公開データや変更可能なデータに触れるMCPサーバーは、すべて認可テストスイートを同梱すべきです。正常系を確認するユニットテストだけでは足りません。危険な挙動は拒否経路にあります。

まず、次のケースから始めます。

正確なステータスコードは製品ポリシーに従ってよいものの、区別は維持すべきです。無効な認証情報は主体解決の前に失敗し、有効だが権限が足りない認証情報は認可の関門で失敗します。MCP仕様では、認可が欠落または無効な場合の401と、スコープが無効または権限が不足している場合の403が示されています。⁴

WordPressでは、このルールはさらに明確になります。管理操作を行うMCPツールは、ダッシュボード、REST API、内部PHP経路が確認するのと同じWordPress権限を確認すべきです。モデル向けプロトコル経由で呼ばれたからといって、低権限ロールが管理者機能への新しい経路を得てはいけません。

マーケットプレイスレビューに必要なもの

MCPマーケットプレイスとプラグインディレクトリは、認可メタデータをパッケージデータの第一級要素として扱うべきです。サーバーを有効化するか判断するユーザーには、ツール数以上の情報が必要です。

最低限公開すべきメタデータは次のとおりです。

これらの項目が脆弱なツールをなくすわけではありません。しかし、レビュー対象を現実のものにします。運用者は宣言された権限を実際のコードと比較でき、マーケットプレイスは欠陥が見つかったときに類似実装をまとめて扱えます。

ここに、MCP認可仕様とツール複製論文の間に欠けていた橋があります。仕様は、プロトコルレベルのフローをどう実装するかを教えてくれます。エコシステムに必要なのは、パッケージレベルの出所とアクション単位の認可証拠です。そうでなければ、繰り返された実装が、同じ確認漏れも繰り返します。

代わりに何を作るべきか

MCP認可はパイプラインとして作ります。

1. プロトコルの関門: 保護対象リソースのメタデータ、OAuthフロー、トークンの配置、トークンの有効性、有効期限、発行者、オーディエンスを検証します。
2. 主体の関門: トークンをユーザー、サービスアカウント、ロール、テナント、ワークスペースへ対応づけます。
3. ツールの関門: すべてのツールを、読み取り、下書き、書き込み、削除、公開、エクスポート、管理、実行、支出で分類します。
4. リソースの関門: 正確な対象オブジェクトまたはテナント境界に対して認可します。
5. 予算の関門: 実行前に、レート、サイズ、支出、対象範囲、時間の制限を適用します。
6. 承認の関門: 高リスクなアクションには、人間またはポリシーによる承認を必須にします。
7. 監査の関門: 許可、拒否、レビュー必須の判断を、運用者が確認できる場所に記録します。

これらの関門はモデルの外側に置くべきです。ツール説明で、管理アクションを避けるようエージェントに伝えることはできます。プロンプトで慎重さを求めることもできます。しかし、境界を担わせてはいけません。エージェントが丁寧に、確信を持って、あるいは繰り返し依頼してきても、サーバーは認可されていないアクションを拒否すべきです。

エージェントのサンドボックスは提案にすぎませんも、別の角度から同じ点を述べています。有効な権限であっても、組み合わさると危険な挙動になり得ます。エージェントは人間が頭の中で追える速度を超えてアクションを組み合わせるため、MCPツールにはアクション境界での認可が必要です。

FAQ

MCPにOAuthは必須ですか？

いいえ。MCPの認可は任意です。HTTP認可仕様は、実装がHTTPベースのトランスポート上で認可をサポートする場合に適用されます。同じ仕様では、STDIOトランスポートはHTTP OAuthフローに従うのではなく、環境から認証情報を取得すべきだとされています。⁴

OAuthはMCP認可を解決しますか？

OAuthが解決するのは問題の一部だけです。OAuthは認可フローを確立し、トークンを発行し、保護されたMCPサーバーがベアラートークンを検証できるようにします。それでもMCPサーバーは、トークン主体が対象リソースに対して特定のツールアクションを実行してよいかを判断しなければなりません。

CVE-2026-8719は何を証明しましたか？

CVE-2026-8719は、有効なトークンの経路であっても、ローカルの権限強制が抜け落ちることを証明しました。NVDとWordfenceは、AI Engine 3.4.9について、管理者レベルのMCPツールに到達できるようにする前に管理者権限を検証せず、MCPアクセスに対して任意の有効なOAuthトークンを受け入れていたと説明しています。¹²

MCP実装者は最初に何をテストすべきですか？

拒否経路を先にテストしてください。低権限トークンから管理ツールへ、読み取り専用トークンから書き込みツールへ、有効なトークンから別テナントのリソースへ、期限切れトークン、オーディエンス不一致のトークン、承認なしの破壊的ツールです。OAuthの正常系が通ることは、アクション単位の認可を証明しません。

ツール複製はなぜMCPセキュリティに関係しますか？

ツール複製が重要なのは、繰り返された実装が同じ脆弱なミドルウェア、認証・認可の近道、欠けた確認を繰り返し得るからです。2026年5月のツール複製論文は、高類似度のMCP候補で検証済みの複製率が高いことを示し、隠れた重複が脆弱な実装を広げる可能性を警告しました。⁶

参考文献