MCPのセキュリティ設計｜権限と接続先をどう守るか

接続の許可と操作の許可を分ける

MCPは、AIアプリケーションが外部のデータやツールを扱うためのプロトコルです。接続できるようになることと、その先でどの操作も安全に実行できることは同じではありません。

たとえば社内文書の検索と、検索結果のメール送信を考えます。利用者が文書を読む権限を持っていても、その内容を社外の宛先へ送ってよいとは限りません。この例は編集部が設計上の違いを示すために用意した想定です。実際の事故を再現したものではありません。

最初に分けたいのは、接続する相手、扱うデータ、実行する操作の3つです。OAuthによる認可は、このうちアクセス権を扱う重要な仕組みです。ただし、モデルがツールの返答をどう解釈するか、メールの宛先が妥当かまで自動で決めてくれるわけではありません。

この記事の認可仕様は、2026年9月15日に確認したMCPの2026-07-28版を参照します。この認可フローはHTTP接続が対象で、stdio接続へそのまま適用するものではありません。利用中のクライアントやSDKが、その版へ対応済みとは限らない点にも注意してください。MCP認可仕様

導入時に記録するもの：仕様版、通信方式、クライアントとSDKのバージョン、認可機能の対応範囲。「MCP対応」という表示だけで判断しません。

発行元と宛先は別々に確かめる

認可の確認では、発行元を表すissuerと、トークンの利用先を表すaudienceを混同しないことが重要です。前者が合っていても、後者の確認を省略する理由にはなりません。

認可応答のissは、応答を返した認可サーバーを識別する値です。RFC 9207は、この値を使って認可サーバーの取り違えを防ぐ仕組みを定めています。値を受け取るだけでなく、事前に把握した発行元と照合する必要があります。RFC 9207

一方、アクセストークンを使う段階では、そのトークンが対象のMCPサーバー向けに発行されたかを確認します。MCPの参照版では、認可要求とトークン要求にresourceを指定し、サーバー側も対象リソース向けのトークンか検証することを必須としています。MCP認可仕様

ここから導ける設計上の確認項目は、「誰が発行したか」と「どこで使えるか」を別のテストにすることです。あるサービスへ接続できたトークンを、別サービスへそのまま渡す設計にしない。中継サーバーを置く場合も、受け取った権限と下流サービスの権限を同一視しないようにします。

確認する段階	確認したいこと	それだけでは確認できないこと
認可応答を受け取る	想定した発行元からの応答か	後で実行する操作の妥当性
MCPへアクセスする	対象リソース向けの有効な権限か	文書の内容を外へ送ってよいか
ツールを実行する	利用者・対象・操作が許可範囲内か	返答をAIが常に正しく解釈するか

この表は編集部による確認範囲の整理です。完全なOAuth実装手順ではなく、署名、有効期限、PKCE、リダイレクト先などの検証を置き換えるものではありません。

文字列の「親切な補正」が落とし穴になる

発行元の照合を具体的に確かめるため、編集部は架空のURLだけを使った模擬テストを行いました。外部サービスへ接続せず、実トークンも使っていません。

対象は、参照版の認可仕様にあるissuer照合の条件分岐です。issへの対応を宣言しているのに値がない場合は拒否します。対応宣言がなくても値があれば照合します。宣言も値もない場合に、この確認だけを理由として拒否する仕様ではありません。MCP認可仕様

想定する発行元をhttps://issuer.example.testとしました。フォーム形式から一度デコード済みの入力を比較し、URLとして「同じように見えるから」と補正しない条件を置いています。

模擬入力	判定
対応宣言あり、値が完全一致	他の検証へ進む
対応宣言あり、値が欠落	拒否
対応宣言なし、別の発行元の値あり	拒否
対応宣言なし、値もなし	他の検証へ進む
ホスト名を大文字へ変更	拒否
末尾にスラッシュを追加	拒否

既定ポートやパーセント表記を勝手に正規化しないケースも含め、2026年9月15日の実行では15件すべてが想定どおりの結果になりました。信頼済みの比較対象がない場合に止める、編集部独自の防御条件も含まれます。

重要なのは、成功時の結果を「認可成功」ではなく「他の検証へ進む」とした点です。ひとつの照合が通っただけで認可フロー全体を通過したことにすると、未確認の条件が見えなくなります。

この検証には、メタデータ取得、フォームのデコード、重複パラメーター処理、トークン交換、署名やaudienceの検証を含めていません。特定SDKの脆弱性検査でも、プロンプトインジェクションの耐性試験でもありません。模擬関数を本番の認可処理へコピーして利用することは想定していません。

読み取り専用でも外へ漏れる

操作を制限するとき、「書き込みを許可していないから安全」とは判断しないようにします。社内文書を読む権限と、外部サイトへ検索リクエストを出す権限が同じAIにあれば、送信内容の制限も検討対象になります。

OWASPのMCP Security Cheat Sheetは、ツールの説明や返答を通じた指示の混入、過剰な権限、情報流出などを扱っています。以下はそれらの論点を、先ほどの文書検索・メール送信の想定へ当てはめた編集部の点検表です。MCP仕様の必須要件一覧ではありません。OWASP MCP Security Cheat Sheet

操作	先に決める制限	実行時に確かめる内容	異常時に止める単位
社内文書を読む	利用者ごとの閲覧範囲	対象文書への権限	対象ツール・認証情報
下書きを保存する	保存先と更新できる項目	上書き対象と差分	書き込み権限
メールを送る	宛先の範囲と送信対象	宛先、添付、本文、件数	送信機能
外部APIへ問い合わせる	接続先と送ってよいデータ	URLと送信パラメーター	外向き通信

「異常時に止める単位」を先に決めるのは、問題を見つけても全システム停止しか選べない状態を避けるためです。ただし、漏えいが疑われる場合に一部機能の停止だけで十分とは限りません。影響範囲に応じて認証情報の失効や接続全体の停止を判断します。

この想定でまず試すなら、実在の顧客情報ではなく架空の文書と宛先を用意します。「文書は読めるが外部へ送れない」「承認した宛先から変更すると再承認になる」といった期待結果を先に書き、機能追加のたびに確かめます。これらの操作テストは、本記事のissuer模擬テストでは未実施です。

承認画面とログも設計する

人の承認を入れる場合、画面に「実行してよいですか」とだけ表示しても、利用者は影響を判断できません。想定したメール送信なら、宛先、添付する文書、送信する本文を確認できる形にします。

さらに、承認した内容と実際に実行する内容が一致しているかを確認します。承認後に宛先が変わるなら、その承認を使い回さない。これは本記事の想定に対する設計提案であり、特定のMCPクライアントにこの機能が実装されていると述べるものではありません。

承認文そのものを、ツールから返った文章へ任せないことも確認点です。外部から来たデータが、自分自身を「承認済み」と判定できる構造にしない。実行許可は、アプリケーション側で管理する利用者の操作と権限に結び付けます。指示の混入と実行制御の関係は、プロンプトインジェクションの解説でも整理しています。

承認の点検例：表示した宛先・本文・添付と実際の引数が一致するか。変更後に古い承認を再利用できないか。ツールの返答だけで承認済みにならないか。

ログについても、詳しく残すことと安全に残すことを分けます。想定例では、実行時刻、ツール識別子、操作種別、承認の有無、成功・拒否の理由を調査の手がかりにします。一方、アクセストークンや文書本文を無条件に保存すると、ログが別の機密情報の保管場所になります。保存項目、閲覧者、保存期間を一緒に決めてください。

ツール説明の変更を検知する仕組みも有用ですが、変更がないことは安全性の証明ではありません。最初から不適切な説明なら、その説明を固定しても問題は残ります。更新の検知と、導入時の内容確認は別の工程として扱います。OWASP MCP Security Cheat Sheet

よくある質問

OAuthを使えば十分ですか

十分とはいえません。認可の確認に加え、ツールごとの操作範囲、扱うデータ、外部送信の制限を設計します。この記事ではメール送信を例に、承認対象の確認も分けました。

ローカルで動けば安全ですか

ローカル実行だけでは判断できません。プロセスが読めるファイル、利用できる認証情報、外向き通信を確認してください。通信方式がstdioであること自体は、実行環境の隔離を意味しません。OWASP MCP Security Cheat Sheet

読み取り権限だけにすればよいですか

被害の範囲を狭める出発点にはなります。ただし、読んだ内容を別のツールで送信できる場合があります。複数ツールを組み合わせたときのデータの行き先も確認します。

テスト15件成功は安全性の証明ですか

違います。限定した入力に対する、発行元の文字列照合と条件分岐の確認です。実際のMCPサーバー、認証フロー全体、攻撃への耐性は検証していません。

導入前は何から確認しますか

利用中の仕様版と実装を記録し、接続先、利用者、読み取り・書き込み・外部送信の権限を一覧にします。そのうえで、拒否すべき操作と停止方法をテスト項目にします。

まとめ

• 接続できることと、操作を許可してよいことは別です。発行元、トークンの利用先、具体的な操作を段階ごとに確認します。
• 読み取り専用でも、別のツールを通じた外部送信は検討対象です。権限はツール単体だけでなく、組み合わせたときの情報の流れで点検します。
• テスト結果には範囲を付けます。小さな照合テストの成功を全体の安全性へ広げず、承認、ログ、停止・復旧の工程を残すことが実務での持ち帰りです。

出典・参考

• MCP Specification 2026-07-28：Authorization — HTTPで保護されたMCPへの認可要件。必須条件と推奨を区別して参照。
• RFC 9207：OAuth 2.0 Authorization Server Issuer Identification — 認可応答の発行元識別。
• OWASP MCP Security Cheat Sheet — 別系統の確認資料。運用上の推奨をMCP標準の必須要件とは扱わない。
• TechCreate編集部：2026年9月15日実施のissuer条件分岐の模擬テスト。Node.js標準のテスト機構を使用、15件成功。実サービス・実トークンを使用しない限定的な検証。