MCP（Model Context Protocol）は「セキュアな双方向接続」を明確に目指して設計されています。Anthropicの発表でも「secure, two-way connections」と繰り返し強調されています。
MCP公式仕様が定める主な安全対策（1次情報源：公式仕様書・セキュリティベストプラクティス）
- 明示的なユーザー同意が必須：データ公開、ツール実行、LLMへのプロンプト送信の前に、ユーザーが「何を共有するか」「何を実行するか」を必ず承認。同意なしにデータは送信されません。
- スコープ（権限）の最小化：必要最小限の権限（例：files:readのみ）だけを付与。広範な権限（files:*など）は避ける。
- トークン検証の徹底：MCPサーバーは自分向けに発行されたトークン以外を受け付けず、「トークンパススルー（そのまま下流APIに渡す）」を禁止。
- プロンプトの可視性制限：サーバー側がAIのプロンプト全体を見られないよう制限。
- ツールの扱い：ツールは任意コード実行の可能性があるため、説明文を「信頼しない」と明記。
さらに公式の「Security Best Practices」ドキュメントでは、以下の具体的な漏えいリスクと対策を挙げています。
3. 実際の運用で注意すべき点（公式ドキュメントに基づく）MCP自体は「規格」であって、自動的に安全になるものではありません。
|
リスクの種類
|
どんな漏えいが起きるか
|
公式推奨対策
|
|---|---|---|
|
Confused Deputy Problem
|
悪意あるリンクで同意を騙し、個人情報や企業データに不正アクセス
|
クライアントごとの同意UI + CSRF対策 + 厳格なリダイレクト検証
|
|
SSRF（サーバーサイドリクエストフォージェリ）
|
内部ネットワークやクラウド認証情報（AWSメタデータなど）が外部に漏えい
|
HTTPS強制 + プライベートIPブロック + エグレスプロキシ使用
|
|
Token Passthrough
|
認証トークンがそのまま渡り、データ漏えいや権限昇格
|
トークンパススルー完全禁止
|
|
ローカルMCPサーバー侵害
|
悪意あるMCPサーバーがローカルで起動され、個人ファイル（.sshキーなど）が盗まれる
|
起動時の明示的同意 + サンドボックス実行 + 危険コマンド警告
|
|
セッションハイジャック
|
セッションIDが盗まれ、データ操作や漏えい
|
セッションを認証に使わず、ユーザーIDと紐づけ
|
- 実装次第でリスクが発生：公式セキュリティドキュメントでも「堅牢な同意・認可フロー」「適切なアクセス制御」を実装しないと、データ漏えいの危険性があると明記されています。
- 企業利用の場合：Claude for WorkなどではローカルMCPサーバーで内部データをテストし、段階的に本番展開することを推奨。外部公開サーバーは特に慎重に。
- 個人利用の場合：信頼できるMCPサーバー（公式リポジトリや信頼できる開発者のもの）だけを使い、起動時は必ずコマンド内容を確認。
- MCPは情報漏えいを防ぐための仕組みを最初から組み込んでいるオープン規格です（ユーザー同意、最小権限、トークン検証など）。
- しかし、MCPサーバーの実装が甘いと、従来のAPI連携と同じく（あるいはそれ以上に）個人情報・企業情報の漏えいリスクが生じます。特にツール呼び出しやファイルアクセス機能は強力なだけに、注意が必要です。
- 公式が公開しているセキュリティベストプラクティスと仕様書をしっかり読んで実装・運用すれば、安全に「AIをデータに繋ぐ」ことができます。
