メインコンテンツへスキップ
エージェントに Model Context Protocol(MCP)サーバー — 独自のリモートサーバー、 またはバンドルされたもの — を使わせたいが、それが公開するすべてのツール呼び出しを 単一の監査済みチョークポイントの背後で実行したい。最初のステップは、ワークスペースに サーバーを登録することです:name、endpoint、auth mode、そしてそのクレデンシャル。 登録されると、MCP ゲートウェイはそのツールをひとつの 接続の下でアドバタイズし、実際のサーバーに到達する前にすべての tools/call を あなたのファイアウォールポリシーを通して評価します。 このページはその 1 つのタスク — サーバーレコードの接続と設定 — をカバーします。 ゲートウェイのランタイム挙動と呼び出しごとの判定については MCP リファレンスを参照してください。全体像については MCP セキュリティ概要から始めてください。
登録はコンソールアクションです(/api/workspace/firewall/* ルートは、リレーの sk-orca-… キーではなく、セッション/アクセストークンで認証します)。書き込みには Developer+ ロールが必要です。任意のメンバーがサーバーを一覧できます。

1. MCP サーバーの接続方法

コンソールで Firewall → MCP Servers を開いてサーバーを追加するか、ワークスペース API を直接呼び出します。登録は重要な 4 つのものを持ちます:

name

ワークスペースごとに一意。これが <server>.<tool> 名前空間のプレフィックスに なるため、同じワークスペース内の重複した名前は HTTP 409 で拒否されます。

endpoint

あなたのリモート MCP サーバーの URL。バンドルされたインプロセスサーバーを 可視かつ統制可能になるよう登録するには、空のままにします。

auth_mode

ゲートウェイがあなたのサーバーに認証する方法:nonebeareroauth、 または basic

credentials

モード固有のシークレット。保存時に暗号化され読み取り時にマスクされます — モデルやクライアントに到達することは決してありません。
サーバーは enabled で始まり、無効化した瞬間にゲートウェイから完全に除外されます — それがオフスイッチであり、無効化されたサーバーのクレデンシャルは決して復号されません。

2. 具体例 1 つ

bearer トークンを使ってリモートの GitHub MCP サーバーを登録します。これはコンソール 相当の REST 呼び出しで、フィールド名はフォームが書き込むものと正確に一致します。
curl https://api.orcarouter.ai/api/workspace/firewall/mcp_servers \
  -H "Authorization: Bearer <your-session-or-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
  }'
クレデンシャルの形状は auth_mode に依存します:
{"token":"…"} — bearer トークンとしてあなたのサーバーに送られます。
{"access_token":"…"} — ゲートウェイが bearer ヘッダーとして送る静的アクセス トークン。自動的なクライアントクレデンシャル交換はまだサポートされていません。 保存された access_token がなければ、oauth モードのプローブは認証なしで接続する のではなく失敗します。
{"username":"…","password":"…"}
空文字列。クレデンシャルは添付されません。
読み取り時には、クレデンシャルとエンドポイントの両方がマスクされます — API は 生の値ではなく、センチネルのプレースホルダーを返します。サーバーを更新するときは、 それらのプレースホルダーをそのまま返して保存値を維持してください。実際にシークレット をローテーションするときだけ、新しい auth_json を送ります。 クレデンシャルローテーションを参照して ください。

3. ヘルスをプローブする

サーバーのツールに対してファイアウォールルールを書けるようになる前に、それらが 到達可能であることと、何という名前かを知る必要があります。サーバーをプローブします — ゲートウェイは復号されたクレデンシャルを使って MCP initialize + tools/list ハンドシェイクを実行し、到達可能性を記録し、アドバタイズされたツールを返します:
curl -X POST \
  https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42/probe \
  -H "Authorization: Bearer <your-session-or-access-token>"
{
  "status": "ok",
  "last_checked_at": 1700000000,
  "tools": [
    { "name": "create_issue", "description": "…", "input_schema": {} }
  ]
}
status はサーバーレコードに記録され、ヘルスインジケーターを駆動します:
status意味
ok到達可能;ツールはゲートウェイから提供されます。
degraded到達可能だが、ハンドシェイクが部分的だった。
down最後のプローブで到達不能;サーバーはスキップされます。
down のサーバーは、ゲートウェイがツールセットを構築するときに除外されるため、 一時的な障害はディスパッチを壊す代わりに優雅に劣化します。プローブは結果にかかわらず その結果を返します — 失敗したプローブは、トランスポートエラーではなく、 status: down とスクラブされた理由を伴う 200 として戻ってきます。
バンドルされたインプロセスサーバー(空の endpoint)はローカルでディスパッチ され、プローブ不可です — それをプローブすると、登録にエンドポイントがないことを 説明するエラーで拒否されます。URL を持つ BYO サーバーだけをプローブします。
すべての登録変更は、ゲートウェイのワークスペースごとのツールキャッシュを即座に無効化 するため、新しく接続、無効化、または再プローブされたサーバーは、キャッシュウィンドウの 後ではなく、次の接続で反映されます。

4. 接続された後

サーバーが登録され ok でプローブされると、そのツールは統制されます:
  • すべての呼び出しが評価されます。tools/call は、あなたのサーバーに到達 する前に mcp サーフェス上であなたのファイアウォールポリシーを通ります。ツール名を 知った今、tool_name_glob: github.* でルールをスコープします。
  • サーフェスをロックダウンします。 明示的に許可しなかったツールをデフォルトで 拒否します — MCP ツールの許可リスト化を 参照してください。
  • 到達先を統制します。 ツールが任意のホストを取得できないように egress ルールを作成します。
  • 変化を監視します。 信頼したサーバーが事後にツール定義を変えることがあります。 ラグプル防御がそのドリフトをフラグします。

5. API リファレンス

すべてのコンソールルートはワークスペーススコープで、セッション/アクセストークンで 認証します。リストの読み取りは任意の Member に開放されています(シークレット マスク)。すべての書き込みには Developer+ が必要です。
メソッドとパスロール目的
GET /api/workspace/firewall/mcp_serversMemberサーバー一覧(シークレット + エンドポイントマスク)。
GET /api/workspace/firewall/mcp_servers/:idMember単一サーバー、マスク済み。
POST /api/workspace/firewall/mcp_serversDeveloper+サーバーを登録(重複名で 409)。
PUT /api/workspace/firewall/mcp_serversDeveloper+サーバーを更新(id はボディ内)。
DELETE /api/workspace/firewall/mcp_servers/:idDeveloper+ソフト削除;名前を解放。
POST /api/workspace/firewall/mcp_servers/:id/probeDeveloper+到達可能性をプローブ + ツールを発見。
エージェントの SDK プロキシは、GET /api/v1/firewall/mcp_servers(有効なサーバー のみ)でゲートウェイスコープのトークンを使ってランタイムレジストリを読み取ります。 その側を認証する方法については MCP ゲートウェイの認証を参照してください。
そもそもなぜ OrcaRouter 経由で接続するのか? ひとつの場所がすべてのツール呼び出し を見るためです — ひとつの接続、ひとつのポリシー、ひとつの監査済みログ、そして エージェント設定に散在する代わりにディスパッチ時に注入されるクレデンシャル。 動機についてはAI エージェントのセキュリティMCP ツールポイズニングの脅威を 読んでください。

関連

MCP セキュリティ概要

MCP 統制モデルの全体、端から端まで。

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

ゲートウェイのランタイム挙動と呼び出しごとの判定。

ゲートウェイの認証

エージェントが接続するトークンを発行しスコープします。

信頼チェックリスト

新しいサーバーを信頼する前に検証すべきすべて。