跳转到主要内容
当一个智能体调用 http_fetch、web_search 或任何打开一个出站连接的工具 时，目的地是你最需要治理的部分。一个能触及 169.254.169.254 的困惑或被 劫持的智能体会读取你的云凭据；一个能向攻击者主机 POST 的智能体会外泄你的 数据。智能体 egress 控制治理那个目的地——你在防火墙的 egress 执行面 上编写一条 host/CIDR 白名单/黑名单规则，把它绑定到一个密钥，网关就会在 调用发出之前检查一个智能体工具报告的每一个出站目的地。 这是一个聚焦的用例页面。关于完整的规则语法和判定语义参见 规则 schema 与 判定；关于 egress 在其他执行点中的位置 参见 执行面。

​
1. egress 执行面上的智能体 egress 控制

在防火墙的四个 执行面 中，egress 是那个 看到一个工具报告的出站网络目的地的执行面——一个主机、一个 IP 字面量， 或一个 CIDR。一条钉在 stage: egress 上的规则匹配那个目的地，而非工具名 或它的参数，这使它成为 SSRF 与数据外泄的控制：它回答这个智能体能触及 哪里，独立于哪个工具做了触及。
Egress 是目的地限定，而非工具拦截。要彻底阻止一个工具存在，在 inbound 执行面上按名称拒绝它（拦截工具）。 Egress 控制假定该工具可能正当地抓取——它只是约束抓取到哪里。

​
2. 一个示例：拒绝 SSRF 目的地

标准的 egress 规则拒绝云元数据端点和私有 RFC-1918 范围——一个 fetch 形态 工具永远不应该触及的目的地。在你的工作区控制台中，打开一条 策略 并添加一条 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 划出例外。把它与一个 deny 的策略 default_verdict 搭配，这样任何 allow 规则没覆盖的东西都被拦截。

​
3. 你来编写 CIDR 规则——没有任何预设附带它们

没有预设 CIDR 列表。 OrcaRouter 不附带一条拒绝 169.254.169.254、 RFC-1918 或任何其他范围的内置规则。CIDR 白名单/黑名单规则由你来编写 ——它就是 §2 中的示例，由你针对你自己的网络编写。复制它，然后把范围和 白名单例外调整到你的环境。
tight 自治级别 及其 block_ssrf_egress 预设确实附带的，是一组针对 fetch 形态工具名的拒绝——http_fetch、 web_search、fetch_url、request，外加它们的 <server>.<tool> MCP 变体。那是一种直接的姿态：它直接拒绝那些 egress 形态的工具，而非限定它们 能触及哪里。当一个智能体根本无权做网络调用时使用它；当它确实抓取但只 从一个批准的主机集合抓取时，使用一条目的地规则（§2）。
做法它约束什么编写者
tight SSRF 预设Fetch 形态工具名（拒绝它们）内置
Egress CIDR/host 规则一次 fetch 可能触及的目的地你

​
4. 一次被拦截的 egress 是什么样

当一个目的地匹配一条执行性 egress 规则时，该调用在离开网关之前被拒绝，而 该评估被记录为一个执行面为 egress、判定为 deny 的防火墙事件。在 影子模式 下，该拒绝被降级为 audit， 原因前缀为 [shadow] would …，所以你能在执行之前对照真实流量准确衡量一条 规则本来会拦截哪些目的地。
一个格式不正确或无条目的 egress 列表被保守对待：一条执行性 deny 规则 仍然设门（一个笔误不能静默地让它停止拦截），但一条带有损坏列表的 allow 规则不会触发——否则一个键入错误的白名单会变成全部允许并遮蔽一个默认 拒绝。新规则在保存时被验证（该列表必须声明至少一个 allow 或 deny 条目）， 所以这只保护遗留行。

​
5. 从真实流量编写，然后上线

事件日志 在每个 egress 执行面事件 上记录目的地主机（egress_host/egress_url），所以把它过滤到执行面 egress，并从实际出现的目的地编写你的拒绝列表，而非猜测。 Discovered Tools 标签是一个逐工具名的汇总（工具名以及它们触发的 执行面）——它告诉你哪些 fetch 形态工具运行了，而非它们触及的主机。 参见 分析。
控制台 Test 标签对一个样本 tool_name + 执行面（+ 可选参数） dry-run 一条策略，并返回判定、匹配到的规则和原因——不派发任何内容。它 确认一次调用解析到哪条规则；要对照真实目的地确认你的 CIDR/host 计算，使用下面的影子模式（Test 载荷不携带一个目的地，所以 egress 列表 匹配在实时 egress 流量上被检验）。参见 测试规则。
打开 影子模式，那么该 egress 拒绝 会像本来会触发那样被记录而不拦截。观察过滤到执行面 egress 的 事件日志，确认它捕获你预期的目的地， 然后关闭影子。
网关上的目的地限定是纵深防御，而非最后一道防线。一个主机名在评估时 解析到的 IP 可能与一个工具实际拨打的不同（DNS 重绑定）。也在你自己的 egress/dialer 层保留一个 IP 拒绝控制；网关规则是针对明显情况的廉价预检 捕获。

​
6. 绑定策略以及谁能编辑它

一条策略在某个密钥解析到它之前什么都不做。在控制台中通过在 密钥 上设置 firewall_policy_id 来 绑定，或将该策略设为工作区默认。解析是：密钥绑定的策略（当它存在且已启用 时），否则工作区默认值。 所有 egress 规则配置都在控制台中于你的会话下运行 （/api/workspace/firewall/*）：
操作角色
读取策略、预设、discovered tools、自治 SimulateMember
创建 / 编辑 / 删除 egress 规则和策略Developer+
Dry-run Test 端点（POST /test）Developer+
读取事件日志和运行汇总Developer+

​
相关

数据外泄

egress 控制应对的威胁。

执行面

四个执行面，以及 egress 的位置。

判定

deny、audit 和 allow 在线上做什么。

拦截工具

按名称而非按目的地拒绝一个 fetch 工具。

危险工具调用

更广的风险类别。

防火墙参考

完整的规则 + 匹配参考，包括 egress 列表。