跳轉到主要內容
一個你連接的 MCP 伺服器隨附觸及網路的工具——一個 fetch、一個 web_search、一個 webhook poster。工具名稱可能在你的 允許清單上、引數可能看起來乾淨，而該呼叫仍然最終 把你的資料 POST 到一個攻擊者控制的主機，或從 169.254.169.254 中繼資料端點拉取憑證。目的地是該呼叫中 你的工具名稱規則永遠看不見的部分。 mcp egress 控制封堵那個缺口。一條 egress 規則把一個防火牆 裁決限定到一個工具觸及何處——一個主機、一個 IP，或一個 CIDR 範圍——所以 被允許觸及 api.openai.com 的同一個 http_fetch 被拒絕觸及 其他一切。它在防火牆的 egress 表面上執行，凌駕於 每一次 tools/call 都已經經過的每次呼叫評估之上。
這是一個主控台任務。防火牆規則位於 /api/workspace/firewall/* 路由上，這些路由以你的工作階段／ 存取權杖驗證——而非一個轉送 sk-orca-… 金鑰。撰寫一條規則需要 Developer+ 角色。

​
1. 一條 egress 規則控制什麼

一條一般規則在工具名稱及其引數上匹配。一條 egress 規則加上第三個維度：該呼叫解析到的目的地。 你把規則的 stage 設為 egress 並附加一個 egress_json allow / deny 條目清單。引擎會從該呼叫中萃取目的地主機 並只在那個主機在範圍內時觸發該規則。 條目以三種方式匹配：

主機名稱

不分大小寫的精確匹配，例如 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. 一個具體範例

拒絕每一個 fetch 形狀的工具觸及雲端中繼資料端點與 RFC-1918 範圍。這是經典的 SSRF 外洩腿切斷：在 egress stage 上的一個 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 會 作為一個工具錯誤回到模型；一個對拒絕清單未涵蓋的公開主機的 呼叫則通過。
allow/deny 清單會隨裁決翻轉意義。在一個 deny（或 其他強制執行）規則上，deny 清單是範圍內集合，而 allow 劃出豁免——「拒絕這些，除了那些」。在一個 allow 規則上 角色反轉：allow 清單是範圍內集合，而 deny 劃出 豁免——「只允許這些」。一個非空的 egress_json 必須宣告 至少一個 allow 或 deny 條目，否則寫入會被拒絕。

​
3. 只允許清單一個目的地

上面範例的反面：把一個 fetch 工具釘在一個單一獲准的 主機上，並讓政策的 default_verdict（或一個之後的全包規則）處理 其餘的。因為這是一個 allow 裁決，allow 清單是 範圍內集合。 
// 一個 allow-verdict、stage=egress 規則上的 egress_json
{ "allow": ["api.openai.com", "api.anthropic.com"] }
該規則現在只在目的地是那兩個主機之一時觸發（允許）。 其他任何東西都會落到下一條規則——把這個與一個 預設拒絕政策搭配，讓一個未列出的 目的地被拒絕而非被放行。
在你信任它之前先測試它。主控台的 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 規則一起接線：
獨立於你撰寫的任何規則， MCP 閘道會對照一個 SSRF 政策驗證每個伺服器端點 及其解析出的撥接 IP——內網範圍與 雲端中繼資料位址會被拒絕，且該 IP 會在 每一個躍點被重新檢查以挫敗 DNS 重新綁定。你的 egress 規則在那個 基準之上疊加一個工作區特定的目的地政策。
一條單一的 egress deny 會停止一個工具觸及一個主機。一條 序列規則會停止 整條鏈——例如「讀取一個檔案，然後在窗口內 egress」——透過 只在 egress 腿緊跟在一次敏感讀取之後時標示它。那是 致命三重奏破壞器；egress 範圍限定是每次呼叫的控制。

​
5. 先 shadow，再強制執行

在一個繁忙的工作區上把一條 egress deny 直接推到強制執行，冒著 弄壞一個你忘記的合法整合的風險。兩個安全網：
  • Shadow 模式。 一個處於 shadow 模式的政策會把每一個強制執行 裁決降級為 audit——你的 egress deny 會記錄 [shadow] would deny … 而非 封鎖，所以你在它咬人之前看見爆炸半徑。
  • Observe 模式。 工作區 firewall_observe_mode 設定會把 未涵蓋的呼叫記錄為探索到的工具，浮現你的代理 已經觸及的真實目的地，所以你可以從資料而非猜測 撰寫一個準確的允許清單。
Egress 目的地匹配鍵控在該呼叫於評估時解析到的 主機。一個敵對伺服器仍能在政策檢查與實際撥接之間 重新綁定 DNS（TOCTOU）——這正是為何閘道的 socket 層 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——工具 globs、引數匹配、egress 清單、序列。

連接一個 MCP 伺服器

註冊一個伺服器，使它的工具呼叫在防火牆後方執行。

允許清單 MCP 工具

預設拒絕你未明確核准的工具。

資料外洩

egress 控制被建來阻止的威脅。