MCPサーバーのセキュリティチェックリスト：導入・自作前に確認する項目

MCPサーバーを導入・自作する前に、何を確認すればよい？

1分要約

• サーバー、ツール定義、返却データ、同じクライアントにつながる別サーバーを、すべて信頼境界として扱います。
• 配布元とバージョンを固定し、ツール定義の変更を検知し、機能ごとに必要最小限の権限だけを与えます。
• OAuthトークンのaudienceを検証し、ローカル実行を隔離し、重要操作は内容を示して承認を取り、監査ログを残します。

どんな人向けか

サードパーティ製MCPサーバーの選定、AIクライアントへの追加、社内データへのアクセスや操作を行うサーバーの自作を担当する人向けです。

結論

MCP接続は、便利なプラグインを追加するだけではなく、コードとデータの境界を増やすことです。有効化する前に、配布元、実行されるコード、各ツールが読み書きできる対象、導入後の変更検知方法を確認します。

リモートサーバーでは呼び出し元を認証し、アクセストークンがそのMCPリソース向けに発行されたことを検証します。ローカルサーバーは、制限しない限り起動元と同じOS権限で動く子プロセスとして扱います。どちらの場合も、ツールの説明文や返却値には間接プロンプトインジェクションが含まれ得ます。モデルが安全に解釈することだけに承認やポリシーを頼ってはいけません。

解説

ツールポイズニングと定義変更

ツールの説明文、引数スキーマ、注釈、返却内容はモデルのコンテキストに入ります。一見普通のメタデータや出力に悪意ある指示を紛れ込ませ、別のツールを使わせたり、データを開示させたりできます。Invariant Labsはこれをツールポイズニングとして報告し、あるサーバーの説明文が別の信頼済みサーバーの使い方にまで影響する「シャドーイング」も示しました。

レビューや承認のあとにツール定義が変わることもあります。この「ラグプル」では、過去に確認した内容は現在も同じである証明になりません。更新時や、クライアントが対応する場合は実行時にも定義を比較し、説明できない変更があれば利用を止めて再確認します。

間接プロンプトインジェクションはデータフローの問題

メール、Webページ、issue、文書、ツール出力には、エージェントを操作する命令が含まれる可能性があります。こうした内容はポリシーではなくデータとして扱います。機密データを無関係な書き込み・ネットワークツールへ流さず、モデルの外にあるサーバーコードでも操作先と権限を検証してください。

ローカル実行とリモート認可のリスクは異なる

stdio を使うMCPサーバーは、起動元のOS権限でコードを実行する子プロセスです。通信方式そのものに隔離機能はありません。実行コマンドと引数、パッケージとインストールスクリプト、環境変数、ファイルとネットワークへのアクセスを確認し、可能なら制限ユーザーやサンドボックスで実行します。

リモートHTTP認可では、issuer、署名、有効期限、scopeに加えて、audience（aud）がMCPサーバー自身のリソース識別子と一致するかを検証します。別API向けトークンを受け入れてはいけません。また、受け取ったクライアントのトークンをそのまま下流APIへ転送せず、別途スコープを絞った資格情報を使うか、明示的なトークン交換を設計します。

実務ガイド

1. 出所と変更管理を確認する

• 公式リポジトリや検証済みの配布元を優先し、パッケージ名、リポジトリ、リリース、メンテナーを照合します。
• リリースまたは変更不能なコミットを固定し、依存関係もロックします。配布元で利用可能な完全性情報や署名、インストールスクリプトを確認します。
• 機密機能を持つものはソースコードを読み、必要なら対象を絞ったセキュリティレビューを受けます。スキャナーは説明文の不審箇所探しに役立ちますが、安全性を証明しません。
• ツール名、説明文、入力スキーマ、注釈、サーバーバージョンの基準を保存します。変更があれば検知し、再レビューします。

2. 権限を必要最小限にする

• 各サーバーに必要なデータ、ファイルパス、接続先、APIスコープだけを与えます。
• 読み取りと書き込み・破壊的操作を分けます。汎用shell、SQL、ファイル操作、任意URL取得より、目的を限定したツールを優先します。
• サーバーごとに資格情報を分離します。秘密情報をソース、プロンプト、ツール説明、ログ、共有設定に埋め込まないようにします。
• リモートサーバーではすべての要求と対象オブジェクトごとに認可します。利用者IDはツール引数ではなく、検証済み資格情報から特定します。

3. OAuthと通信を保護する

• リモートMCPエンドポイントではHTTPSを使い、MCPリソースの境界でトークンを検証します。
• tokenのissuer、署名、有効期限、scope、audienceを検証し、別リソース向けトークンは拒否します。
• トークンパススルーを実装しません。呼び出し元のMCPアクセストークンを変更せず下流APIへ転送してはいけません。
• 有効期間を短くし、scopeを絞ります。Bearer tokenや認可コードはログに出しません。

4. stdio とツールの挙動を制限する

• 起動前に実行ファイル、引数、パッケージバージョン、作業ディレクトリ、環境変数を確認します。
• 本番環境ではバージョン未固定のnpxやパッケージ実行を避けます。不要なネットワークを切り、必要なパスだけを可能なら読み取り専用で渡します。
• 入力を厳格なスキーマと業務ルールで検証し、未定義フィールドや危険なパス、コマンド、URLを拒否します。
• ツール出力も信頼せず、サイズを制限します。返却された指示だけで高権限の後続ツールが自動実行されないようにします。

5. 承認とログを実効性のあるものにする

• 外部へのデータ送信、記録の変更・削除、金銭に関わる操作、権限拡大には明示的な人の承認を求めます。
• 承認画面には操作の内容と重要な引数を省略せず表示します。サーバー導入時の承認を、今後すべてのツール実行への包括承認として扱いません。
• サーバー識別子とバージョン、ツール名、判断、時刻、利用者・要求ID、結果を記録します。秘密や不要な機微データはマスクし、ログへのアクセスと保存期間をポリシーに合わせます。
• プロンプトインジェクションによる拒否対象の操作、サーバー間のデータ流出、未承認の呼び出しをテストします。期待する遮断と違反時のアラートを記録します。

ありがちな落とし穴

• 表示名だけを見て承認し、説明文や入力スキーマ全体を読まない。
• パッケージ、サーバー実装、ツール定義が変わった後も、初回レビューを安全性の根拠にする。
• stdioならサンドボックスだと考えたり、localhostなら他のローカルプロセスから到達できないと思い込む。
• 有効なトークンであればaudienceが違っても下流に転送してよいと考える。
• データを隔離しコードで認可する代わりに、「モデルがその指示を無視する」ことに頼る。
• プロンプト、引数、結果を丸ごと記録し、資格情報や個人情報の二次保管場所を作る。

チェックリスト

• [ ] 配布元、リポジトリ、パッケージ名、リリースの出所を確認した。
• [ ] 依存関係と実行バージョンを固定し、更新前に差分をレビューする。
• [ ] 現在のツール説明、スキーマ、注釈を確認した。
• [ ] 定義変更を検知し、再レビューを開始できる。
• [ ] 権限と資格情報をサーバー・タスクごとに必要最小限にした。
• [ ] リモート要求で認証とオブジェクト単位の認可を行う。
• [ ] OAuthのissuer、署名、有効期限、scope、audienceを検証する。
• [ ] 受け取ったアクセストークンを下流APIへそのまま転送しない。
• [ ] ローカルstdioのコマンド、引数、環境変数、インストールスクリプトを確認する。
• [ ] ローカルプロセスを隔離するか、ファイルとネットワーク権限を絞る。
• [ ] 入出力を検証・制限し、信頼できないデータとして扱う。
• [ ] 重要・破壊的操作は、主要な引数を示して承認を求める。
• [ ] 間接プロンプトインジェクションとサーバー間データフローをテストする。
• [ ] 秘密や不要な生データを保存せず、調査に使えるログを残す。

FAQ

stdioなら自動的に安全ですか？

いいえ。直接ローカル接続でネットワークリスナーを公開せずに済む場合はありますが、起動元の権限でプロセスを実行します。プロセスを確認し、制限してください。別のプロキシがstdio子プロセスを起動する構成では、プロキシ側のコマンド実行境界も加わります。

MCPサーバーの承認にスキャナーだけで十分ですか？

いいえ。スキャナーは不審なツールメタデータや既知のパターンを見つける補助になります。配布元の信頼性、実行コード全体の監査、安全な実行時挙動、将来の定義変更までは証明しません。

MCPサーバーはaudienceが異なるアクセストークンを受け入れてよいですか？

いいえ。そのリソース向けに発行されたトークンだけを受け入れます。別サービス向けトークンをパススルーすると、リソース間の境界が壊れ、confused deputyにつながることがあります。

参考資料

• MCP Security Best Practices
• OWASP MCP Security Cheat Sheet
• Invariant Labs: MCP Security Notification—Tool Poisoning Attacks

内部リンク

• ハブ：AI開発
• 関連記事：
  • プロンプトインジェクション対策チェックリスト
  • npmサプライチェーン攻撃対策チェックリスト
  • RAGのデータ汚染対策チェックリスト

免責事項

一般的なセキュリティ情報です。対策を適用する前に、MCP仕様、利用するクライアント、IDプロバイダー、実際の運用環境を確認してください。