跳转到主要内容
你有一条想放到生产前面的策略。恐惧不在策略——在于把它翻开后发现它拦截了 你智能体实际需要的一个工具，或掩码了你的应用依赖的一个字段。修复办法不是 在沙箱里做更多测试；而是在一个不能弄坏任何东西的姿态下、对照真实流量 上线，然后只在你看到什么触发之后才收紧。 本配方就是那个 rollout：observe → shadow → enforce，自治先 balanced 再 tight。你全程留在控制台（或 REST API）；智能体像以前那样继续调用 https://api.orcarouter.ai/v1/...。
刚接触这个模型？阅读 执行模式 了解每个姿态机制上做什么，以及 Secure Agents 基线 了解每个 自治级别设置什么。本页是那个顺序——你翻动开关的次序。

​
1. 三步走的 AI 安全 rollout

整个 rollout 以三步用自治换取安全，每一步在下一步之前对照实时 流量验证：

Observe

允许一切，记录一切。未覆盖的工具调用落入 Discovered Tools；防护栏 flag 规则记录匹配而不改变流量。你了解你智能体的真实形态。

Shadow

一条真实策略评估每一次调用，但每个执行性判定都被降级为 audit 并 记录为 [shadow] would …。你准确看到什么会拦截——而没有任何东西 实际被拦截。

Enforce

Shadow 关闭。deny 拦截、mask 脱敏、pending_approval 挂起。自治 从宽（balanced）走向紧（tight），而你的智能体受到治理。
纪律就是要点：你绝不执行一条你没有先在 shadow 中对照你自己的流量 观察过它触发的规则。

​
2. 第一步——observe（自治 = permissive）

从能多宽就多宽开始。从 Firewall → Posture（Developer+）应用 permissive 自治级别——或 POST /api/workspace/firewall/autonomy。 它启用工作区 observe mode 并不留任何执行策略，因此每一次调用都被 允许，而每一次未覆盖的调用都被记录为一个覆盖缺口。 
# Console: Firewall → Posture → apply "permissive"
# or, via the REST API on your session token:
curl https://api.orcarouter.ai/api/workspace/firewall/autonomy \
  -H "Authorization: Bearer <your console access token>" \
  -H "X-Workspace-Id: <workspace>" \
  -H "Content-Type: application/json" \
  -d '{"level": "permissive"}'
/api/workspace/firewall/* 路由运行在你的控制台会话 / 访问令牌上， 而不在一个中继 sk-orca-... 密钥上。应用一个自治级别是一次工作区写入 ——Developer+。只有 /v1/* 模型调用使用中继密钥。
现在把真实流量指向它并让它运行。观察两个信息流：
  • Firewall → Discovered Tools（Member）——你的智能体调用的每一个 工具，标记 covered 或 gap。这是你规则的输入：你即将为实际 发生的流量编写策略，而不是假设。
  • Guardrails → Matches（Member）——如果你加了任何 flag 动作的规则， 它们记录的每一次匹配，而不触及请求。
让它运行直到 Discovered Tools 不再呈现新工具。那个稳定的列表就是你的 规则编写规格。

​
3. 第二步——shadow（一条真实策略，零拦截）

现在编写你实际想要的策略——工具 glob、参数子句、egress 列表、一个 cap_cost 上限——并在你附加它之前打开 shadow_mode。（从 防火墙规则 构建规则；完整的策略模型在 防火墙参考 中。） 
{
  "name": "prod-rollout",
  "enabled": true,
  "shadow_mode": true,
  "default_verdict": "audit",
  "rules": [
    { "priority": 10, "tool_name_glob": "shell.exec", "verdict": "deny" },
    { "priority": 20, "tool_name_glob": "*",          "verdict": "cap_cost", "cap_cost_cents": 1000 }
  ]
}
在 shadow_mode: true 时，那个 deny 和那个 cap_cost 都在评估时被 降级为 audit——引擎计算真实判定、记录它并前缀 [shadow] would …， 并放行那次调用。把策略附加到你正在上线的密钥（在密钥上设置 firewall_policy_id）或把它设为工作区默认值。 然后读取 Firewall → Events / Runs（Developer+），过滤到 [shadow] 前缀，并确认两侧：
每一次 shell.exec 调用显示 [shadow] would deny。每一次越过你 上限的运行显示 [shadow] would cap_cost。策略看到了你为它构建的 流量。
没有合法工具带一个本会拦截的判定出现。这是误报检查——shadow 存在的 原因。如果一个你需要的工具被标记，修复规则并在你执行之前重新观察。
防护栏没有策略级别的 shadow。等价物是按规则的 flag 动作：它在 Matches 信息流中记录一次匹配且什么都不改变，因此你能在把一条内容规则 切换到 block 或 mask 之前衡量它。在这同一步中把你的防护栏规则作为 flag 运行。

​
4. 第三步——enforce（自治先 balanced，然后 tight）

当 shadow 日志看起来对了，分两个阶段执行，而不是一个。不要直接跳到 默认拒绝。 首先，balanced。 这是推荐的第一个执行姿态：防火墙默认判定是 audit，但最具破坏性的动作（如破坏性 shell）被拒绝，而 PII Shield 防护栏以仅审计运行——它flag PII 而暂不掩码。你现在拦截最糟糕的 东西，同时仍观察其余的。 在同一动作中把你自己策略上的 shadow_mode 关闭，这样它的 deny / cap_cost 判定与基线一起上线。 
curl https://api.orcarouter.ai/api/workspace/firewall/autonomy \
  -H "Authorization: Bearer <your console access token>" \
  -H "X-Workspace-Id: <workspace>" \
  -H "Content-Type: application/json" \
  -d '{"level": "balanced"}'
观察 Events 一小时。真实的拦截现在不带 [shadow] 前缀地出现。一个被 拒绝的工具调用返回 HTTP 400 firewall_blocked；它是 skip-retry 且不消耗模型 token。 然后，tight。 一旦 balanced 安静下来，就走向默认拒绝。tight 级别默认拒绝、拒绝破坏性 shell 以及 SSRF egress，并执行 PII Shield + Secrets Blocker——PII 在模型看到请求之前被掩码，而你 请求中的密钥被拦截。一个被拦截的提示返回 HTTP 400 guardrail_blocked，消耗无配额，并且是 skip-retry。
阶段防火墙（动作）防护栏（文本）你在证明什么
permissiveObserve；什么都不拦截仅 flag真实流量形态
balanced默认 audit；破坏性 shell 被拒绝PII 被 flag最坏情形被阻止
tight默认拒绝；shell + fetch 形态工具（SSRF）被拒绝PII 被掩码，secrets 被拦截完整零信任
PII 的流式注意事项。 在 tight 下，PII Shield 在模型看到请求之前 在请求上掩码 PII——那是实时的。对一个流式响应的输出侧掩码尚未 上线；一个输出 block 在流式上执行（扫描器切断流）。如果你依赖脱敏 模型输出，先在防护栏 Test 标签页中验证你的 stage/stream 组合。参见 防护栏。

​
5. 逃生舱——一键撤销

每次自治变更都是一个单一事务，它快照你先前的姿态，因此你可以从 Firewall → Posture（或 POST /api/workspace/firewall/autonomy/undo/:audit_id）直接回滚。你也可以 随时重新应用一个更软的级别——把 tight 降回 balanced，或把 balanced 降回 permissive。
撤销从最近一次应用的审计快照恢复。如果你自你正在撤销的那次应用以来 做过手动策略编辑，那个快照就不再是最新的未使用快照，于是撤销会拒绝， 而不是静默地把那些编辑回滚掉。当那种情况发生时，改为重新应用一个更软的 级别——它总是可用。

​
6. 每一步的判定来自哪里

这个 rollout 从不拦截你没有要求的东西，因为每个姿态都映射到一个明确、 可观测的机制：
姿态机制结果
Observe工作区 firewall_observe_mode 开 + 防护栏 flag允许 + 记录缺口 / 匹配
Shadow按策略的 shadow_mode计算真实判定，降级为 audit，记录 [shadow] would …
Enforceshadow_mode 关 + tight/balanced 自治deny / mask / cap_cost 上线
四个术语——observe mode、audit 判定、flag 动作和 shadow_mode——是 不同的开关，在 执行模式 中 并排记录。

​
7. 下一步

执行模式

observe、shadow 和 enforce 背后的机制图。

Secure Agents 基线

每个自治级别设置什么，以及如何先模拟它。

驯服一个自治智能体

你执行之后的下一步：成本上限、异常检测和审批。

智能体防火墙

策略、规则、判定、shadow mode，以及完整的 MCP 网关。
一次你可以信任的上线是一个 rollout，而不是一个开关。观察你的智能体做 什么、对照它的真实流量对策略做 shadow，然后执行——balanced 先于 tight ——而每一条规则在它曾经拦截生产之前都已在生产上被验证。