跳轉到主要內容
你有一條想放到生產環境之前的政策。恐懼不是 那條政策——而是把它翻開並發現它封鎖了一個你代理 實際需要的工具，或遮罩了一個你應用依賴的欄位。修正之道不是 在一個沙盒中做更多測試；而是在一個無法弄壞任何東西的姿態中，對照真實流量 推出，然後只在你看到什麼觸發之後才收緊。 本配方就是那次推出：observe → shadow → enforce，自主 balanced 先於 tight。你全程待在主控台（或 REST API）中 ；代理像以前一樣持續呼叫 https://api.orcarouter.ai/v1/...。
對這個模型陌生？閱讀強制執行模式 以了解每個姿態在機制上做什麼，以及 Secure Agents 基準以了解 每個自主等級設定什麼。本頁是那個序列——你翻動開關的順序。

​
1. AI 安全推出的三個招式

整個推出以三步用自主換取安全，每一步 在下一步之前都對照即時流量驗證：

觀察（Observe）

允許一切、記錄一切。未涵蓋的工具呼叫落入 Discovered Tools；防護欄 flag 規則記錄 match 而不 改變流量。你學到你代理真實的形狀。

影子（Shadow）

一條真實的政策評估每個呼叫，但每個強制執行的裁決都被 降級為 audit 並記錄 [shadow] would …。你確切看到 本來會封鎖什麼——而沒有任何東西真的被封鎖。

強制執行（Enforce）

影子關閉。deny 封鎖、mask 遮蔽、pending_approval 保留。 自主從寬（balanced）走向緊（tight），而你的 代理受治理。
紀律就是重點：你絕不強制執行一條你沒有先在影子中 對照你自己的流量觀察觸發過的規則。

​
2. 招式一——觀察（autonomy = permissive）

從它能達到的最寬開始。從 Firewall → Posture（Developer+）套用 permissive 自主等級——或 POST /api/workspace/firewall/autonomy。它啟用工作區觀察 模式並不留下任何強制執行的政策，所以每個呼叫都被允許，而每個 未涵蓋的呼叫都被記錄為一個涵蓋缺口。 
# 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 動作 規則，它們記錄的每個 match，而不觸及請求。
讓它運行，直到 Discovered Tools 停止浮現新工具。那個穩定的 清單就是你的規則撰寫規格。

​
3. 招式二——影子（一條真實政策，零封鎖）

現在撰寫你實際想要的政策——工具 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。每個跨越 你上限的 run 顯示 [shadow] would cap_cost。政策看見 你為它建構的流量。
沒有合法工具帶著一個本來會封鎖的裁決出現。這是 誤判檢查——影子存在的原因。如果一個你需要的工具被 標記了，修正規則並重新觀察，再強制執行。
防護欄沒有政策層級的影子。等價物是逐規則的 flag 動作：它在 Matches 動態中記錄一個 match 並 什麼都不改變，這樣你就能在把一條內容規則切換到 block 或 mask 之前衡量它。透過這同一個招式，把你的防護欄規則作為 flag 運行。

​
4. 招式三——強制執行（autonomy balanced，然後 tight）

當影子日誌看起來正確時，分兩個階段強制執行，而非一個。別 直接跳到預設拒絕。 首先，balanced。 這是建議的第一個強制執行姿態： 防火牆預設裁決是 audit，但最具破壞性的動作 （如破壞性 shell）被拒絕，而 PII Shield 防護欄 以僅 audit運行——它標記 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 且不消耗模型權杖。 然後，tight。 一旦 balanced 安靜下來，走向預設拒絕。 tight 等級預設拒絕、拒絕破壞性 shell 與 SSRF egress，並強制執行 PII Shield + Secrets Blocker——PII 在 模型看見請求之前在請求上被遮罩，而你請求中的密鑰被 封鎖。一個被封鎖的提示回傳 HTTP 400 guardrail_blocked，消耗 零配額，並且是 skip-retry。
階段防火牆（動作）防護欄（文字）你在證明什麼
permissive觀察；沒有東西被封鎖僅 flag真實流量形狀
balanced預設 audit；破壞性 shell 被拒絕PII 被標記最壞情況被阻止
tight預設拒絕；shell + 擷取形狀的工具（SSRF）被拒絕PII 被遮罩、密鑰被封鎖完整的零信任
PII 的串流注意事項。 在 tight 下，PII Shield 在模型 看見之前於請求上遮罩 PII——那是即時的。一個串流回應的 輸出側遮罩尚未即時；一個輸出 block 在串流上會被 強制執行（掃描器切斷串流）。如果你依賴遮蔽 模型輸出，先在防護欄 Test 分頁中驗證你的 階段/串流組合。參見 防護欄。

​
5. 逃生艙——一鍵還原

每次自主變更都是一次快照你先前姿態的單一交易， 所以你可以從 Firewall → Posture（或 POST /api/workspace/firewall/autonomy/undo/:audit_id）直接滾回。你也可以單純地 重新套用一個更軟的等級——把 tight 降回 balanced，或把 balanced 降回 permissive——隨時。
還原會從你正在還原的那次套用的最近一次套用的稽核 快照還原。如果你在你正在還原的那次套用之後做了手動政策編輯，那個快照就不再是最近的未使用快照，而還原會 拒絕，而不是靜默地把那些編輯滾走。當那發生時， 改為重新套用一個更軟的等級——它總是可用的。

​
6. 每個招式的裁決從哪裡來

推出絕不封鎖一個你沒要求的東西，因為每個姿態都 映射到一個明確、可觀測的機制：
姿態機制結果
Observe工作區 firewall_observe_mode 開 + 防護欄 flagAllow + 記錄缺口 / match
Shadow逐政策 shadow_mode計算真實裁決、降級為 audit、記錄 [shadow] would …
Enforceshadow_mode 關 + tight/balanced 自主deny / mask / cap_cost 上線
這四個術語——觀察模式、audit 裁決、flag 動作，以及 shadow_mode——是不同的開關，在 強制執行模式中並排記錄。

​
7. 下一步

強制執行模式

觀察、影子與強制執行背後的機制圖。

Secure Agents 基準

每個自主等級設定什麼，以及如何先模擬它。

馴服一個自主代理

你強制執行之後的下一步：成本上限、異常偵測，以及 審批。

代理防火牆

完整的政策、規則、裁決、影子模式，以及 MCP 閘道。
一次你可以信任的上線是一次推出，而非一個開關。觀察你代理 做什麼、對照它真實的流量影子化政策，然後強制執行——balanced 先於 tight——而每條規則都在它曾封鎖之前就在生產環境上被驗證。