MCPサーバーセキュリティ確認 ─ 権限・トークン・ログ

冒頭要約

MCP（Model Context Protocol）は、LLMアプリケーションが外部データやツールへ接続するための標準化された仕組みです。便利な一方で、MCPサーバーがSaaS、リポジトリ、データベース、チケット、社内文書へ接続すると、AIエージェントは「読むだけのチャット」ではなく、権限を持つ実行者になります。

まず確認すべきことは、攻撃手順ではありません。誰の権限で、どのツールを、どのデータに、どの操作まで許可するかです。2026年6月26日時点で公開情報から確認できる範囲では、MCP公式ドキュメント、NSAのMCPセキュリティ設計考慮事項、OWASP LLM Top 10はいずれも、認可、scope最小化、監査、過剰な自動実行への注意を重視しています。

この記事では、MCPサーバーを社内AI、AI Gateway、開発環境、SaaS連携に接続する前後で、情シス、開発者、SaaS管理者、CSIRTがそのまま確認できるチェック項目に落とし込みます。PoC、payload、悪用コード、探索クエリ、侵入再現は扱いません。

MCPとは何か、なぜ重要か

MCPは、LLMアプリケーションが外部データ、ツール、ワークフローへ接続するためのプロトコルです。公式仕様では、LLMアプリケーション側をHost、Host内の接続部品をClient、データやツールを提供する側をServerとして整理しています。

この構造で重要なのは、MCPサーバーが「情報を返すだけ」とは限らない点です。設定によっては、チケット作成、コード検索、リポジトリ操作、社内文書検索、クラウドAPI呼び出し、通知送信のような操作につながります。つまり、MCPのリスクはモデル名ではなく、接続先、認可、トークン、ツール実行範囲で決まります。

観点	確認すべきこと
接続先	SaaS、GitHub、クラウド、社内DB、ファイル共有、チケット、ログ基盤のどこへ接続するか
権限	読み取り、作成、更新、削除、外部送信、管理操作のどこまで許可するか
認証・認可	OAuth、APIキー、サービスアカウント、個人トークンのどれで動くか
データ	個人情報、顧客情報、秘密情報、コード、監査ログを扱うか
監査	誰が、どのプロンプトで、どのツールを、どの結果で実行したか追えるか

読者別の影響

読者	主な影響	最初に見ること
情シス・SaaS管理者	部門導入のAIツールがSaaS権限を持つ	連携アプリ、OAuth同意、scope、外部共有、管理者承認
開発者・SRE	MCPサーバーがリポジトリ、CI、クラウドAPIへ接続する	個人トークン、サービスアカウント、書き込み権限、CIシークレット
AI基盤・データ担当	RAGや社内検索が権限境界を越える	文書ごとの閲覧権限、ログ保管、データ分類、出典表示
CSIRT・SOC	不審なツール実行やトークン利用を調査する	ツール実行ログ、IdPログ、APIログ、キー発行・失効履歴
事業部門・DX担当	PoCの広い権限が本番相当で残る	所有者、利用目的、終了日、承認者、停止条件

特に注意が必要なのは、MCPサーバーが個人アカウントや個人トークンを使って動く構成です。退職、異動、委託終了、トークン漏えい、権限変更のときに停止しにくく、監査ログでも操作主体が曖昧になります。

まず確認すること

導入前レビューでは、MCPサーバーを「AI機能」ではなく「外部連携アプリ」として扱うと漏れが減ります。

MCPサーバーの名称、所有者、用途、運用責任者、停止判断者を決める。
接続先SaaS、API、リポジトリ、DB、ファイル共有、ログ基盤を一覧化する。
OAuthアプリ、APIキー、サービスアカウント、個人トークンのどれを使うか確認する。
OAuth scope、API権限、リポジトリ権限、クラウドIAM権限が用途に対して過剰でないか見る。
読み取り専用で足りる用途に、作成、更新、削除、外部送信、管理権限を付けない。
プロンプト、参照データ、ツール実行、承認者、結果、失敗、外部送信のログを残せるか確認する。
秘密情報、顧客情報、個人情報、ソースコード、監査ログをプロンプトや実行ログにそのまま保存しない設計にする。
異常時に、MCPサーバー、連携アプリ、トークン、ツール実行を止める手順を事前に決める。

実務では、AIプロキシ・LLM APIキー漏えい確認チェックリスト、SaaS権限棚卸しチェックリスト、GitHub secret leak対応チェックリストを組み合わせると、MCP固有の確認と既存の権限・シークレット管理をつなげやすくなります。

初動対応

やること

MCPサーバーごとに、接続先、認証方式、トークン保管場所、scope、所有者、利用者を一覧化する。
高権限・書き込み可能・外部送信可能なツールは、人間承認または別の承認ゲートを入れる。
個人トークンを使っている場合は、サービスアカウント、短命トークン、最小scopeへの移行計画を作る。
OAuth同意、APIキー発行、トークン利用、ツール実行、データ取得、外部送信のログを同じ時間軸で追えるようにする。
PoC、検証、部門導入のMCPサーバーには終了日と再レビュー日を設定する。
不審な動作が疑われる場合は、証跡保全後に連携アプリとトークンを失効し、必要なものだけ最小権限で再発行する。

やらないこと

便利だからという理由で、全リポジトリ、全ドライブ、全チャンネル、全クラウド権限をまとめて渡さない。
個人ブラウザセッションや個人アクセストークンを、チーム共有のMCPサーバーへ接続しない。
「プロンプトで禁止しているから安全」と判断しない。権限とツール実行はシステム側で制御する。
ログを残すために、プロンプト全文、APIキー、顧客情報、添付ファイルをそのまま長期保存しない。
攻撃再現や外部MCPサーバーの探索で安全性を確認しない。確認は公式情報、設定、権限、ログ、契約範囲に基づいて行う。

記録すべきこと

MCPサーバー名、所有者、用途、接続先、公開範囲、利用者。
認証方式、OAuth client、scope、APIキー、サービスアカウント、トークン有効期限。
許可したツール、読み取り・書き込み・削除・外部送信・管理操作の可否。
承認者、例外理由、終了日、再レビュー日、緊急停止手順。
不審利用の有無、確認したログ、失効したトークン、再発行したトークン、残リスク。

判断基準

次の条件に当てはまるMCPサーバーは、通常のPoCではなく、セキュリティレビューまたはCSIRT相談の対象にします。

優先度	条件	判断
高	顧客情報、個人情報、監査ログ、秘密情報、コードへアクセスする	データオーナーとセキュリティレビューを必須にする
高	書き込み、削除、外部送信、権限変更、CI/CD実行ができる	人間承認、最小権限、監査ログ、停止手順を必須にする
高	個人トークン、長期APIキー、広いOAuth scopeで動く	本番利用前にサービスアカウント化・短命化・scope縮小を行う
中	読み取り専用だが社内文書やリポジトリを横断検索する	文書単位の閲覧権限、ログのマスク、出典表示を確認する
中	PoC用MCPサーバーが継続利用されている	所有者、終了日、再レビュー日、権限削減を設定する
低	公開データのみ、ローカル検証のみ、権限なし	対象外根拠を残し、定期棚卸しに入れる

判断に迷う場合は、認証と認可の違いと最小権限の原則に戻って整理します。MCPはAIの話に見えますが、実務上は「誰に何を許可するか」という認可設計の問題です。

よくある誤解

「MCPはローカルで動くから安全」

ローカル実行でも、接続先がGitHub、クラウド、SaaS、社内DBであれば影響はローカルに閉じません。ローカルMCPサーバーが個人トークンを持つ場合、端末侵害、ログ露出、設定ファイル共有の影響も考える必要があります。

「読み取り専用なら問題ない」

読み取り専用でも、顧客情報、秘密情報、未公開コード、監査ログ、障害情報を横断検索できる場合は機密性に影響します。さらに、外部コンテンツを読むRAGやブラウザ操作では Indirect Prompt Injection のようなリスクも関係します。

「プロンプトで禁止しているので権限制御は不要」

プロンプトは方針を伝える手段であり、権限境界そのものではありません。OWASP LLM Top 10でも、Prompt Injection、Insecure Plugin Design、Excessive Agencyのようなリスクが整理されています。MCPの防御は、Prompt Injection対策だけでなく、scope最小化、承認ゲート、ログ、停止手順を組み合わせて考えます。

「導入したMCPサーバーは開発チームだけが管理すればよい」

MCPサーバーがSaaS、IdP、リポジトリ、クラウドAPI、業務データへ接続するなら、情シス、SaaS管理者、データオーナー、CSIRTも関係します。開発チームだけで権限とデータ利用を決めると、監査やインシデント対応で説明できない状態になりやすくなります。

MCPサーバーを社内AIに接続する前に確認すること ─ 権限・トークン・ログの実務チェック

冒頭要約

MCPとは何か、なぜ重要か

読者別の影響

まず確認すること

初動対応