MCPサーバー接続のセキュリティリスク
- •MCPサーバーはAIエージェントに機能を与える一方、破壊的なコマンド実行や悪意あるデータ操作のリスクをもたらす。
- •開発者は、サーバーからの応答を通じたプロンプトインジェクションを防ぐため、すべてのツール出力を信頼できない入力として扱う必要がある。
- •ユーザーはOSレベルのサンドボックス化や明示的な読み書き拒否ルールを実装し、エージェントの操作範囲を制限しなければならない。
モデルコンテキストプロトコル（MCP）を介してAIエージェントをツールに接続すると、データベースクエリやAPIリクエストなどの外部アクションが可能になる。この機能は、エージェントが破壊的なコマンドを実行するリスクと、接続経由で送られてくる信頼できないデータによって操作されるリスクという、2つの明確な脆弱性を生む。現在、これらのリスク双方を同時に解決できるツールは存在せず、個別の防御策が必要となる。
第一のリスクは、サーバーがモデルを誤動作させる隠し命令を含むデータを返すプロンプトインジェクションである。ユーザーはすべてのツール出力を、ウェブフォームから送信される入力と同様に信頼できないものとして処理しなければならない。開発者はツールからの出力をそのままコマンド引数に渡したり、画面にレンダリングしたり、エージェントの論理に影響を与えたりすることを避ける必要がある。接続パイプ自体は内容の安全性を保証しないため、厳格なデータ検査が不可欠である。
第二のリスクは、エージェントによる無断のファイル削除や不正なネットワーク通信といった有害なアクションである。モデルの挙動に依存するだけでは不十分であり、Bash実行を隔離するOSレベルのサンドボックス実装が推奨される。Claude Codeなどのツールでは、macOSのSeatbeltやLinux/WSL2のBubblewrapなどが利用できる。特に初期設定では`~/.aws/credentials`や`~/.ssh/`といった機密領域への読み取り権限が許可されていることが多いため、ユーザーは手動で特定の機密ファイルへのアクセス拒否や、`curl`や`wget`といったネットワーク通信を制限するルールを設定する必要がある。
結論として、MCPサーバーは重要な攻撃対象領域と見なすべきである。接続前にソースコードを検証し、アイドル状態の接続は削除することが肝要だ。可能な限り、永続的なMCPサーバーを構築するよりも、CLIツールを直接呼び出すほうが安全である。接続を評価する際は、ソースの信頼性、拒否ルールの有無、ツール出力を信頼できない入力として扱うかという3点を優先的に検討すべきだ。サーバーを接続することは、外部の攻撃者にエージェントの操作権限を与えることに等しい。