跳轉到主要內容
當一個代理呼叫 http_fetch、web_search，或任何開啟一個外送連線的 工具時，目的地是你最需要治理的部分。一個能觸及 169.254.169.254 的混亂或被劫持的代理會讀取你的雲端憑證;一個能 POST 到攻擊者主機 的代理會外洩你的資料。代理 egress 控制治理那個目的地——你在 防火牆的 egress 介面上撰寫一條 host/CIDR 允許／拒絕規則,將它 綁定到一個金鑰,而閘道會在呼叫送出之前檢查一個代理的工具回報的 每一個外送目的地。 這是一個聚焦的使用情境頁。關於完整的規則文法與裁決語意,參見 規則綱要與 裁決;關於 egress 如何坐落在 其他強制執行點之間,參見介面。

​
1. Egress 介面上的代理 egress 控制

在防火牆的四個介面中,egress 是 那個看見一個工具回報的外送網路目的地——一個 host、一個 IP 字面值,或一個 CIDR——的介面。一條固定到 stage: egress 的規則匹配 那個目的地,而不是工具名稱或它的引數,這使它成為 SSRF 與資料外洩 控制:它回答這個代理能觸及哪裡,獨立於哪個工具做了觸及。
Egress 是目的地限定,而非工具封鎖。要完全阻止一個工具存在, 在 inbound 介面上依名稱拒絕它（封鎖工具）。 Egress 控制假設該工具可能正當地擷取——它只是約束去哪裡。

​
2. 一個範例：拒絕 SSRF 目的地

典型的 egress 規則拒絕 cloud metadata 端點與私有 RFC-1918 範圍——一個 擷取形狀的工具絕不應觸及的目的地。在你的工作區主控台中,開啟一個 政策並加入一條帶有 stage egress、裁決 deny 與一個 egress 清單的規則： 
{
  "label": "deny SSRF destinations",
  "stage": "egress",
  "verdict": "deny",
  "egress_json": "{\"deny\":[\"169.254.169.254\",\"10.0.0.0/8\",\"172.16.0.0/12\",\"192.168.0.0/16\"],\"allow\":[\"api.openai.com\"]}"
}
egress_json 是一個攜帶 host/CIDR 清單的 JSON 編碼字串——解碼後, 它是 {"deny": [...], "allow": [...]}。每個條目以一個 CIDR、一個 IP 字面值,或一個不區分大小寫的主機名稱匹配。對一個 deny 裁決而言,deny 清單是範圍內的集合（規則封鎖的目的地）,而 allow 清單從中切出例外——所以上面的規則封鎖那四個範圍,但讓 api.openai.com 通過,即使它曾經解析進其中一個範圍。當一個目的地是 一個主機名稱而非一個字面 IP、而你的清單攜帶 IP/CIDR 條目時,該名稱 會被盡力解析、其位址會被重新檢查,所以 metadata.internal 仍會匹配 一個 169.254.0.0/16 拒絕,即使它沒有按名稱列出。
改為一個允許清單姿態——只許可一個指名的目的地集合並封鎖其餘—— 請以裁決 allow 撰寫規則,並把你的目的地放進 allow 清單。極性會 翻轉:allow 變成範圍內的集合,而 deny 切出例外。將它與一個政策 default_verdict deny 搭配,這樣 allow 規則未涵蓋的任何東西都被 封鎖。

​
3. 你撰寫 CIDR 規則——沒有預設集附帶它們

沒有預設的 CIDR 清單。 OrcaRouter 不附帶一個拒絕 169.254.169.254、RFC-1918 或任何其他範圍的內建規則。那條 CIDR 允許／拒絕規則是你要撰寫的——它是 §2 中的範例,由你對著你自己的 網路撰寫。複製它,然後將範圍與允許清單例外調整到你的環境。
tight 自主等級及其 block_ssrf_egress 預設集確實附帶的,是一組對擷取形狀的工具 名稱——http_fetch、web_search、fetch_url、request,加上它們的 <server>.<tool> MCP 變體——的拒絕。那是一個直接的姿態:它直接拒絕 那些 egress 形狀的工具,而不是限定它們可以觸及哪裡。當一個代理根本 不該做任何網路呼叫時去拿它;當它確實擷取但只從一個核准的主機集合 時,去拿一條目的地規則（§2）。
做法它約束什麼由誰撰寫
tight SSRF 預設集擷取形狀的工具名稱（拒絕它們）內建
Egress CIDR/host 規則一次擷取可觸及的目的地你

​
4. 一個被封鎖的 egress 的樣子

當一個目的地匹配一條強制執行的 egress 規則時,該呼叫會在它離開 閘道之前被拒絕,而該評估會被記錄為一個介面為 egress、裁決為 deny 的防火牆事件。在影子模式 下,該 deny 會被降級為 audit,原因加上前綴 [shadow] would …,所以 你能在強制執行它之前,精確衡量一條規則對照真實流量會封鎖哪些 目的地。
一個格式錯誤或無條目的 egress 清單會被保守地處理:一條強制執行的 deny 規則仍會把關（一個錯字不能靜默地讓它停止封鎖）,但一條帶有 壞清單的 allow 規則不會觸發——否則一個打錯字的允許清單會變成 allow-all 並遮蔽一個 default deny。新規則在儲存時被驗證（清單必須 宣告至少一個 allow 或 deny 條目）,所以這只會保護舊有的列。

​
5. 從真實流量撰寫，然後推出

事件記錄在每個 egress 介面 事件上記錄目的地主機（egress_host/egress_url）,所以將它篩選到 介面 egress,並從實際出現的目的地撰寫你的 deny 清單而非猜測。 Discovered Tools 分頁是一個每工具名稱的彙整（工具名稱與它們 觸發的介面）——它告訴你哪些擷取形狀的工具執行了,而不是它們 觸及的主機。參見分析。
主控台 Test 分頁會對照一個樣本 tool_name + 介面（+ 可選的 args）乾跑一個政策,並傳回裁決、匹配到的規則與原因——不派發任何 東西。它確認一次呼叫解析到哪條規則;要對照真實目的地確認你的 CIDR/host 運算,使用下方的影子模式（Test 載荷不攜帶一個目的地, 所以 egress 清單匹配是在即時 egress 流量上演練）。參見 測試規則。
開啟影子模式,egress deny 會以它會觸發的樣子被記錄而不封鎖。觀察篩選到介面 egress 的 事件記錄,確認它捕捉到你 預期的目的地,然後關閉影子。
閘道處的目的地限定是縱深防禦,而非最後一道防線。一個主機名稱 在評估時解析到的 IP,可能與一個工具實際撥打的那個不同（DNS rebinding）。也在你自己的 egress/dialer 層保留一個 IP 拒絕控制;閘道 規則是針對明顯情況的便宜起飛前捕捉。

​
6. 綁定政策以及誰能編輯它

一個政策在某個金鑰解析到它之前什麼都不做。在主控台中透過在 金鑰上設定 firewall_policy_id 來綁定,或將該政策設為工作區預設值。解析是: 金鑰綁定的政策（當它存在且已啟用時）,否則是工作區預設值。 所有 egress 規則設定都在主控台中於你的工作階段下執行 （/api/workspace/firewall/*）：
動作角色
讀取政策、預設集、discovered tools、自主 SimulateMember
建立／編輯／刪除 egress 規則與政策Developer+
乾跑 Test 端點（POST /test）Developer+
讀取事件記錄與執行彙整Developer+

​
相關

資料外洩

egress 控制處理的威脅。

介面

四個介面,以及 egress 坐落的位置。

裁決

deny、audit 與 allow 在線路上做什麼。

封鎖工具

依名稱而非依目的地拒絕一個擷取工具。

危險的工具呼叫

更廣的風險類別。

防火牆參考

完整的規則 + 匹配參考,包括 egress 清單。