MCP ゲートウェイ セキュリティ: すべてのツール呼び出しがゲートを通過することを証明する

MCP ゲートウェイのセキュリティは、アーキテクチャ図にプロキシを配置することによって確立されるものではありません。防御可能なデフォルトはより厳密です。 保護された各運用ツール呼び出しが意図したゲートウェイを通過し、予期されたポリシー リビジョンを使用し、検証された ID と最小特権スコープを伝達し、監査レシートを生成し、検証済みの効果または明示的な待機状態で終了したことを証明します 。 「ゲートウェイ」は結果ではなく配置を表すため、この区別は重要です。現在の米国の検索結果には、ゲートウェイ製品、比較、アーキテクチャの説明、セキュリティに関する主張が混在しています。これらの共通の約束は、エージェントと MCP サーバー間の中央制御ポイントです。運用上の問題は、そのポイントが実際に特定のコールを所有しているかどうかです。 のMCP 認可仕様HTTP トランスポートの認可、保護されたリソースのメタデータ、検出、およびスコープの選択を定義します。プロトコルのセキュリティのベストプラクティス実装者は、混乱した代理のリスク、トークンの対象者の検証、トークンのパススルーの危険性、同意、および監査可能性を考慮する必要があります。どちらの文書も、単なる仲介者の存在をすべてのルートが管理されていることを証明するものではありません。 トラフィックをルーティングする前に証拠コントラクトを定義する ゲートウェイ構成の横に配布できるほど小さいルート マニフェストから始めます。 マニフェストは 5 つのテスト可能なアサーションを作成します。 1. リクエストは直接サーバー URL ではなく、指定されたゲートウェイを経由して渡されます。 2. ゲートウェイは、機密でないワークロードまたはユーザー ID を検証しました。 3. この決定は、予期された新たな政策修正によるものでした。 4. 許可されたスコープは、サイレントにアクセスを拡大することなく、選択したツールをカバーしました。 5. ゲートウェイは、ダウンストリームの結果に結合できる監査レシートを発行しました。 ルート アサーションは理論的なものではありません。クラウドフレアの現在MCP サーバーポータルのドキュメントでは、ツール呼び出し用のオプションのゲートウェイ パスについて説明しますが、バックグラウンド同期は上流サーバーに直接接続します。また、サーバーで認証が強制されない限り、ブロックされたユーザーでもアップストリーム サーバーの直接 URL を使用できることも警告します。これらは正当な製品固有の動作であり、普遍的な MCP ルールではありませんが、ポータルやゲートウェイがサイド ドアを排除していると想定するのではなく、インベントリに すべて のパスを含める必要がある理由を示しています。 決定ごとに中身の入っていない封筒を 1 つ記録します。プロンプト、ツール引数、結果本体、アクセス トークン、シークレットは必要ありません。 不透明な識別子は、ルートの所有権、ID の適用、ポリシーの鮮度、適用範囲、承認状態、および受信の継続性をテストするには十分です。秘密の値をソースに保管します。インシデントでコンテンツ検査が必要な場合は、それを独自の保持境界を持つ明示的に承認された別個のワークフローとして扱います。 認可とポリシーの適用は関連していますが、互換性はありません。 MCP 仕様では、承認は実装のオプションであると規定されています。 HTTP 認証がサポートされている場合、保護されたサーバーは OAuth リソース サーバーとして機能します。したがって、ゲートウェイはベアラー トークンが存在したことを示すことによって証拠を作成することはできません。対象となるリソースとアイデンティティを検証し、関連するツールのポリシーを評価し、決定を説明するのに十分な非秘密の証拠を保存する必要があります。 MCP セキュリティ ガイダンスでは、トークン パススルーは制御を回避し、説明責任を損なう可能性があるため、アンチパターンとして明示的に特定しています。 隠蔽を「許可」した 8 つの状態を再生します 付属のフィクスチャには 8 つの合成リクエストが含まれています。その分類子は、ゲートを動作順序で適用します。 ローカルで実行します。 それぞれの評決には、異なる制限付きの応答が必要です。 評決 証拠が語ること 次のアクション GATEWAY BYPASS 保護されたコールは別のルートまたはゲートウェイ ID を使用しました クライアントと上流のエンドポイントのインベントリを作成します。直接パスを閉じるか個別に管理する IDENTITY NOT ENFORCED ルートは中央でしたが、発信者は検証されませんでした 匿名の実動呼び出しを拒否し、ワークロードまたはユーザー ID を境界で修正します POLICY DRIFT 決定には古い改訂版または古い証拠が使用されました 再試行する前に、実行中のゲートウェイと承認されたポリシー アーティファクトを調整します。 AUTHORIZATION GAP ツールまたはその必要な範囲が決定と一致しませんでした 呼び出しを拒否し、範囲を縮小し、ツールレベルの回帰ケースを追加します。 AUDIT GAP 通話は許可された可能性がありますが、参加可能な受信が存在しません ロギング/エクスポート パスを修復します。評決は緑ではなく不明のままにしておく EFFECT UNCERTAIN 輸送またはツールの完成は目的地を証明しませんでした 再試行する前に、特にタイムアウト後に宛先を読み取る WAITING 保護されたアクションには名前付き承認依存関係があります 所有者に通知し、期限を守ります。エージェントにスタックのラベルを付けないでください HEALTHY ルート、アイデンティティ、ポリシー、範囲、監査、承認、および効果が一致する インシデントレビューウィンドウを通じて領収書を保管してください この優先順位により、都合の良い承認待ちによってバイパスまたは古いポリシーが隠蔽されるのを防ぎます。 WAITING は、ルート、アイデンティティ、ポリシー、認可、および監査ゲートを通過した後にのみ使用できます。同様に、ダウンストリーム効果が成功しても、制御パスをバイパスした呼び出しが許されるわけではありません。 この実験は意図的に内容を含まないものになっています。ライブゲートウェイ製品ではなく、正規化されたコントラクトをチェックします。 MCP が標準化したかのようにフィールド名をコピーするのではなく、ゲートウェイのフィールドをフィクスチャにマップします。プロトコルはメッセージと認証動作を定義します。ゲートウェイ ポリシー リビジョン識別子、監査レシートの形状、および宛先検証機能は実装上の選択肢として残ります。 結果として生じる効果から許可を分離する 許可の決定は、ポリシーが試行を許可したことのみを証明します。これは、ツールが一度実行されたこと、意図された宛先を変更したこと、または要求された成果物を作成したことを証明するものではありません。 突然変異の場合は、ゲートウェイの受信を宛先の受信に結合します。 これはタイムアウト後は特に重要です。ゲートウェイが応答を受信しなかったために再試行すると、上流システムがすでにコミットした効果が重複する可能性があります。 EFFECT UNCERTAIN 最初に目的地を調整するようにオペレーターに指示します。ゲートウェイはレート制限や再試行の許可を行うことができますが、通常は宛先が元の効果が存在するかどうかのより強力な情報源となります。 読み取り専用ツールの場合、結果は、スキーマ チェック、鮮度アサーション、またはタスクの必須フィールドとの決定的比較となる場合があります。書き込みの場合は、API リードバック、不変オブジェクト バージョン、プロバイダー メッセージ ID、コミット ハッシュとチェック、または別の宛先所有のレシートを優先します。約束された結果が他の場所にある場合、ツールの JSON RPC 成功結果は弱くなります。 実際の展開は狭いままになる可能性があります。 1. 本番 MCP サーバーと影響力の高いツールを 1 つ選択します。 2. すべてのクライアント エンドポイントと、それに到達できる直接のアップストリーム URL を列挙します。 3. 導入証拠にゲートウェイ ID とポリシー リビジョンを固定します。 4. 不透明な要求 ID を使用して、許可されたプローブと拒否されたプローブを 1 つずつ送信します。 5. 呼び出し元の ID、必要なスコープ、ツールの決定、最新性、および両方の監査受信を確認します。 6. 文書化された直接ルートを試して、それがブロックされているか、明示的に管理されていることを証明してください。 7. 承認が必要な呼び出しを実行し、それをそのまま保持します WAITING 指名所有者が決定するまで。 8. アップストリーム効果後のタイムアウトをシミュレートし、再試行する前に Runbook が宛先を読み取ることを証明します。 9. ゲートウェイ、アイデンティティ プロバイダー、ポリシー、クライアント、または MCP サーバーを変更した後、プローブを繰り返します。 限界があります。このフィクスチャは、特定のベンダーのパーサー、DLP エンジン、プロンプト インジェクション防御、または脆弱性スキャナーをテストしません。中央ゲートウェイがすべてのローカル STDIO サーバーにとって適切なアーキテクチャであることは証明されません。ローカル プロセスには、ネットワーク ゲートウェイの代わりにホスト レベルの制御が必要な場合があります。また、Sidewisp が必須のモデルまたはツール ゲートウェイになるわけでもありません。 Sidewisp の意図する役割は隣接しています。つまり、到達可能性、進捗状況、ツール、結果、時間、予算の証拠をエージェントの健康状態のビューに取り入れ、回復に関する人間の権限を維持します。 Sidewisp は現在プライベートプレビュー段階です。 ライブ エクスペリエンスは、早期アクセス Web サイトとインタラクティブなデモンストレーションです。実稼働 MCP ゲートウェイ アダプター、ライブ モニタリング エンジン、および自動リカバリ エグゼキューターは出荷されません。 Sidewisp が現在それらを監視または修正していると想定するのではなく、現在のゲートウェイおよび宛先システムで強制レシートを使用してください。 解決策は具体的です。ルートのインベントリを作成し、ゲートとポリシーを固定し、ID と最小特権スコープを検証し、参加可能な監査レシートを要求し、正当な待機を維持し、成功を宣言する前に宛先を確認します。 MCP ゲートウェイのセキュリティは、制御パスと効果が一致する場合にのみ運用上の証拠となります。