メインコンテンツへスキップ
Model Context Protocol（MCP）を話す エージェントは、接続するサーバーと同程度にしか安全ではありません。各 MCP サーバーは、 新たなツールのセット、新たなクレデンシャル、新たなネットワーク到達範囲です — そして エージェントが直接ダイヤルした瞬間、誰もその呼び出しを見ていません。それが mcp セキュリティが解決しなければならない問題のすべてです：「この 1 つのツールは 安全か」ではなく「すべての呼び出しで、すべてのツールを、ひとつの監査トレイルで 誰が統制するのか」です。 OrcaRouter の答えは、単一の監査済みチョークポイントです。各 MCP サーバーを一度登録 し、エージェントはひとつのゲートウェイに接続します。そしてすべての tools/call は、実際のサーバーに到達する前にファイアウォールエンジンを 通ります。このページはそのサーフェスの地図です — ゲートウェイ、呼び出しごとの判定、 スキル統制、egress、暗号化されたクレデンシャル — それぞれに焦点を当てた手順への リンク付きです。
ここでのすべての管理アクションはコンソール（またはセッション／アクセストークンを 使った REST API）から設定され、ロールゲートされています。sk-orca-... 形式のキーを 持つのは /v1/* リレー呼び出しとファイアウォールゲートウェイルートだけです。

​
1. なぜ mcp セキュリティにゲートウェイが必要か

10 個のエージェントを 5 つのコミュニティ MCP サーバーに直接向けると、あらゆる世界の 最悪を手に入れます：共有ポリシーなし、監査トレイルなし、10 個のエージェント設定に コピーされたクレデンシャル、そして shell.exec という名前のツールがクラウド メタデータエンドポイントへリダイレクト 1 回の距離にある状態です。ゲートウェイは それをひとつの統制された接続に集約します。

ひとつの接続、すべてのサーバー

エージェントは単一のエンドポイントに接続します。ゲートウェイは、有効で到達可能な すべてのサーバーのツールを <server>.<tool> 名前空間の下で集約します。

すべての呼び出しにポリシー

各 tools/call は、ディスパッチ前にあなたのファイアウォールポリシーによって 評価されます。

暗号化されたクレデンシャル

サーバーの認証シークレットは保存時に暗号化され、読み取り時にマスクされ、 ディスパッチ時に注入されます — モデルやクライアントに到達することは決して ありません。

統制下の egress

登録されたサーバーのエンドポイントは、デフォルトでプライベートおよびクラウド メタデータの IP 範囲に対して検証されます。ツールごとの宛先については、ベースライン SSRF egress 拒否リストを適用するか、独自のホスト／CIDR ルールを作成します。
これらすべての基盤については、 AI エージェントのセキュリティと ゼロトラストの理由を参照してください。

​
2. 4 つの構成要素

OrcaRouter での MCP 統制は、協調する 4 つのピースです。答えようとしている問いに 合うものを選んでください。
サーバーを直接ダイヤルする代わりに、エージェントが接続する単一のエンドポイント です。登録されたすべてのサーバーのツールを <server>.<tool> で名前空間化して 集約し、各ツールの入力スキーマを逐語的に再公開します。 MCP サーバーの接続と 認証から始めてください。完全な リファレンスはファイアウォール：MCP サーバーに あります。
ゲートウェイは各 tools/call を mcp サーフェス上でファイアウォールに通し、 ディスパッチの前に判定 — allow、audit、deny、sanitize、または pending_approval — を返します。 MCP ツールの許可リスト化と ツール引数のサニタイズを参照してください。
エージェントが自己インストールするケイパビリティ — スキル、BYO MCP サーバー、 プラグイン — はスキャンされ、リスクバンドを割り当てられ、すべてのルール判定の 上に乗る強制モード（allow / quarantine / block）を与えられます。 ファイアウォール：スキルと ラグプル防御を参照してください。
各サーバーの認証シークレットは保存時に暗号化され、読み取り時にマスクされます。 認証と クレデンシャルローテーションを参照して ください。

​
3. tools/call はどう評価されるか

エージェントがゲートウェイ経由でツールを呼び出すとき、その呼び出しはサーバーへ 直行しません。あなたのワークスペースポリシーに対して照合され、所有元スキルの 強制モードがその上に適用され、allow / audit / sanitize の判定だけが実際の サーバーに到達します。
判定エージェントが見るもの
allow / audit転送。audit はイベントもログに記録します。
sanitize引数をリダクトして転送（結果は決して変更しません）。
deny / pending_approvalツールエラーとして返されるため、エージェントはクラッシュする代わりに適応できます。
ブロックされた MCP 呼び出しはツールエラー（firewall deny: …）として戻ってきます。 任意の失敗するツールが返すのと同じ形状です — エージェントは別の方法で再試行する、 ユーザーに尋ねる、あるいは停止できます。トランスポートクラッシュではありません。
判定の語彙、サーフェス、ルールのマッチングは ファイアウォールと ファイアウォールルールに完全に文書化されています。 概念モデルは強制モードと OrcaRouter の検査方法にあります。

​
4. サーバーの登録（具体例 1 つ）

各サーバーは一度登録します。サーバーレコードは name（ワークスペースごとに一意、 . 不可）、endpoint、auth_mode（none / bearer / oauth / basic）、 そしてその暗号化されたクレデンシャルを持ちます。これはコンソールから行います — 書き込みには Developer+ が必要です。 
# Console route, called with your session/access token (UserAuth).
curl https://api.orcarouter.ai/api/workspace/firewall/mcp_servers \
  -H "Authorization: Bearer <your-access-token>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "github",
    "endpoint": "https://api.githubcopilot.com/mcp",
    "auth_mode": "bearer",
    "auth_json": "{\"token\":\"ghp_x\"}",
    "enabled": true
  }'
次に、ツールを発見し到達可能性（ok / degraded / down）を記録するために プローブします： 
curl -X POST \
  https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42/probe \
  -H "Authorization: Bearer <your-access-token>"
これで、github.create_issue が何を受け付けるかを正確に知った上で github.* に 対してルールを書けます。エンドツーエンドのウォークスルーは MCP サーバーの接続にあります。
シークレットは決して平文で保存されません。 auth_json は保存時に暗号化され、 読み取り時にマスクされます。更新時には、保存値を維持するためにマスクをそのまま返して ください。クレデンシャルローテーションを 参照してください。

​
5. エージェントをゲートウェイに接続する

サーバーが登録されたら、任意の MCP クライアントを ファイアウォールゲートウェイスコープのキー（そのスコープを持たないトークンは 403 を受け取ります）とともにゲートウェイに向けます： 
https://api.orcarouter.ai/api/v1/firewall/mcp
ゲートウェイは streamable HTTP を話し、有効で到達可能なすべてのサーバーのツールを <server>.<tool> 名前空間の下でアドバタイズします。呼び出しを自身でプロキシする SDK は、同じゲートウェイトークンで GET /api/v1/firewall/mcp_servers から ランタイムレジストリを読み取れます。

​
6. ツールが到達できる先をロックダウンする

呼び出しごとの判定はどのツールが実行されるかを統制し、egress 制御はどこに到達 してよいかを統制します。2 つのレイヤーが協調します。 第 1 に、ゲートウェイが登録されたサーバーのエンドポイントに接続するとき、その URL はデフォルトでプライベート（RFC1918）、ループバック、リンクローカル、クラウド メタデータの範囲に対して検証されます — そしてホストは DNS 解決されるため、ブロック された範囲に解決される名前も拒否されます。したがって、169.254.169.254 や イントラネットアドレスに向けられた BYO サーバーは、明示的にホワイトリスト化して いない限り拒否されます。 第 2 に、ツールごとの宛先については、egress ルールが egress サーフェス上で 呼び出しのアウトバウンド宛先に対して照合されるホスト／CIDR の許可／拒否リストを 持ちます。ベースラインのユースケーステンプレートには、そのリストがすでに プライベート、ループバック、リンクローカル、クラウドメタデータの範囲 （169.254.169.254 と metadata.google.internal を含む）をカバーする既製の egress 拒否ルールが付属しているため、適用すれば CIDR を手で書くことなく SSRF／ メタデータ防御が得られます。
SSRF と egress は、「このツールがデータを返した」と「このツールがあなたのシークレット を攻撃者のホストに持ち出した」の違いです。ベースラインの egress 拒否リストを適用し、 独自のホスト／CIDR ルールを追加してください — egress 制限と データ持ち出しを参照してください。

​
7. 監視する：イベント、ラン、異常

すべての統制された呼び出しはトレイルを残します。ファイアウォールイベントは判定、 サーフェス、マッチしたルールを記録し、ランはセッションの呼び出しをグループ化し、 異常フィードは学習されたベースラインに対する頻度とコストのスパイクをフラグします。 設定、ポリシー、発見されたツールの読み取りは任意の Member に開放されています。 イベント／ラン／集計の読み取りには Developer+ が必要です。

​
8. 次のステップ

MCP サーバーの接続

サーバーを登録、プローブし、ゲートウェイ経由で公開します。

MCP ツールの許可リスト化

サーバーをデフォルト拒否にし、レビューしたツールだけを許可します。

ラグプル防御

承認後に変化するサーバーとスキルを統制します。

ファイアウォール：MCP サーバー

完全なフィールドとルートのリファレンス。
このモデルが初めてですか？ MCP 統制がどこに収まるかを見るには ガードレール vs. ファイアウォール を読み、それが閉じる脅威については MCP ツールポイズニングと 過剰なエージェンシーを読んでください。