MCPのセキュリティ｜認証で守れない5つの境界
目次
はじめに
「OAuthを入れたので、このMCPサーバーは安全です」
接続レビューでこの説明を聞いたら、認証と認可をいったん分けたい。認証は主体を確かめる。認可はその主体に何を許すかを決める。OAuthは後者の枠組みであり、接続後のツール引数や出力先まで自動で安全にするものではない。
MCPでは、モデルがツールを選び、サーバーが下流APIを呼ぶ。境界が一段ではない。
MCPのセキュリティで先に仕様化したいのは、次の5つだ。
- 認可サーバーの発行者
- アクセストークンの宛先
- ツール一覧と説明の信頼
- ツール引数と戻り値
- 実行形態と資格情報
MCP のセキュリティは「誰が入れるか」の先にある
MCPは、AIをデータやツールへつなぐ共通規格である。社内検索、ファイル更新、CRM操作を同じ方式で扱える。
2026年7月28日版の仕様では、認可サーバーの取り違え対策、資格情報の発行者への束縛、クライアント登録方式などが強化された。公式の2026-07-28仕様リリース解説を見ると、MCPの認可が単なるログイン画面の追加ではないと分かる。
仕様に準拠したOAuthフローがあっても、悪意あるツール定義や危険な引数は残る。
MCPで守る5つの境界
1. 認可サーバーの発行者を固定する
最初の境界は「誰が認可コードを発行したか」だ。
複数の認可サーバーへ接続すると、認可コードを別の発行者へ誤送信する危険が生まれる。コード交換先を取り違えれば資格情報が漏れ得る。
2026年7月28日版では、認可応答の発行者を示す iss を検証する対策が加わった。TypeScript SDK v2の移行ガイドも、認 可コールバックのissと、検証済みメタデータに記録した発行者が一致しない場合、コード交換前に拒否するよう説明している。
受け入れ条件へは次を書く。
- 認可サーバーのメタデータを検証して保存する
- コールバックの発行者と保存済み発行者を照合する
- 発行者が違えばコードを交換しない
- クライアント資格情報を別の発行者へ使い回さない
- リダイレクトURIを完全一致で検証する
「OAuth接続できた」を合格にせず、別発行者、欠落したiss、改変したリダイレクトURIで拒否できるかをテストする。
2. トークンの宛先をMCPサーバーへ束縛する
次は「そのトークンが、どこ向けに発行されたか」だ。
MCPサーバーが受け取ったトークンを、GitHubやGoogle Driveなどの下流APIへそのまま渡す構成は避けたい。別の宛先向けトークンを受け入れると、サーバーが攻撃者の代理として動く confused deputy の問題につながる。
MCPの認可仕様は、クライアントが対象リソースを指定し、サーバー側が自分向けに発行されたトークンか検証する考え方を示す。下流APIを呼ぶ場合は、MCPサーバーが下流向けの別トークンを取得する。
ここでの検査項目は明確だ。
| 検査 | 合格条件 |
|---|---|
| 発行者 | 許可した認可サーバーと一致する |
| 宛先 | 対象MCPサーバーを示している |
| 期限 | 期限切れを拒否する |
| 権限範囲 | 呼び出す機能に必要な範囲内である |
| 下流接続 | 受信トークンを転送せず、別資格情報を使う |
401と403も分ける。トークンがない、壊れている、期限切れなら401。許可範囲が足りないなら403とし、ログでも区別する。
3. ツール一覧と説明を設定資産として 守る
MCPでは、モデルがツール名、説明、入力スキーマを読んで呼び出し先を選ぶ。つまり、ツールの説明文も実行経路を左右する設定資産だ。
たとえば「検索ツール」に見える説明へ、別ツールの実行を促す指示が混ざっていたらどうだろう。利用者は検索を頼んだだけでも、モデルの選択が変わり得る。接続先の提供元が安全でも、更新後にツール定義が変わることもある。
ツール一覧を毎回無条件に信頼しない。
- 許可するサーバーとツール名を登録する
- ツール説明と入力スキーマの版を記録する
- 差分が出たら自動更新せずレビューへ戻す
- 削除、公開、送信など高リスク機能を別枠にする
- キャッシュ期限後の再取得時も差分を検査する
2026年7月28日版では tools/list などの一覧結果をキャッシュできる。便利だが、古い定義をいつまで使うかという判断も増える。TypeScript SDK v2の2026-07-28対応ガイドを参照し、cacheScopeとttlMsを踏まえて再取得条件を決めたい。
MCPとは何かで扱った通り、ToolsはAIが外部操作を行う入口である。アプリの設定変更と同じように、追加、変更、廃止をレビュー対象にする。
4. ツール引数と戻り値を信頼しない
ツールが正規のものでも、モデルが作った引数は信頼済み入力ではない。メールやWebページに埋め込まれた命令が、モデルを経由して引数へ混ざる恐れがある。
典型例はURL取得ツールだ。「このURLを要約して」という処理で任意URLを受け入れると、社内管理画面やクラウドのメタデータサービスへ到達するSSRFを招き得る。
OWASPのMCP Security Cheat Sheetは、MCPツールの入力を信頼せず検証すること、URL取得に許可リストを使うこと、戻り値も次の処理へ渡す前に確認することを挙げている。
要件はツール単位で書く。
- URLはhttpsのみ、接続先ドメインを限定する
- プライベートIP、localhost、メタデータ用アドレスを拒否する
- ファイルパスは許可した作業領域の内側に限定する
- SQLやシェルコマンドを自由文字列で受け取らない
- 件数、文字数、金額、更新対象に上限を置く
- 戻り値の機密度を判定してからAIの文脈へ入れる
この層はOAuthでは守れない。ツール実装の入力検証と、ホスト側の実行前ポリシーが必要だ。一般的な権限設計とのつながりは、AIエージェントのセキュリティ｜5つの境界へ切り出している。
5. ローカル、リモート、自動実行を分ける
同じMCPサーバーでも、実行形態で守り方が変わる。
ローカルのstdio接続は、OS上のプロセスとして動き、環境変数やファイル権限の影響を受ける。リモートHTTP接続は、ネットワーク、認可サーバー、トークン保管、CORSやOrigin検証が加わる。夜間バッチは人間の同意画面を使えない。
| 形態 | 主な主体 | 先に閉じる点 |
|---|---|---|
| ローカルstdio | 端末利用者 | 起動コマンド、環境変数、作業ディレクトリ |
| リモートHTTP | 利用者本人 | 発行者、宛先、スコープ、Origin |
| 自動実行 | サービスID | 専用資格情報、短い期限、対象ツール |
人間不在の接続には、MCP公式のOAuth Client Credentials拡張がある。長期シークレットを共用せず、用途別のサービス主体を用意する。
企業で接続数が増えたら、個人ごとの設定に任せない。MCP公式のEnterprise-Managed Authorizationは、組織のIdPを基準に、役割とグループで接続を管理し、監査を一元化する方法を示している。
受け入れテストにする5つの失敗ケース
設計書を作って終わらせず、失敗する入力で確認する。
- 別の認可サーバーから返ったコードを拒否する
- 別のMCPサーバー向けトークンを拒否する
- ツール説明や入力スキーマの変更を検知する
- localhostやプライベートIPへのURL取得を 拒否する
- 退職者、期限切れサービスID、許可外ツールを拒否する
各テストには、期待するHTTP状態、監査ログ、再開条件を添える。停止理由を運用担当者が追える状態を合格にする。
Atsumellの視点
MCPを導入すると、接続の実装は速くなる。そのぶん、接続できた時点で完成したように見えやすい。
Atsumellでは、MCPサーバーの一覧より先に、発行者、宛先、ツール定義、引数、実行形態を仕様へ落とす。各項目を拒否条件と受け入れテストへ変えると、認可基盤、MCPホスト、ツール実装の責任分担も見えてくる。
最初の一歩は、利用予定のツールを一つ選ぶことだ。そのツールについて、誰が発行した資格情報を、どの宛先で検証し、どの引数なら受け付け、何が変わったら止めるかを書く。
自社のAIエージェントへMCPを安全に組み込みたい場合は、Atsumellへ相談できる。要件整理、脅威の洗い出し、受け入れ条件、実装、運用の引き継ぎまで一緒に組み立てる。
