MCP ゲートウェイと MCP セキュリティ：ゲートウェイが対応できる範囲
ゲートウェイは、受け取ったエージェントのリクエストについてアクセスを確認し、記録します。ゲートウェイで対応できる MCP セキュリティのリスクと、引き続きほかの対策が必要なリスクを解説します。
決定の概要
MCP 向けのゲートウェイは、AI クライアントと、クライアントが使うツールとの間の経路に置かれるチェックポイントです。受け取ったリクエストについて、誰からのリクエストかを確認し、アクセスルールを適用し、認証情報を分離し、未レビューのツールを保留し、重要な変更操作をレビューに回し、実際に起きたことを記録できます。MCP セキュリティはより広い取り組みで、プロンプトインジェクション、各サーバーのコード、ノートパソコン上のローカルサーバー、ゲートウェイを経由しないすべての経路も対象になります。多くのチームには、ゲートウェイとこうしたほかの対策の両方が必要です。
まず結論から
Model Context Protocol（MCP）は、Claude Code や Cursor などの AI クライアントを、ツールを提供するサーバーに接続します。ツールとは、チケットキューの検索、ファイルの読み取り、顧客レコードの更新といった機能です。ゲートウェイは、こうしたクライアントとサーバーの間に置かれます。クライアントは管理された 1 つのエンドポイントに接続し、ゲートウェイは各リクエストを確認してから転送します。
MCP セキュリティの対象はもっと広く、エージェントによるツール利用で起こりうるあらゆる問題が含まれます。たとえば、コンテンツに隠された指示にモデルが従ってしまう、ツールの実態が説明と異なるサーバーがある、使われるべきでない場所でトークンが使われる、エージェントがタスクに必要以上のアクセス権を持っている、誰も存在を知らなかった接続がある、といったケースです。
つまり、これは 2 つの製品の比較というより、対象範囲の違いの問題です。ゲートウェイは MCP セキュリティを構成する対策の一つであり、受け取ったリクエストに対しては強力な対策です。問題は、自社の構成でゲートウェイがどのリスクに対応し、残りのリスクを誰が担当するかです。
MCP セキュリティの各リスクにどこで対処するか
出発点となるリストは、2 つの情報源から得られます。MCP セキュリティのベスト プラクティスでは、トークンのパススルーや混乱した代理（confused deputy）問題など、このプロトコル特有の攻撃が説明されています。執筆時点でベータ版のプロジェクトである OWASP の MCP Top 10 は、主なリスクを 10 のカテゴリーに分類しています。
次の表は、この 10 のカテゴリーについて、ゲートウェイが果たせる役割と、ほかで補う必要があるものを対応づけたものです。特定の製品を説明したものではなく、自社でレビューを行うための出発点です。頼りにする項目については、それぞれデモを依頼して確認してください。
| リスク | ゲートウェイでできること | ほかに必要な対策 |
|---|---|---|
| トークンの不適切な管理とシークレットの漏洩 | 接続先の認証情報をデバイスやプロンプトに置かずに済む（ただし、その分ゲートウェイが価値の高い攻撃対象になる） | シークレットストアと、有効期間が短くスコープを絞ったトークン |
| スコープの肥大化による権限昇格 | チームごとにツール、リソース、操作を制限し、新たなアクセスをレビューする | 絞り込んだ OAuth スコープと定期的なアクセスレビュー |
| ツールポイズニング | レビューが済むまでツールをブロックし、定義が変わったら改めてレビューする | 承認前のサーバーの精査と、変更を知らせるクライアント |
| サプライチェーン攻撃と依存関係の改ざん | ほとんどない：サーバーのコードは検査できず、接続するサーバーを限定できるだけ | 来歴の確認、バージョンの固定、ソフトウェア部品表（SBOM） |
| コマンドインジェクションとコマンド実行 | 一部のみ：レビュー済みのスキーマから外れる引数を拒否できる | サーバー側での入力検証と安全なコマンド処理、さらにサンドボックス化 |
| エージェントが読み込むコンテンツを介したプロンプトインジェクション | 誤誘導されたエージェントがアクセスできる範囲を制限し、影響の大きい変更操作はレビューまで保留する | モデルやクライアントの防御策と、ユーザーへの確認表示 |
| 不十分な認証と認可 | 受け取るすべてのリクエストで ID とアクセス権を確認する | 各サーバーでも引き続き独自のアクセス制御を行う |
| 監査とテレメトリの不足 | ゲートウェイを経由するリクエストの判定と結果を記録する | それ以外はクライアント、サーバー、エンドポイントのログで補う |
| シャドーMCP サーバー | 受け取らないリクエストには何もできない | 検出、エンドポイントのインベントリ、ネットワーク制御、使いやすい正規のルート |
| コンテキストインジェクションと過剰な情報共有 | ツールが読み取れる範囲を制限し、設定に応じてレスポンスを検査する | データ分類と、モデル提供元のデータ利用規約 |
ゲートウェイが得意なこと
ゲートウェイの価値は、どのクライアントから送られたかにかかわらず、受け取ったすべてのリクエストが同じチェックを通る点にあります。誰からのリクエストか、その人が今もチームに所属しているか、その接続、ツール、リソースを使ってよいかを確認できます。こうした判断を、クライアントやサーバーごとにばらばらに繰り返すのではなく、一か所にまとめられます。
認証情報を分けて管理することもできます。利用者はゲートウェイにサインインし、ゲートウェイは接続先システム向けに発行された認証情報を使ってそのシステムを呼び出します。MCP の仕様では、クライアントのトークンをそのまま受け渡すことを禁止しています。そうすると接続先システムの制御を迂回することになり、誰が操作したのかが明確に記録されないためです。
ツールをレビューの対象として扱うこともできます。ツールの名前や説明は、モデルが読み取り、それに基づいて行動するテキストです。そのため、未レビューのツールを保留し、定義の変更を新たなレビューとして扱うゲートウェイは、プロトコルが残している隙間を埋められます。また、重要な変更操作をレビュー担当者に回し、判定と実行結果の両方を記録することもできます。
ゲートウェイ自体にもセキュリティ上の責任がある
ゲートウェイにはアクセスが集中するため、ほかの多くのシステムの認証情報を保持するシステムと同様に、厳しく精査する必要があります。MCP セキュリティのベスト プラクティスでは、クライアントをサードパーティの API に接続するサーバーをプロキシサーバーと呼び、特有の義務を定めています。
こうしたプロキシは、サードパーティの認可サーバーへ転送する前にクライアントごとに同意を求め、リダイレクト先のアドレスを完全一致で照合し、OAuth の state パラメーターを検証しなければなりません。これらの対策がないと、攻撃者はユーザーが以前に与えた同意を悪用し、ユーザーが一度も許可していないアクセス権を得られてしまいます。仕様ではこれを、混乱した代理（confused deputy）問題による攻撃と呼んでいます。
ゲートウェイは、利用者に代わってメタデータを取得したり、接続先のサーバーを呼び出したりもします。仕様では、サーバー上に配置されたクライアントに対し、HTTPS の必須化、プライベートアドレス範囲のブロック、リダイレクトの確認などによって、サーバーサイドリクエストフォージェリ（SSRF）を防ぐことを求めています。ゲートウェイがこうした処理をどのように扱うのか、また侵害された場合に保存している認証情報がどうなるのかを確認してください。
ゲートウェイの対象外となるもの
ゲートウェイに見えるのはリクエストであり、その背後にある推論ではありません。データをどこかに送るようモデルに指示する内容がドキュメントに含まれていて、そのリクエストが利用者に許可された範囲内であれば、ポリシーによるチェックだけでは、本人の意図なのか埋め込まれた指示なのかを見分けられません。Anthropic は、プロンプトインジェクションは解決にはほど遠い問題だとしています。権限を絞り、影響の大きい操作をレビューすれば被害は抑えられますが、それでコンテンツが信頼できるものになるわけではありません。
ローカルサーバーもゲートウェイの対象外です。ノートパソコン上で起動したサーバーはユーザーの権限で動作し、その通信がリモートのゲートウェイに届くことはありません。MCP プロジェクトのガイダンスでは、こうしたサーバーを、エンドポイント管理とソフトウェア管理が必要な一般的なソフトウェアとして扱っています。
ツールが読み取り専用であることを示すヒントなどのツールアノテーションも、制御を強制するものではありません。MCP のメンテナーは、安全性の保証は確定的に動作する制御で担保するよう推奨しています。さらに、同じ認証情報が別の経路で使われた場合はゲートウェイのルールは適用されず、クライアントがモデル提供元に送る内容もゲートウェイからは見えません。
例：隠れた指示を含むサポートチケット
例として、チケットを読み、顧客レコードを検索できるサポート用のエージェントを考えてみましょう。そこに、顧客リスト全体をエクスポートして返信に添付するようエージェントに指示する文章を含んだチケットが届きます。
モデルがこの指示に従うかどうかはわかりません。それはモデルとクライアントによって異なります。従おうとした場合、ゲートウェイは、この利用者がそのリソースに対してエクスポートツールを使ってよいかを確認します。そのツールがサポートチーム向けに一度も有効化されていなければ、リクエストは拒否されます。有効化されていて、チームがエクスポートにレビューを必須にしている場合は、何かが実行される前に、レビュー担当者がリクエストの正確な内容を確認します。
エクスポートが許可されていてレビューも不要であれば、ゲートウェイには拒否する理由がありません。与えられたルールのもとでは、そのリクエストは許可されているからです。だからこそ、チェックポイントそのものと同じくらい、ツールの設計やアクセス権の決め方が重要になります。
MCP セキュリティツールとの組み合わせ方
MCP セキュリティとして販売されている製品は、ゲートウェイとは異なる役割を担うことがよくあります。スキャナーは、承認前にサーバーのパッケージやツールの説明に隠れた指示がないかを検査します。ランタイム監視ツールは、エージェントの動作中にコンテンツや挙動を検査します。検出ツールは、デバイスに設定されている MCP サーバーを探します。
これらはゲートウェイの代わりではなく、ゲートウェイを補完するものです。スキャンはどのサーバーを承認するかの判断材料になり、検査はポリシーだけでは実現できないコンテンツの確認を加え、検出はどの経路がまだ管理を迂回しているかを示します。ゲートウェイを評価する際は、次の質問で、自社の構成においてゲートウェイが実際に何を適用するのかを確認できます。
- ゲートウェイが実際に受け取るのはどのリクエストで、どの経路がゲートウェイを迂回していますか？
- クライアントのサインインと接続先の認証情報は、どのように分離されていますか？
- ツール定義はどのようにレビューされ、定義が変更された場合はどうなりますか？
- 接続単位だけでなく、ツール、リソース、操作の種類ごとにアクセスを制限できますか？
- 提案された変更操作のレビューはどのように行われ、レビュー担当者には何が表示されますか？
- 記録では、アクセスの判定と操作の実行結果が区別されていますか？
Durinが適している場所
Durin は、エージェントのリクエストに一貫したルールと証跡を必要とするチームに向けて、ゲートウェイを通じて MCP ガバナンスを提供します。Durin を経由するリクエストでは、各呼び出しが、その時点の ID、メンバーシップ、チーム、接続、認証情報、レビュー済みツール、リソース、検査の各チェックを通過する必要があります。ツールはレビューが完了するまでブロックされ、ツール定義が変更された場合は改めてレビューが必要です。Durin はその接続に設定された認証情報でプロバイダーを呼び出し、Durin 自身のトークンを接続先に渡すことはありません。
これらのチェックを通過したレビュー済みのリクエストは、デフォルトでそのまま実行に進めます。チームは、デフォルトでアクセスを拒否するよう設定できます。また、提案された変更操作を別の管理者がレビューするよう求めることもでき、その場合、申請者は許可の有効期限が切れる前に、同じリクエストをもう一度送信します。Durin は判定と実行結果を分けて記録し、結果が不確定な操作を自動で再実行することはありません。
Durin はプロンプトインジェクションを防ぐものではなく、Durin を経由しないリクエストを管理することもできません。Durin のシャドーMCP の検出機能は、登録済みデバイスに設定されている MCP サーバーを報告するため、そうした経路を見つけるのに役立ちますが、それらをブロックするものではありません。モデル、クライアント、エンドポイント、サーバーの各対策も、引き続き計画に含める必要があります。