本番環境の MCP セキュリティ

MCP サーバーは「もう一つの API」ではありません。モデルが読み取り、それに従って行動する命令チャネルです。ツール名も、パラメータの説明も、ツールが返す文字列も、すべてユーザーのリクエストと同じコンテキストウィンドウに入り、モデルにはデータと命令を確実に区別する手段がありません。この一点だけで、Model Context Protocol のセキュリティは API セキュリティとは別の分野になり、2026 年の事故がこれほど似通った形で繰り返された理由も説明できます。

本稿は脅威モデリングの論考ではなく運用ガイドです。仕様がすでに義務づけている内容、2026 年の事故が実際に破ったもの、そして本番で持ちこたえる対策を、検証コマンド付きで扱います。

MCP が脅威モデルの前提をどう変えるか

従来の連携では、どの呼び出しを、どの引数で、コードのどこで行うかを開発者が決めていました。MCP では、接続されたすべてのサーバーのツール定義をクライアントがモデルに渡し、モデルが何をどんなパラメータで呼ぶかを決めます。OWASP はその帰結を端的に述べています。MCP はプロンプトインジェクション、サプライチェーンリスク、混乱した代理人問題を一箇所にまとめてしまう、と。^[owaspcs]

• ツールのメタデータはほぼ実行内容として働く。説明文や JSON Schema はモデルに指示として読まれます。汚染された description フィールドは、ドキュメントというより注入されたコードに近い存在です。
• ツールの出力は信頼できない入力。Web ページ、issue のタイトル、データベースの 1 行が、システムプロンプトと同じ立場でコンテキストに戻ってきます。
• モデルはすべてのサーバーを同時に見ている。悪意あるサーバーのツール説明が、別の信頼済みサーバーの使われ方を変えてしまう。これがツールシャドーイングで、サーバー単位のレビューでは見つかりません。^[owaspcs]

仕様はこれを肩代わりしないと明言しています。認可は MCP 実装にとって任意であり、HTTP トランスポートを使う場合は仕様に従うべき、stdio 実装は環境から資格情報を取得すべき、とされています。^[spec-auth]それ以外のサンドボックス化、ツール完全性、外向き通信の制御は、ホスト・クライアント・サーバーを出荷する側の責任です。

基準を決めた 2026 年の事故

今年もっとも明快な 2 つの事例は、特殊な実験環境ではなくベンダー自身のデフォルト構成から出ました。2026 年 8 月 5 日の Black Hat USA で Novee Security は、Anthropic と Google と OpenAI のコーディングエージェントを、各ベンダーが既定で出荷している構成のまま検証しました。ここから CVE が 2 件生まれ、いずれも修正済みです。ただし 2 件が実際に許した操作は大きく異なり、その差こそが要点です。^{[ghsa-google][ghsa-anthropic]}

このパターンは正確に述べる価値があります。3 製品にとどまらず一般化するからです。破綻したのはモデルではなくハーネスでした。ある部品が値を「安全」と印を付け、後続の部品がより強い権限でその値に基づいて動いたのです。2026 年 8 月 7 日時点の報道では両 CVE とも CISA の「悪用が確認された脆弱性カタログ」には載っておらず、公開情報にも実標的への使用は見当たりません。重要なのは欠陥の種類であって、進行中の攻撃活動ではありません。

これはDevOps と MLOps と LLMOps の運用モデルと合わせて読んでください。ある動作を生んだ正確な束——モデル、プロンプト、ツールスキーマ、ポリシー——を言えないなら、インシデントは説明できず、ロールバックも信用できません。

仕様がすでに義務づけている基準線

「MCP セキュリティ」の作業のかなりの部分は、要するに OAuth をきちんとやることです。2025-06-18 改訂で MCP サーバーは純粋な OAuth 2.1 のリソースサーバーとして再定義され、2025-11-25 改訂ではディスカバリーと同意がさらに整理されました。^[spec-log]リモートの MCP サーバーを運用しているなら、以下は推奨ではありません。^{[oauth21][rfc9700][nsa]}

ディスカバリー: README ではなく RFC 9728

MCP サーバーは OAuth 2.0 Protected Resource Metadata を実装しなければならず、authorization_servers に少なくとも 1 件を公開しなければなりません。クライアントはそれをディスカバリーに使わなければなりません。未認証リクエストに対しては 401 を返し、WWW-Authenticate ヘッダーでメタデータ文書の位置を示します。^{[spec-auth][rfc9728]}

curl -sSI https://mcp.example.com/mcp | grep -i '^www-authenticate'
# www-authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource"

curl -sS https://mcp.example.com/.well-known/oauth-protected-resource \
  | jq '{resource, authorization_servers, scopes_supported}'

curl -sS https://auth.example.com/.well-known/oauth-authorization-server \
  | jq '{issuer, token_endpoint, code_challenge_methods_supported}'

オーディエンス束縛: トークン使い回しを止める要

クライアントは RFC 8707 の resource パラメータを、認可リクエストとトークンリクエストの両方で、対象サーバーの正規 URI を値として送らなければなりません。認可サーバーが対応していなくても送る必要があります。^[rfc8707]サーバー側は、提示されたトークンが自分向けに発行されたものであることを検証しなければならず、そうでなければ拒否します。^[spec-auth]

トークンパススルー——自分宛でないトークンを受け取り、そのまま下流へ転送すること——は明示的に禁止されています。仕様の論拠は運用面です。監査証跡が壊れ、オーディエンスに依存するレート制限やリクエスト検証が迂回され、盗まれたトークンを持つ者にとってあなたのサーバーがプロキシになってしまう。^[spec-sec]MCP サーバーが上流 API を呼ぶなら、そこではクライアントであり、自分専用のトークンが必要です。

CANONICAL = "https://mcp.example.com/mcp"   # RFC 8707 resource identifier

def authorize(token: dict) -> None:
    aud = token.get("aud")
    aud = aud if isinstance(aud, list) else [aud]
    if CANONICAL not in aud:
        raise Unauthorized("token audience does not include this server")   # 401
    if not required_scopes(token).issuperset(scopes_for_current_tool()):
        raise Forbidden("insufficient scope")                               # 403
    # Never forward `token` upstream. Mint a separate one for the upstream API.

クライアント登録: CIMD が推奨の既定に

2025-11-25 改訂は、推奨のクライアント登録方式として OAuth Client ID Metadata Documents（SEP-991）を追加し、あわせて OpenID Connect Discovery 対応と WWW-Authenticate による段階的スコープ同意を導入しました。^{[spec-log][cimd]}CIMD では client_id が HTTPS の URL であり、その先にクライアントを記述した小さな JSON 文書が置かれます。認可サーバーは必要に応じてそれを取得し、登録済みリダイレクト URI を検証し、自身のポリシーを適用します。事前調整も不要で、動的クライアント登録が生む使い捨て登録の山も生じません。

これが重要なのは、DCR が混乱した代理人攻撃の材料の一つだからです。プロキシとして働く MCP サーバーがサードパーティ認可サーバーに対して静的な client ID を使い、かつクライアントの動的登録を許し、さらにサードパーティが同意 cookie を設定していると、攻撃者は自分の redirect_uri でクライアントを登録し、被害者の cookie を利用して同意画面を飛ばし、認可コードを回収できます。対策は、サーバー側に保存したクライアントごとの同意をサードパーティのフローに入る前に確認すること、リダイレクト URI の完全一致検証、そして使い捨ての state です。^[spec-sec]

いずれも新しいアイデンティティ工学ではありません。スケールする IAM の設計と同じ規律であり、Keycloak と Entra ID の選択で現れるトレードオフと同じです。すでに運用・監査している認可サーバーを再利用し、MCP サーバーごとに独自の認可を生やさせないことです。

10 の失敗パターンと、それぞれを塞ぐ対策

OWASP MCP Top 10 はベータ（v0.1）のリビングドキュメントで、次版は 2026 年 10 月予定です。認証取得の目標ではなくチェックリストとして扱うのが妥当でしょう。^[owasp10]

層ごとの堅牢化

ツール定義を固定するか、rug pull を受け入れるか

rug pull が成立するのは、ツールを一度承認したあと誰も見直さないからです。対策は機械的で、承認時に定義をハッシュ化し、呼び出しのたびに検証します。

import hashlib, json

def tool_fingerprint(tool: dict) -> str:
    canonical = json.dumps(
        {"name": tool["name"],
         "description": tool.get("description", ""),
         "inputSchema": tool.get("inputSchema", {})},
        sort_keys=True, separators=(",", ":"), ensure_ascii=False)
    return hashlib.sha256(canonical.encode()).hexdigest()

if tool_fingerprint(live_tool) != PINNED[server_id][live_tool["name"]]:
    raise ToolDefinitionDrift(server_id, live_tool["name"])   # fail closed

失敗時は閉じる方向に倒します。承認後に説明が変わったツールは新しいツールであり、静かなリトライではなく人による新しい判断が必要です。

ローカルサーバーを本気で隔離する

ローカルの MCP サーバーは、クライアントの権限で動くバイナリです。ワンクリック設定に関する仕様の指示は明快です。実行されるコマンドを省略せずそのまま表示し、クライアント権限で動くと警告し、ファイルシステムとネットワークへの既定アクセスを最小にしてサンドボックス化すること。^[spec-sec]ローカルでは stdio が望ましく、到達範囲をクライアントプロセスに限定できます。HTTP が必要なら 127.0.0.1 にバインドし——0.0.0.0 は避け——トークンを必須とし、リクエストごとに Host ヘッダーを検証します。^[owaspcs]

docker run --rm -i \
  --network none \
  --read-only --tmpfs /tmp:rw,noexec,nosuid,size=64m \
  --cap-drop ALL --security-opt no-new-privileges \
  --pids-limit 128 --memory 512m --cpus 1 \
  --user 10001:10001 \
  -v "$PWD/workspace:/workspace:ro" \
  ghcr.io/example/mcp-server@sha256:<digest>

@sha256: のダイジェストは好みの問題ではなくサプライチェーン対策です。タグは差し替えられますが、ダイジェストは差し替えられません。すでに Kubernetes でワークロードを動かしているなら、Kubernetes を使うべきでない場面と同じ影響範囲の考え方が当てはまります。MCP サーバーごとにコンテナ 1 つは妥当ですが、MCP サーバーごとにコントロールプレーン 1 つは行きすぎです。

外向き通信を制御する: SSRF はディスカバリー経路にある

これはサーバーではなくクライアントを狙うため見落とされがちです。OAuth ディスカバリーの過程で、クライアントはサーバーから与えられた URL を取得します。WWW-Authenticate の resource_metadata、authorization_servers の各エントリ、そして AS メタデータ内のエンドポイントです。悪意あるサーバーはそのいずれかを http://169.254.169.254/ に向け、あなたのクライアント経由でクラウドインスタンスの資格情報を読み出せます。^[spec-sec]

クライアントはループバック以外で HTTPS を必須とし、プライベートおよびリンクローカル範囲（10/8、172.16/12、192.168/16、127/8、169.254/16、fc00::/7、fe80::/10）を遮断し、同じ規則をリダイレクトの各ホップにも適用し、サーバー側デプロイは外向きプロキシ経由にすべきです。仕様は IP 検証の自作を明確に戒めており——8 進・16 進・IPv4 射影 IPv6 の表記が多くの自作パーサーを突破します——検証と使用の間の DNS リバインディングにも注意を促しています。^{[spec-sec][owaspssrf]}

CI 上のコーディングエージェント: 手元でもっとも価値の高い標的

CI 上のエージェントはリポジトリへの書き込み権限とワークフローシークレットを持ち、その入力は見知らぬ誰かが issue に書いた文章です。Black Hat の研究が攻撃したのは、まさにこの構成でした。

on:
  issues:
    types: [opened]

permissions:
  contents: read
  issues: read
  id-token: none

jobs:
  triage:
    runs-on: ubuntu-latest
    environment: agent-sandbox
    timeout-minutes: 10
    steps:
      - uses: actions/checkout@<commit-sha>
        with: { persist-credentials: false }

      - run: printf '%s' "$ISSUE_BODY" > /tmp/untrusted.md
        env:
          ISSUE_BODY: ${{ github.event.issue.body }}

      - run: agent-cli review --input /tmp/untrusted.md --sandbox read-only --no-network

• 絶対に ${{ github.event.* }} を run: の文字列に展開しないこと。環境変数かファイル経由で渡します。
• リポジトリ内の指示ファイルは信頼できない入力です。1 つのチェックアウトを共有した 2 回の Codex 実行で、1 回目が 2 回目の指示を書けてしまった件を受け、OpenAI 自身のガイダンスがそう明記しています。^[codex]
• エージェントはジョブの最後に実行する。同じガイダンスは、そうしないと後続の特権ステップにファイルを残す可能性があると警告しています。^[codex]
• 実行を別ジョブに分ける。チェックアウトも分ければ、前の実行が次の入力を書き換えられません。
• ハーネスにパッチを当てる。Gemini CLI 0.39.1、run-gemini-cli 0.1.22、Claude Code 2.1.163。そのうえで外部から起動できるワークフローをすべて監査します。

監査: すべてのツール呼び出しを再現可能にする

OWASP はテレメトリの欠如を独立したリスクとして挙げており、これは封じ込められたはずのインシデントを際限のないものに変えます。^[owasp10]呼び出しごとの最低限の記録は、認証済みの呼び出し元 ID、サーバーとツール、検証に通ったツール指紋、秘密情報をマスクした完全なパラメータ、判断経路（自動承認・ポリシー許可・人による承認）、結果、レイテンシ、そしてエージェント実行全体を束ねる相関 ID です。初めて見るツール、スコープの昇格、ツール出力中の指示めいたパターンには警報を設定します。

サーバーが数台を超えても運用可能にする構造的な判断が 2 つあります。第一に、前段にゲートウェイを置くこと。許可リスト、サーバー単位の分離、外向きポリシー、ログ収集を一箇所で強制するほうが、同じポリシーを各ホストで実装し直すより優れています。第二に、可能な限り退屈な答えを選ぶこと。退屈なクラウドアーキテクチャの論旨がそのまま当てはまります。可動部品が少なく、信頼境界が少なく、混乱した代理人が隠れる場所も少ない。同じ抑制はエージェントスタックを組む段階からすでに効いてきます。

今日から回せる検証パス

9 項目です。1) 未認証リクエストが有用なポインタ付きで拒否される、2) 保護リソースメタデータが公開されている、3) 別オーディエンス向けトークンが拒否される、4) 平文 HTTP が受け付けられない、5) ローカルサーバーが全インターフェースで待ち受けていない、6) ツール定義が承認時と一致する、7) イメージがダイジェストで固定されている、8) シェルステップにイベントデータが展開されていない、9) ハーネスが修正版以上である。

# 1
curl -sS -o /dev/null -w '%{http_code}\n' https://mcp.example.com/mcp

# 2
curl -sSf https://mcp.example.com/.well-known/oauth-protected-resource | jq -e '.authorization_servers[0]'

# 3
curl -sS -o /dev/null -w '%{http_code}\n' -H "Authorization: Bearer $TOKEN_FOR_OTHER_AUDIENCE" \
  https://mcp.example.com/mcp

# 4
curl -sS -o /dev/null -w '%{http_code}\n' http://mcp.example.com/mcp

# 5
ss -ltnp | grep -E '0\.0\.0\.0|\[::\]'

# 6
mcp-inspect list-tools --server internal | sha256sum

# 7
grep -rEn 'image:\s*\S+:(latest|main|v?[0-9]+)\s*$' deploy/

# 8
grep -rn 'github\.event\.\(issue\|comment\|pull_request\)' .github/workflows/ | grep 'run:'

# 9
gemini --version; claude --version

3 番は初回でもっとも落ちやすい項目であり、同時に仕様の記述がもっとも明確な項目でもあります。

今週やるべきこと

MCP は採用する価値があります。この protocol は実在する連携の手間を一掃しますし、2025-11-25 改訂は重要なセキュリティ判断を口伝から仕様本文へ移しました。ただし提供されるのは機能であって、コントロールプレーンではありません。効く対策は、アイデンティティとサプライチェーンの仕事ですでに馴染みのあるものを、多くのチームがまだ引いていない境界に適用するだけです。

優先順に、ハーネスへのパッチ適用、オーディエンス検証の必須化、ツール定義とイメージダイジェストの固定、ローカルサーバーの隔離と外向き通信の遮断、そして破壊的な操作の手前に人によるゲートを置くこと。今後 12 か月で痛い目を見るのは、MCP を採用した組織ではなく、採用したうえでハーネスを既定のまま放置した組織です。

よくある質問

MCP は既定で安全ですか？

安全ではありませんし、仕様もそう主張していません。認可は MCP 実装にとって任意であり、サンドボックス化、ツール完全性、ネットワークポリシーはホスト・クライアント・サーバーを作る側に委ねられています。ローカルにインストールした MCP サーバーは、それを起動したクライアントと同じ権限で動きます。

MCP におけるツール汚染とは何ですか？

エージェントが依存するツールを操作し、モデルの振る舞いを変える攻撃です。OWASP は 3 つの下位手法をまとめています。承認済みツールの説明を後から書き換える rug pull、インターフェース定義自体がモデルを誤導するスキーマ汚染、そして悪意あるサーバーの説明が別の信頼済みサーバーのツールの使われ方を変えるツールシャドーイングです。名前・説明・入力スキーマのハッシュを固定し、呼び出しのたびに検証すれば、前 2 つは塞げ、3 つ目は検知できます。

MCP サーバーに OAuth は必須ですか？

リモートの HTTP トランスポートでは事実上必須です。仕様は HTTP ベースの実装が OAuth 2.1 モデルに従うべきだとしています。サーバーはリソースサーバーとして振る舞い、RFC 9728 の保護リソースメタデータを実装し、提示されたトークンが自分向けに発行されたことを検証しなければなりません。ローカルの stdio サーバーは環境から資格情報を取得しますが、サンドボックスと同意の制御は依然として必要です。

トークンパススルーとは何で、なぜ禁止されているのですか？

自分宛に発行されていないトークンを受け取り、そのまま下流の API へ転送することです。MCP 仕様はこれを明示的に禁じています。監査証跡が壊れ、トークンのオーディエンスに依存する制御が迂回され、盗んだトークンを持つ者があなたのサーバーを流出用プロキシとして使えるようになるからです。上流 API を呼ぶ MCP サーバーは、その API 用のトークンを自分で取得しなければなりません。

MCP の脆弱性は実際に悪用されていますか？

掲載時点で CVE-2026-12537 も CVE-2026-54316 も CISA の悪用確認済み脆弱性カタログには載っておらず、公開報道にも標的への使用は見当たりません。Claude Code の問題については 2026 年 6 月から公開の再現用リポジトリが存在するため、律速となるのはエクスプロイトの入手性ではなくパッチ適用の速度です。

悪意ある MCP サーバーが社内ネットワークに到達するのをどう防ぎますか？

露出点は OAuth ディスカバリー経路です。クライアントがサーバー提供の URL を取得するため、悪意あるサーバーはそれをクラウドメタデータのエンドポイントや内部サービスに向けられます。ループバック以外では HTTPS を必須にし、プライベートおよびリンクローカル範囲を遮断し、同じ検証をリダイレクトの各ホップに適用し、サーバー側クライアントは外向きプロキシ経由にしてください。IP 検証は自作しないことです。

Client ID Metadata Documents（CIMD）とは何ですか？

MCP の 2025-11-25 改訂に SEP-991 として推奨の既定で追加されたクライアント登録方式です。client_id は HTTPS の URL で、その先にクライアントとリダイレクト URI を記述した JSON 文書があり、認可サーバーが必要に応じて取得・検証します。ハードコードされた client ID も、動的クライアント登録が生む使い捨て登録の山も避けられ、混乱した代理人攻撃の材料が一つ減ります。

出典と参考文献

本稿で用いた仕様本文、IETF の RFC、OWASP プロジェクト資料、NSA のサイバーセキュリティ情報シート、およびベンダー一次情報のアドバイザリ。

1. Model Context Protocol — Authorization (specification 2025-11-25)
2. Model Context Protocol — Security Best Practices
3. Model Context Protocol — Key Changes, revision 2025-11-25
4. SEP-991 — OAuth Client ID Metadata Documents for MCP
5. RFC 9728 — OAuth 2.0 Protected Resource Metadata
6. RFC 8707 — Resource Indicators for OAuth 2.0
7. RFC 9700 — Best Current Practice for OAuth 2.0 Security
8. OAuth 2.1 — draft-ietf-oauth-v2-1-13
9. OWASP MCP Top 10 (beta, v0.1)
10. OWASP Cheat Sheet Series — MCP Security
11. OWASP Cheat Sheet Series — SSRF Prevention
12. NSA Artificial Intelligence Security Center — CSI: MCP Security Design Considerations for AI-Driven Automation
13. GHSA-fg94-h982-f3mm — Out-of-Band Data Exfiltration via Pre-Approved HuggingFace Domain in WebFetch
14. NVD — CVE-2026-54316
15. GHSA-wpqr-6v78-jr5g — Google run-gemini-cli security advisory
16. NVD — CVE-2026-12537
17. OpenAI — codex-action security guidance