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

Model Context Protocol（MCP）は、エージェントが外部サーバーにホストされたツールを呼び出すことを可能にします。それは同程度に強力かつ危険です：エージェントが接続する各 MCP サーバーは、誰もレビューしていない新たなツール、クレデンシャル、ネットワーク到達範囲のセットです。ファイアウォールの MCP ゲートウェイは、それらすべての前に単一の監査済みチョークポイントを置きます。各 MCP サーバーを一度登録すると、ゲートウェイはそれらのツールを単一の接続の下でエージェントに公開し、すべての tools/call を、実際のサーバーに到達する前にファイアウォールエンジンを通します。

1. MCP 統制が提供するもの

ひとつのゲートウェイ、すべてのサーバー。 エージェントはひとつのエンドポイントに接続します。ゲートウェイは到達可能なすべての登録済みサーバーのツールを <server>.<tool> で名前空間化して集約するため、github.create_issue と shell.exec が単一の MCP 接続の下で並んで表示されます。
すべての呼び出しにポリシー。 各 tools/call はまずあなたのポリシーによって評価されます。ブロックされた呼び出しは、トランスポート障害ではなくツールエラー（firewall deny: …）としてモデルに戻るため、エージェントはクラッシュする代わりに反応できます。sanitize は転送前に引数を書き換えます；pending_approval は呼び出しを保留します。
SSRF ガード済み。 リモートエンドポイントはゲートウェイの SSRF ポリシーに対して検証されます — イントラネット範囲とクラウドメタデータアドレスはブロックされ、解決されたダイヤル IP は、リダイレクトを含むすべてのホップで DNS リバインディングを打ち破るために再チェックされます。
暗号化されたクレデンシャル。 サーバーの認証シークレットは保存時に暗号化され、読み取り時にマスクされます。ゲートウェイはディスパッチ時にそれらを注入します；モデルやクライアントに到達することは決してありません。

2. 2 種類のサーバー

種類	`endpoint`	挙動
BYO（持ち込み）	streamable-HTTP URL	ゲートウェイは `tools/call` をあなたのリモート MCP サーバーにプロキシします。
バンドル	空	OrcaRouter のインプロセス MCP サーバー。可視かつ統制可能になるよう登録されます；別途プローブはできません。

3. サーバーの登録

サーバーレコードは次を持ちます：

フィールド	備考
`name`	ビジネスキー。ワークスペースごとに一意、≤ 128 文字。`.` は不可 — `<server>.<tool>` の名前空間セパレータです。
`endpoint`	MCP サーバー URL（≤ 512 文字）。バンドルサーバーでは空。
`auth_mode`	`none`（デフォルト）、`bearer`、`oauth`、`basic`。
`auth_json`	モード固有のクレデンシャル（下記参照）。`auth_mode` が `none` でないときは常に必須。
`enabled`	デフォルトは `true`。無効化されたサーバーはゲートウェイから完全に除外されます。
`status`	到達可能性 — `ok`（デフォルト）、`degraded`、`down`。プローブによって設定されます。

モード別のクレデンシャル形状：

// bearer
{ "token": "ghp_…" }
// oauth
{ "client_id": "…", "client_secret": "…", "token_url": "…" }
// basic
{ "username": "…", "password": "…" }
// none
""

登録リクエストは次のようになります：

curl https://api.orcarouter.ai/api/workspace/firewall/mcp_servers \
  -H "Authorization: Bearer sk-orca-..." \
  -H "Content-Type: application/json" \
  -d '{
    "name": "github",
    "endpoint": "https://api.githubcopilot.com/mcp",
    "auth_mode": "bearer",
    "auth_json": "{\"token\":\"ghp_x\"}",
    "enabled": true
  }'

同じワークスペース内の重複した名前は HTTP 409 を返します（別のワークスペース内の同じ名前は問題ありません）。

シークレットは決して平文で保存されません。 auth_json はワークスペースのシークレットキーで保存時に暗号化されます。そのキーが設定されていない場合、クレデンシャルを暗号化せずに永続化するのではなく、書き込みが拒否されます。読み取り時には、シークレットとエンドポイントがマスクされます；保存された値を維持するには、更新時にマスクをそのまま返してください。2 つのクレデンシャル付き認証モード間を切り替えるには、新しい auth_json が必要です（暗号文はそのモードに形状結合されています）。

4. プローブ — ツールを発見する

サーバーのツールに対してルールを書けるようになる前に、その名前を知る必要があります。サーバーをプローブします：

curl -X POST \
  https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42/probe \
  -H "Authorization: Bearer sk-orca-..."

ゲートウェイはエンドポイントに対して MCP initialize + tools/list を実行し（復号されたクレデンシャルを使用、10 秒で制限）、到達可能性 status とタイムスタンプを記録し、アドバタイズされたツールをその入力スキーマとともに返します：

{
  "status": "ok",
  "last_checked_at": 1700000000,
  "tools": [
    { "name": "create_issue", "description": "…", "input_schema": { } }
  ]
}

これで、github.create_issue が何を受け付けるかを正確に知った上で、 tool_name_glob: github.* のようなルールを作成できます。バンドル（空エンドポイント）サーバーはプローブ不可で、400 を返します。

5. ライフサイクルと強制

有効 vs. 無効。 無効化されたサーバーはランタイムレジストリから除外されます — そのツールはゲートウェイから消え、そのクレデンシャルは決して復号されません。それがオフスイッチです。
到達可能性。 status（ok / degraded / down）は最後のプローブを反映します；到達不能なサーバーは、ゲートウェイがツールセットを構築するときにスキップされます。
呼び出しごとの判定。 ディスパッチ時にエンジンは、特定の <server>.<tool> 呼び出しに対してその引数とともに判定を返します：
- allow / audit → 転送（監査ログ、依然として許可）。
- sanitize → 書き換えられた引数で転送。
- deny / pending_approval / 不明なもの → ツールエラーとしてブロック。（統合ゲートウェイ経由では、保留された呼び出しは承認 id を通すのではなく永続的なエラーとして表面化します — 承認ハンドシェイクが必要なときは evaluate フックを使ってください。）
削除はソフト削除です；名前スロットは即座に解放されるため、同じ名前で再登録できます。

すべての変更は、ゲートウェイのワークスペースごとのツールキャッシュを即座に無効化するため、新しく登録、無効化、または再プローブされたサーバーは、キャッシュ TTL の後ではなく、次の接続で反映されます。

6. クライアントの接続

任意の MCP クライアントを、ファイアウォールゲートウェイスコープのトークンとともにゲートウェイエンドポイントに向けます：

https://api.orcarouter.ai/api/v1/firewall/mcp

ゲートウェイは streamable HTTP を話し（POST メッセージ、SSE ストリーム用の GET、セッション終了用の DELETE）、orcarouter-firewall-gateway として自身を識別します。有効で到達可能なすべてのサーバーのツールを <server>.<tool> 名前空間の下でアドバタイズし、各ツールの入力スキーマを逐語的に再公開します。ファイアウォールゲートウェイスコープのないトークンは 403 を受け取ります — これ専用のゲートウェイトークンを発行してください。

API リファレンス

コンソール（ワークスペーススコープ、RBAC）

メソッドとパス	ロール	目的
`GET /api/workspace/firewall/mcp_servers`	Member	サーバー一覧（シークレットマスク、エンドポイントリダクト）。
`GET /api/workspace/firewall/mcp_servers/:id`	Member	単一サーバー、マスク済み。
`POST /api/workspace/firewall/mcp_servers`	Developer+	サーバーを登録（重複名で 409）。
`PUT /api/workspace/firewall/mcp_servers`	Developer+	サーバーを更新（id はボディ内）。
`DELETE /api/workspace/firewall/mcp_servers/:id`	Developer+	ソフト削除；名前を解放。
`POST /api/workspace/firewall/mcp_servers/:id/probe`	Developer+	到達可能性をプローブ + ツールを発見。

ゲートウェイ（ファイアウォールゲートウェイスコープのトークン）

メソッドとパス	目的
`ANY /api/v1/firewall/mcp`	統合された MCP ゲートウェイのディスパッチエンドポイント。
`GET /api/v1/firewall/mcp_servers`	SDK プロキシ向けのランタイムレジストリ（復号された認証、有効なサーバーのみ）。
`POST /api/v1/firewall/evaluate`	単一の `tools/call` を自分でディスパッチする前に評価。

FAQ

そもそもなぜ MCP を OrcaRouter 経由でルーティングするのか？

すべてのツール呼び出しを見る場所をひとつにするためです。ゲートウェイがなければ、各エージェントは各 MCP サーバーに直接接続します — 共有ポリシーなし、監査トレイルなし、SSRF 保護なし、そしてクレデンシャルがエージェント設定に散在します。ゲートウェイはそのすべてを集中化します：ひとつの接続、ひとつのポリシー、ひとつの監査済みログ、ディスパッチ時に注入される暗号化されたシークレット。

ブロックされた MCP 呼び出しが戻ってきたときに何が起こるか？

モデルはそれをツールエラー（firewall deny: <reason>）として受け取ります — 任意の失敗するツールから得るのと同じ形状です。それによりエージェントは適応できます — 別のアプローチを試す、ユーザーに尋ねる、あるいは停止する — トランスポートクラッシュとして扱う代わりに。

同じツールをサーバーごとに異なる方法で統制できますか？

はい — それが <server>.<tool> 名前空間の目的です。tool_name_glob: trusted.* を持つルールは allow できる一方、community.* は audit されたり pending_approval にされたりします。さらに細かいスコープのために、スキル名グロブと組み合わせます。

ゲートウェイは SSRF から保護しますか？

はい。エンドポイント URL とその解決されたダイヤル IP は、登録時とすべてのディスパッチホップで SSRF ポリシーに対して検証されます — イントラネット範囲とクラウドメタデータアドレスは拒否され、解決された IP は DNS リバインディングを打ち破るために再チェックされます。ツールがどこに到達してよいかを統制するために、 egress ルールと組み合わせてください。

MCP サーバーを保護する（ゼロトラスト）

ゼロトラスト姿勢のもとで MCP サーバーを接続し、認証し、統制します。

MCP 信頼チェックリスト

サードパーティの MCP サーバーを信頼する前に検証すべきこと。

​1. MCP 統制が提供するもの

​2. 2 種類のサーバー

​3. サーバーの登録

​4. プローブ — ツールを発見する

​5. ライフサイクルと強制

​6. クライアントの接続

​API リファレンス

​コンソール（ワークスペーススコープ、RBAC）

​ゲートウェイ（ファイアウォールゲートウェイスコープのトークン）

​FAQ

​関連項目