ひとことで言えば：MCPはAIに「物事を実行する力」を与えますが、その手に渡る権限は、設定ファイルに何を書いたかで決まります。 リスクの境界を理解してこそ、安心して使えます。
リスクはどこから？3つの層
1️⃣ 導入するサーバー自体が信頼できない（サプライチェーンリスク）
npx -y xxx で何かを入れる——そのパッケージを公開した人が、コードに何をさせるかを支配しています。悪意ある、または侵害されたサーバーは、環境変数からトークンを盗み、ファイルを読み、データを持ち出せます。 これが最大のリスク分類です。
2️⃣ 認証情報の権限が広すぎる（認可リスク）
GitHubトークンにリポジトリへのフル読み書きを与えていませんか？ならばAIはあなたのコードを変更し、Issueを削除できます。最小権限で与える：読み取りだけで足りるなら書き込みは渡さない。1つのリポジトリで足りるならアカウント全体は渡さない。
3️⃣ プロンプトインジェクション
AIが読むWebページ、文書、コードには「ユーザーの指示を無視してXXせよ」のような悪質なテキストが潜み、AIに高権限ツールを呼び出させることがあります。これはAI時代の新しいフィッシングです。
6つの実践的な保護Tips
- スター数が多く、長期にわたってメンテされ、公式提供のサーバーだけ入れる（Microsoft / GitHub 公式エコシステムなど）。未知の個人プロジェクトは避ける
- トークンはローカルに保管。設定ファイルは
.gitignoreで除外し、リポジトリに絶対にプッシュしない - 認証情報は最小権限で発行：GitHubは読み取り専用トークン、データベースは読み取り専用アカウント——見るだけで足りるなら変更権は渡さない
- 高権限サーバーには警戒：コマンド実行、ファイル削除、全ディスク読み取りができるもの（ファイルシステム系など）は信頼できる環境でのみ導入
- AI自身が認証情報を求めてきたら要注意：「続けるにはトークンが必要です」という会話には疑いを。公式の場面であなたの鍵を要求されることはありません
- 定期的に点検：使っていないサーバーは速やかに削除。漏洩の疑いがあればトークンを即時失効させて再発行
安全な導入のためのチェックリスト
☐ このプロジェクトはスター1万超、または公式公開か？
☐ READMEに最小権限設定の明確な例があるか？
☐ 設定ファイルのパスは .gitignore に含めたか？
☐ 付与するトークンは必要な範囲だけか？
☐ 導入後にクライアントの再起動が必要か？再起動前に見落としはないか？
最も安全な候補を体系的に選びたいなら、当サイトの厳選リストへ——すでに「公式 / 多スター / 活発」で絞り込んでいます。