MCPセキュリティとは何ですか？
MCPセキュリティとは、Model Context Protocolサーバーがシステムへの最も容易な侵入経路になるのを防ぐためのものです。このプロトコルは、エージェントがツールを検出して呼び出す方法を標準化しますが、誰がツールを呼び出せるか、ツールがどこにアクセスできるか、あるいはツールの説明が有害なものに変化した場合に何が起こるかまでは決定しません。これらの決定は、認証、オリジンおよびトランスポートの検証、厳密にスコープ定義されたツール、レート制限、監査トレールなど、サーバー側で行われます。
定義
MCPセキュリティとは、AIエージェントに機能を公開してもその背後にあるシステムが公開されないように、Model Context Protocolサーバーとそのクライアントに適用される一連のコントロール（認証と認可、オリジンとトランスポートの検証、ツールのスコープ定義、入力と出力の処理、レート制限、監査など）のことです。
主な要点
- MCPは配管（仕組み）を標準化するのであって、信頼を標準化するわけではありません。各サーバーが独自のセキュリティ姿勢を決定します。
- ツールの説明はモデルに対する信頼できない入力です。指示を含むことがあり、承認後に変更される可能性もあります。
- ローカルのstdioサーバーとリモートのHTTPサーバーでは脅威モデルが異なり、発生しうる危険なミスも異なります。
- クライアントは管理下にはないため、オリジンチェックとレート制限はサーバー側で行う必要があります。
- 「読み取り専用」は実装の属性であり、ツールの名前によって保証されるものではありません。
コンテキスト
MCPは、エージェントに機能を検出して呼び出すための統一された方法を提供します。その統一性は価値であると同時にリスクでもあります。1つのクライアントを多くのサーバーに向けることができ、各サーバーは、実際には設定ファイルにURLを貼り付けた人物によって、その都度新たな信頼の決定が下されることになります。
主に2つのデプロイ形態があります。ローカルのstdioサーバーは、ユーザー自身のマシン上でそのユーザーの権限で実行されます。ネットワーク境界がないため、問題となるのはそれが何を読み取れるか、そして外部に通信（phone home）するかどうかです。リモートのHTTPサーバーはパブリックなエンドポイントです。問題となるのは、誰が、どこから、どのくらいの頻度で呼び出しているか、そしてブラウザが騙されてユーザーの代わりにそれを呼び出すように仕向けられていないか、ということです。
このナレッジベースでは、パブリックHTTPエンドポイントと公開されたstdioパッケージという、これら両方の形態を1つずつ運用しています。そのため、以下のコントロールは一般的なチェックリストとしてではなく、実際に実装されている通りに説明されています。
アーキテクチャ
まず公開範囲を決定します。パブリックな読み取り専用機能、認証が必要な機能、またはローカル専用機能のいずれかです。その他すべての設計はその決定に従うものであり、ほとんどのインシデントは、その決定がなされなかったサーバーから発生しています。
処理を実行する前にトランスポートを検証します。HTTPサーバーの場合、ハンドラーが実行される前にOriginヘッダーを許可リストと照合し、ブラウザ起点のクロスサイト呼び出しを拒否します。DNSリバインディングやCSRF型の不正利用は、いずれもこの経路から発生するためです。
プロトコルが許す限り、サーバーをステートレスに保ちます。セッションストアを持たないことは、セッション固定化攻撃、リクエスト間の汚染、および呼び出し元間での状態の漏洩が発生しないことを意味します。
ツールのスコープを狭く限定します。1つのツールに1つの機能を持たせ、引数によって動作が変わる動詞は避けます。書き込みも実行できる「query」ツールは、適切なパラメータが渡されるのを待っている権限昇格の脆弱性に他なりません。
呼び出し元ごとにレート制限を適用し、実際の429ステータスコードとRetry-Afterヘッダーで応答します。制限に従って再試行するエージェントは通常のトラフィックですが、制限なしに再試行を繰り返すエージェントは、自社のバックエンドに向けられたサービス拒否（DoS）ツールと化します。
不正利用を再構成できる十分な情報（ツール、結果、レイテンシ、呼び出し元の識別情報）を含めてすべての呼び出しをログに記録し、ログ自体が情報漏洩の要因にならないようにします。
返されるすべてのツールの実行結果を、信頼できないコンテンツとして扱います。外部データをプロキシするサーバーは、その構造上、間接的なプロンプトインジェクションの経路となります。
コンポーネント
メリット
- 適切にスコープが定義されたMCPサーバーは、それが置き換えるアドホックな統合よりも攻撃対象領域が小さくなります。1つのプロトコル、1つの監査ポイント、1つの取り消し場所で済みます。
- ステートレス性と限定されたツールにより、サーバーの動作把握が容易になります。セキュリティレビューは1ページに収まる規模になります。
- 標準的なエラーとレート制限ヘッダーにより、クライアントの動作が予測可能になります。これはそれ自体が防御的な特性です。
- すべてが単一の境界を通過するため、測定が容易になります。不正利用と通常の利用が同じログに記録され、明確に区別できます。
リスク
- ツールのラグプル（梯子外し）：承認時には正常に動作し、クライアントが確認を求めてこなくなった後で、ツールの説明を後から変更するサーバー。
- スコープが広すぎるローカルサーバー：ユーザーのファイルシステムや認証情報を保持するstdioサーバーは、それを捕捉するネットワーク境界がないため、エージェントの全権限を持つことになります。
- 混乱した代理（Confused Deputy）：サーバーが呼び出し元の持たない認証情報を保持しているため、サーバーにアクセスできるすべてのユーザーがその権限を引き継いでしまいます。
- 暗黙的なパブリック公開：認証、Originチェック、レート制限なしでデプロイされたリモートサーバーは、容易に発見され、自由に不正利用されてしまいます。
- インジェクションの中継：サードパーティのソースから取得したツールの出力を、信頼できる指示であるかのようにモデルに渡してしまうこと。
ツールとテクノロジー
例
- このナレッジベースは、パブリックな読み取り専用のHTTP MCPエンドポイントを公開しています。設計上ステートレスであるため、セッションの固定化やリプレイは発生しません。ツールは公開されたコンテンツのみを返し、すべての呼び出しはハッシュ化された呼び出し元ごとに、実際の429ステータスコードとRetry-Afterヘッダーを用いてレート制限されます。
- そのエンドポイントのOriginルールを作成する前に、まず実際のトラフィックを測定しました。ほぼすべてのリクエストにOriginヘッダーが全く含まれておらず、nullを含むものはなく、ヘッダーが含まれていたリクエストはすべてこのサイトからのものでした。適用されたルールはこの測定結果に従っており、Webアプリケーションのデフォルト設定をコピーするのではなく、他の場所からのブラウザ起点の呼び出しを拒否し、実際のターゲットであるヘッダーなしのエージェントトラフィックを許可しています。
- 同じナレッジベース向けに公開されているstdioパッケージは、パブリックエンドポイントへのアウトバウンド呼び出しのみを必要とするため、認証情報やファイルシステムへのアクセス権なしでローカルに実行されます。何も必要としないローカルサーバーには、何も与えるべきではありません。
FAQ
- MCPはエージェントの安全性を高めますか、それとも低下させますか？
- 個々の統合においては安全性が高まりますが、全体としてはリスクが高まります。1つのプロトコルに統合されることで、レビューや取り消しを行う場所が1つにまとまります。しかし、エージェントを別のシステムに接続するコストも下がるため、接続するたびに新たな信頼の決定を迫られることになります。
- 読み取り専用サーバーに認証は必要ですか？
- データが完全に公開されているのであれば、必ずしも必要ではありません。ただし、レート制限と監査証跡は依然として必要です。公開されているからといって無料（無制限）で利用できるわけではなく、制限のないパブリックエンドポイントは、自社のインフラに向けられた増幅器となってしまいます。
- エージェントがOriginヘッダーを送信しないのであれば、なぜそれをチェックするのですか？
- まさに送信しないからです。ヘッダーのないトラフィックこそが正当な対象であり、外部のOriginを持つリクエストは、第三者に代わって動作しているブラウザによるものであるため、まさに拒否すべきケースに該当します。
- ツールのラグプル（梯子外し）とは何ですか？また、どのように防御すればよいですか？
- ユーザーが承認した時点では無害なツールの説明を提示し、その後で説明を変更するサーバーのことです。防御策としては、サーバーのバージョンを固定すること、説明が変更されたときに再検証すること、そしてコードの依存関係に付与しないような権限をリモートサーバーに付与しないことが挙げられます。