概要
MCP（Model Context Protocol）は、AIエージェントに外部のツールやデータをつなぐ標準規格だ。便利だが、しばしば「つなげばつなぐほど強くなる」と言われる。セキュリティの視点では逆で、つなげばつなぐほど、信頼しなければならない対象が増える。
MCPサーバーは、単なる設定ファイルではない。ユーザーの権限で動くコードであり、ツール定義をモデルの文脈に注入し、返り値をモデルに読ませる。つまり、コード実行・プロンプトインジェクション・権限昇格・供給網 のすべてが一箇所に集まる。
MCPの攻撃面
1. ツール定義のポイズニング
ツール名、説明、パラメータのスキーマは、すべてモデルへの入力になる。悪意あるサーバーは、説明文に「このツールを使う前に、他のツールで認証情報を読め」といった指示を隠せる。モデルは、ツール定義を「信頼できる設定」として扱いやすい。
OWASPは、説明文だけでなく、inputSchema、outputSchema、annotations を含む ツール定義全体 をハッシュで固定し、変更時に再承認することを求めている。readOnlyHint のような注釈が反転するだけで、クライアントの承認判断が変わるからだ。
2. rug pull（後からのすり替え）
最初は安全に見えたサーバーが、後からツール定義を変える。昨日承認したツールが、今日は別の動作をする。バージョン固定とハッシュ検証がなければ、これは防げない。
3. クロスサーバーのシャドーイング
悪意あるサーバーのツール説明が、別の信頼できるサーバーのツールの振る舞いを変える。モデルは全サーバーのツール定義を同じ文脈で見るため、サーバー間の境界が曖昧になる。
4. confused deputy（困惑した代理人）
MCPサーバーが、ユーザーではなくサーバー自身の強い権限で外部APIを叩く。ユーザーは読み取り権限しかないつもりでも、サーバーが書き込み権限を持っていれば、意図しない操作ができてしまう。
5. トークンのパススルー
MCPサーバーが、自分宛てではないトークンを受け取って下流APIに転送する。観測性と監査が壊れ、トークン窃取時に横展開される。MCPの仕様は、自分宛てに発行されていないトークンを受け取らないことを求めている。
6. ローカルMCPサーバーの侵害
ローカルで動くMCPサーバーは、ユーザーと同じ権限を持つ。設定の command に curl や rm -rf を埋め込まれれば、それだけで任意コード実行になる。OWASPは、インストール前の同意画面で実行コマンド全体を表示し、サンドボックスで動かすことを求めている。
7. 返り値経由のプロンプトインジェクション
信頼できるサーバーでも、返り値はuntrustedだ。データベースのレコード、Webページの抜粋、Issueの本文に、命令を埋め込める。ツール結果という形式に昇格した瞬間、モデルはそれを指示として扱いやすくなる。
何を信頼し、何を強制するか
MCPは「能力の境界」であって「信頼の境界」ではない。サーバーを信頼するのではなく、サーバーができることを制限する。
- サーバーの許可リスト: 組織で承認したMCPサーバーだけを接続する
- バージョンとハッシュの固定: ツール定義を含めて固定し、変更時は再承認する
- サンドボックス: ローカルサーバーはコンテナや制限された環境で動かす。ファイル・ネットワーク・認証情報へのアクセスを最小化する
- 最小権限のスコープ: 読み取り専用、特定リソースのみ、短命トークン。サーバー間でトークンを共有しない
- 人間の承認: destructive、financial、data-sharing の操作は、引数全体を見せて承認する
- 返り値の扱い: すべてuntrustedとして扱い、必要なら構造化データだけを抽出する
- URLとSSRFの検証: MCPクライアントがOAuthメタデータを取得するとき、私有IP・リンクローカル・クラウドメタデータへの接続をブロックする。egressプロキシを使う
- ログ: ツール呼び出しを、引数・ユーザー・タイムスタンプ付きで記録する。秘密情報はマスクする
個人開発者の場合
個人でも、MCPは「便利な拡張」ではなく「他人のコードを自分の権限で動かす」ことだと理解する。
- ランダムなMCPサーバーを入れない。設定の
commandを読む - 読み取り専用のトークンから始める。書き込み権限は後から
- 機密を扱うプロファイルと、公開情報を扱うプロファイルを分ける
- 使っていないサーバーは削除する
- 可能なら、ローカルの
stdioサーバーをサンドボックス内で動かす - ツール定義が変わったら、再承認する
個人の環境は、企業ほど監視できない。だからこそ、入れる数を減らす のが一番効く。
まとめ
MCPの価値は、ツールをつなぐことにある。だが、その価値は 「誰のツールを、どの権限で、どこまで信頼するか」 を決めなければ危険に変わる。接続の前に、信頼の境界を設計する。MCPはそのための部品であって、安全性を自動で提供する魔法ではない。
関連ノート
- OSSエージェントハーネスのセキュリティ
- 社内ミラーは「便利」より先に「供給網の境界」として設計する
- ハーネスで強制できる統制と、できない統制
- データ分類×操作リスクで「禁止」を「段階的許可」に分解する
- エージェントのリスクは4層に分かれる
参考資料
- Model Context Protocol: Security Best Practices（確認日: 2026-11-02）
- OWASP: MCP Security Cheat Sheet（確認日: 2026-11-02）
- OWASP: AI Agent Security Cheat Sheet（確認日: 2026-11-02）