メインコンテンツへスキップ
接続する MCP サーバーは、ネットワークに到達するツール — fetch、web_search、 webhook ポスター — を提供します。ツール名は許可リストにあるかもしれず、引数は クリーンに見えるかもしれず、それでも呼び出しはあなたのデータを攻撃者制御のホストに POST したり、169.254.169.254 メタデータエンドポイントからクレデンシャルを引き出したり してしまいます。宛先は、あなたのツール名ルールが決して見ない呼び出しの部分です。 mcp egress 制御はそのギャップを閉じます。egress ルールは、ファイアウォール判定を ツールが到達する先 — ホスト、IP、または CIDR 範囲 — にスコープするため、api.openai.com への到達が許可された同じ http_fetch が、それ以外のすべてに拒否されます。それは すべての tools/call がすでに通る呼び出しごとの評価の上に、 ファイアウォールの egress サーフェス上で実行されます。
これはコンソールタスクです。ファイアウォールルールは /api/workspace/firewall/* ルート上にあり、リレーの sk-orca-… キーではなく、あなたのセッション／アクセス トークンで認証します。ルールの作成には Developer+ ロールが必要です。

​
1. egress ルールが制御するもの

通常のルールはツール名とその引数でマッチします。egress ルールは 3 つ目の 次元を追加します：呼び出しが解決される宛先です。ルールの stage を egress に 設定し、許可／拒否エントリの egress_json リストを添付します。エンジンは呼び出しから 宛先ホストを抽出し、そのホストがスコープ内にあるときだけルールを発火させます。 エントリは 3 通りでマッチされます：

ホスト名

大文字小文字を区別しない完全一致、例：api.openai.com。末尾のドットは両側で トリミングされます。

IP リテラル

解決されたダイヤル IP に対する完全一致、例：169.254.169.254。

CIDR 範囲

宛先 IP — リテラルまたは DNS 解決済み — がブロック内に収まる必要があります、 例：10.0.0.0/8。
宛先がホスト名だがあなたのリストが IP/CIDR エントリを持つとき、名前は解決され その IP が再チェックされます — そのため、metadata.internal は名前でリストされて いなくても 169.254.0.0/16 の deny にマッチします。これは、拒否された範囲に解決 される名前に対するベストエフォートの多層防御です；権威ある SSRF ガードは依然として ゲートウェイのダイヤルレイヤー で実行されます。

​
2. 具体例 1 つ

すべての fetch 形状のツールがクラウドメタデータエンドポイントと RFC-1918 範囲に 到達するのを拒否します。これは標準的な SSRF 持ち出しレッグの切断です：egress ステージ上の deny 判定で、egress_json 拒否リストでスコープされます。 
curl https://api.orcarouter.ai/api/workspace/firewall/rules \
  -H "Authorization: Bearer <your-session-or-access-token>" \
  -H "Content-Type: application/json" \
  -d '{
    "policy_id": 12,
    "priority": 10,
    "label": "Deny SSRF / metadata egress",
    "stage": "egress",
    "tool_name_glob": "*",
    "verdict": "deny",
    "egress_json": "{\"deny\":[\"169.254.169.254\",\"10.0.0.0/8\",\"172.16.0.0/12\",\"192.168.0.0/16\"]}"
  }'
宛先がそれらの範囲のいずれかに解決される tools/call は、ツールエラーとしてモデルに 戻ってきます；拒否リストがカバーしない公開ホストへの呼び出しは通過します。
許可／拒否リストは判定で意味が反転します。deny（またはその他の強制）ルールでは、 deny リストがスコープ内の集合で、allow が例外を切り出します — 「これらを拒否、 ただしあれらを除く」。allow ルールでは役割が逆転します：allow リストが スコープ内の集合で、deny が例外を切り出します — 「これらだけを許可」。空でない egress_json は、少なくとも 1 つの allow または deny エントリを宣言しなければ ならず、さもなくば書き込みは拒否されます。

​
3. ひとつの宛先だけを許可リスト化する

上の例の逆：fetch ツールをひとつの認可されたホストにピン留めし、ポリシーの default_verdict（または後続のキャッチオール）に残りを処理させます。これは allow 判定なので、allow リストがスコープ内の集合です。 
// egress_json on an allow-verdict, stage=egress rule
{ "allow": ["api.openai.com", "api.anthropic.com"] }
ルールは今や、宛先がそれら 2 つのホストのいずれかであるときだけ発火（許可）します。 それ以外は次のルールに落ちます — これをデフォルト拒否ポリシー とペアにして、リストにない宛先が手を振って通されるのではなく拒否されるようにします。
信頼する前にテストします。コンソールの Test タブと POST /api/workspace/firewall/test エンドポイント（Developer+）は、サンプル呼び出しを あなたのドラフトポリシーに対してリプレイするため、ライブトラフィックを送らずに 既知の宛先での判定を確認できます。

​
4. ファイアウォールの残りとどう組み合わさるか

egress ルールは、ワークスペースファイアウォールポリシー内の 多くのルールのひとつです。エンジンは優先順位順（最も低いものから）にルールを歩き、 最初のマッチが勝つため、厳格な egress deny を広い allow の上に置いてください。
egress ルール上の判定効果
denyスコープ内の宛先への呼び出しをブロックします — egress サーフェスに記録され、ツールにエラーとして返されます。
auditマッチした呼び出しをファイアウォールイベントとしてログに記録します；依然としてディスパッチします。
allowスコープ内の宛先を許可します；デフォルト拒否のフロアとペアになります。
pending_approval と cap_cost は egress サーフェス上では強制されません — egress は宛先チェックであり、保留や支出上限ではありません。それらの判定は代わりに mcp または inbound サーフェス上で使ってください。 判定リファレンスを参照してください。
egress ルールと並べて配線する価値のある 2 つの関連する制御があります：
あなたが作成する任意のルールとは独立に、MCP ゲートウェイ はすべてのサーバーエンドポイントとその解決されたダイヤル IP を SSRF ポリシーに 対して検証します — イントラネット範囲とクラウドメタデータアドレスは拒否され、 IP は DNS リバインディングを打ち破るためにすべてのホップで再チェックされます。 あなたの egress ルールは、そのベースラインの上にワークスペース固有の宛先ポリシーを 重ねます。
単一の egress deny は、ツールがホストに到達するのを止めます。 シーケンスルールはチェーンを止めます — 例：「ファイルを読み、それからウィンドウ内で egress する」 — egress レッグを、 それがセンシティブな読み取りに続くときだけフラグすることで。それが lethal-trifecta ブレーカーです；egress スコープは呼び出しごとの制御です。

​
5. まずシャドウし、それから強制する

混雑したワークスペースで egress deny をいきなり強制にロールすると、忘れていた正当な 統合を壊すリスクがあります。2 つのセーフティネット：
  • シャドウモード。 シャドウモードのポリシーは、すべての強制判定を audit に ダウングレードします — あなたの egress deny は、ブロックする代わりに [shadow] would deny … をログに記録するため、作用する前に影響範囲が見えます。
  • observe モード。 ワークスペースの firewall_observe_mode 設定は、カバーされて いない呼び出しを発見されたツールとしてログに記録し、 エージェントがすでに到達している実際の宛先を表面化するため、推測ではなくデータから 正確な許可リストを書けます。
egress 宛先マッチングは、評価時に呼び出しが解決されるホストをキーにします。敵対的な サーバーは、ポリシーチェックと実際のダイヤルの間で依然として DNS をリバインドできます （TOCTOU） — それがまさに、ゲートウェイのソケットレイヤー IP ガードが権威ある制御で あり、このルールが唯一の防衛線ではなく多層防御である理由です。

​
6. ロールとルート

すべてのコンソールルートはワークスペーススコープで、あなたのセッション／アクセス トークンで認証します。読み取りは任意の Member に開放されています；ルールの作成 または編集には Developer+ が必要です。
メソッドとパスロール目的
GET /api/workspace/firewall/policies/:idMemberポリシーとそのルールを読みます。
POST /api/workspace/firewall/rulesDeveloper+ルールを追加します（stage: egress を設定）。
PUT /api/workspace/firewall/rulesDeveloper+ルールを更新します（id はボディ内）。
DELETE /api/workspace/firewall/rules/:idDeveloper+ルールを削除します。
POST /api/workspace/firewall/testDeveloper+サンプル呼び出しをドラフトポリシーに対してリプレイします。

​
関連

ファイアウォールルールリファレンス

完全なルール DSL — ツールグロブ、引数マッチング、egress リスト、シーケンス。

MCP サーバーの接続

サーバーを登録して、そのツール呼び出しがファイアウォールの背後で実行されるように します。

MCP ツールの許可リスト化

明示的に承認しなかったツールをデフォルト拒否します。

データ持ち出し

egress 制御が止めるために作られた脅威。