跳转到主要内容
一个你连接的 MCP 服务器交付的工具会向网络伸手——一个 fetch、 一个 web_search、一个 webhook 投递器。工具名也许在你的允许列表上， 参数也许看起来干净，而调用仍然最终把你的数据 POST 到一个攻击者 控制的主机，或从 169.254.169.254 元数据端点拉取凭据。目的地是 调用中你的工具名规则从未看到的那部分。 mcp 出站控制关闭那个缺口。一条出站规则把一个防火墙判定限定到 一个工具触及的地方——一个主机、一个 IP 或一个 CIDR 范围——因此 被允许到 api.openai.com 的同一个 http_fetch 被拒绝到其他一切。 它运行在防火墙的 egress 面上，叠加在每一次 tools/call 已经经过的 每次调用的评估 之上。
这是一个控制台任务。防火墙规则住在 /api/workspace/firewall/* 路由上，它们用你的会话/访问令牌鉴权——不是一个中继 sk-orca-… 密钥。编写一条规则需要 Developer+ 角色。

​
1. 一条出站规则控制什么

一条普通规则在工具名及其参数上匹配。一条出站规则添加第三个 维度：调用解析到的目的地。你把规则的 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 阶段上的一个 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 判定、stage=egress 规则上的 egress_json
{ "allow": ["api.openai.com", "api.anthropic.com"] }
该规则现在只在目的地是那两个主机之一时触发（允许）。其他任何东西 都落到下一条规则——把它与一个 默认拒绝策略 配对，让一个 未列出的目的地被拒绝而不是被放行。
在你信任它之前测试它。控制台的 Test 标签页和 POST /api/workspace/firewall/test 端点（Developer+）对照你的草稿 策略重放一次样本调用，因此你可以在不发送实时流量的情况下确认对一个 已知目的地的判定。

​
4. 它如何与防火墙的其余部分组合

一条出站规则是一个 工作区防火墙策略 中众多规则之一。引擎按 优先级顺序（最低优先）遍历规则，第一个匹配获胜，因此把一条紧的 出站 deny 放在任何宽泛 allow 的上面。
一条出站规则上的判定效果
deny拦截到范围内目的地的调用——在 egress 面上记录并作为一个错误返回给工具。
audit把匹配的调用记录为一个 防火墙事件；仍然派发。
allow允许范围内目的地；与一个默认拒绝底线配对。
pending_approval 和 cap_cost 在 egress 面上不被执行—— egress 是一个目的地检查，不是一个挂起或一个消费上限。改为在 mcp 或 inbound 面上使用那些判定。参见 判定参考。
有两个相关控制值得与一条出站规则一起接线：
独立于你编写的任何规则， MCP 网关 对照一个 SSRF 策略校验每个 服务器端点及其解析出的拨号 IP——内网范围和云元数据地址被拒绝， 并且 IP 在每一跳上被重新核查以挫败 DNS 重绑定。你的出站规则在 那个基线之上叠加一个工作区特定的目的地策略。
一条单独的出站 deny 阻止一个工具触及一个主机。一条 序列规则 阻止那条链——例如 “读取一个文件，然后在窗口内出站”——通过只在出站腿跟在一次敏感 读取之后时标记它。那是 lethal-trifecta（致命三联）断路器；出站 限定是每次调用的控制。

​
5. 先 shadow，然后执行

在一个繁忙的工作区上把一条出站 deny 直接推向执行，有风险破坏一个 你忘了的合法集成。两张安全网：
  • Shadow 模式。 一个处于 shadow 模式的策略把每一个执行判定降级 为 audit——你的出站 deny 记录 [shadow] would deny … 而不是拦截， 因此你在它咬人之前看到爆炸半径。
  • Observe 模式。 工作区 firewall_observe_mode 设置把未覆盖的 调用记录为 已发现工具，浮现你的智能体 已经触及的真实目的地，因此你可以从数据而不是猜测来编写一个准确的 允许列表。
出站目的地匹配以调用在评估时解析到的主机为键。一个有敌意的服务器 仍然可以在策略检查与实际拨号之间重绑定 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 在 body 中）。
DELETE /api/workspace/firewall/rules/:idDeveloper+移除一条规则。
POST /api/workspace/firewall/testDeveloper+对照一个草稿策略重放一次样本调用。

​
相关

防火墙规则参考

完整的规则 DSL——工具 globs、args 匹配、出站列表、序列。

连接一个 MCP 服务器

注册一个服务器，让它的工具调用在防火墙后运行。

允许列表 MCP 工具

默认拒绝你没有明确批准的工具。

数据外泄

出站控制为阻止而生的威胁。