1. 三種姿態一覽
| 姿態 | 流量發生什麼 | 機制 | 何時使用 |
|---|---|---|---|
| 觀察 | 所有流量被允許;沒有政策的呼叫被記錄為覆蓋缺口 | 工作區層級的觀察模式開啟;防護欄規則使用 flag 動作;防火牆 default_verdict 是 audit | 基準探索——在你撰寫任何規則之前了解你的代理實際做什麼 |
| 影子 | 流量被允許;政策評估,假設性的封鎖被記錄為 [shadow] would … | 防火牆政策上的每政策 shadow_mode 旗標 | 安全的預生產驗證——在政策觸及流量之前確認它正確觸發 |
| 強制執行 | 真實裁決適用——deny 封鎖、sanitize 遮罩、pending_approval 保留 | 影子模式關閉;防護欄動作設定為 block / mask;防火牆裁決是即時的 | 在你已在影子中驗證政策後的生產強制執行 |
角色要求。 任何工作區成員都可以讀取政策、設定和已發現工具視圖;
防火牆Events 和 Runs 動態需要 Developer 角色。更改設定、
政策動作或
shadow_mode 也需要 Developer 或更高角色。2. 觀察姿態——在規則化之前衡量
觀察姿態不是一個單一開關。它是三個獨立機制的組合, 共同產生「允許一切,記錄一切」:防火牆觀察模式(工作區設定)
當一次工具呼叫解析到完全沒有政策——沒有金鑰附加且沒有工作區預設值——時, 防火牆的工作區層級觀察模式決定發生什麼:- 觀察模式開啟: 呼叫被允許並記錄為覆蓋缺口。 Discovered Tools 視圖從這些缺口事件中填充,精確顯示你的代理 在沒有任何規則覆蓋它們的情況下執行哪些工具。
- 觀察模式關閉: 呼叫被靜默允許——與從未啟用此功能的工作區位元組完全一致。
防火牆 audit 裁決(每政策預設值)
當政策確實解析但沒有規則匹配工具呼叫時,政策的 default_verdict 適用。
default_verdict 的預設值是 audit——允許呼叫並記錄以供審查。
沒有規則且沒有設定更改的新政策不封鎖任何東西且不靜默允許任何東西:它稽核它看見的一切。
audit 也是一個正常的規則裁決。匹配並產生 audit 的規則讓呼叫通過並記錄它——
這是防護欄稽核模式在防火牆中的對應物。
防護欄 flag 動作(每規則動作)
在防護欄方面,flag 動作是觀察等效:規則觸發,一個匹配項被記錄在 Matches 動態中,
請求繼續不受影響。沒有封鎖。沒有遮罩。在你想衡量一個規則時使用 flag——
看看它多頻繁觸發以及在什麼上——在承諾 block 或 mask 之前。
這三者共同產生觀察姿態:觀察模式捕捉未覆蓋的工具呼叫;
audit 裁決
涵蓋政策下但尚未在特定規則下的工具呼叫;flag 動作涵蓋你還沒準備好
強制執行的防護欄檢查。
3. 影子姿態——在強制執行之前驗證
影子模式是防火牆政策上的每政策旗標(shadow_mode: true)。當它開啟時:
- 政策完全按照生產中的方式評估每次工具呼叫——規則被匹配、裁決被計算、引數謂詞被測試。
- 每個強制執行裁決(
deny、sanitize、pending_approval)在到達工具之前被降級為audit。 - 記錄的原因帶有
[shadow] would …前綴,這樣你可以在事件動態中精確看到什麼本來會被封鎖、 淨化或保留。
防護欄在政策層級沒有
shadow_mode 等效物——使用每規則的 flag 動作
來觀察個別防護欄檢查,然後再切換到 block 或 mask。4. 強制執行姿態——真實裁決,真實後果
在強制執行姿態中,沒有任何東西被降級:- 防火牆
deny→ 代理看到工具錯誤(MCP)或 HTTP 400firewall_blocked(inbound 表面)。 錯誤命名工具和原因。標記為 skip-retry。 - 防火牆
sanitize→ 匹配到的子字串從工具引數中被遮罩,清理後的呼叫被轉發。 - 防火牆
pending_approval→ 呼叫被保留;代理接收 HTTP 400firewall_approval_pending和一個輪詢的審批 id。 - 防護欄
block→ HTTP 400guardrail_blocked,命名觸發的防護欄和規則。不消耗配額。 - 防護欄
mask→ 匹配項被遮罩(例如jane@acme.com→[EMAIL]),請求以淨化後的文字繼續。
shadow_mode,並將防護欄規則動作
從 flag 更改為 block 或 mask(視情況而定)。
5. 建議的推出流程
觀察——探索你的代理做什麼
開啟工作區觀察模式(
PUT /api/workspace/firewall/settings,
firewall_observe_mode: true)。讓防火牆沒有政策(或一個 default_verdict 為 audit 的政策)。
為你想衡量的任何防護欄規則添加 flag 動作。觀察Discovered Tools 視圖,其中填充了你的代理發出的每次工具呼叫,
標記為covered(有規則套用)或 gap(沒有任何規則套用)。
使用這個作為撰寫你的第一個政策規則的輸入——你是在為真實流量撰寫規則,
而不是假設的流量。讓它執行,直到 Discovered Tools 視圖穩定下來,你有足夠的資料撰寫有意圖的規則。影子——在強制執行之前驗證
使用
shadow_mode: true 撰寫防火牆政策。將它附加到你想治理的金鑰
(或將其設定為工作區預設值)。對於防護欄,在此階段保持規則動作為 flag。政策現在評估每次真實工具呼叫並記錄它會做什麼。開啟Events 和 Runs 視圖
並按 [shadow] 前綴過濾。確認:- 它在你打算的工具和引數模式上觸發。
- 它沒有在你想要允許的任何東西上觸發(誤報)。
6. 自主等級——一次性設定所有這些
逐規則調整政策是精確的路徑。自主等級是快速的路徑——一個控制項 在一次交易中原子性地設定你工作區的防火牆和防護欄姿態,並支援一鍵還原:| 等級 | 產生的姿態 |
|---|---|
permissive | 觀察姿態:沒有強制執行政策,沒有防護欄,工作區觀察模式開啟——你看見一切,沒有任何東西被封鎖。映射到上面的觀察步驟。 |
balanced | 預設裁決 audit,但破壞性 shell 被拒絕;PII Shield 在純稽核模式下執行(標記 PII);觀察模式關閉。一旦你知道你的流量形態,推薦的起始姿態。 |
tight | 完整強制執行:預設拒絕,破壞性 shell 和 SSRF 外向請求被拒絕;PII Shield + Secrets Blocker 防護欄強制執行(篩查你的請求中的 PII 和密鑰);觀察模式關閉。 |
POST /api/workspace/firewall/autonomy 套用(Developer+)。
Simulate 端點(GET /api/workspace/firewall/simulate?level=)
在你套用之前預覽等級更改會做什麼。
自主等級是上述相同機制的便利層——它們設定
default_verdict、
觀察模式、防火牆規則和防護欄規則動作。它們不切換 shadow_mode;
那仍然是一個手動的每政策控制。你總是可以在套用等級後覆蓋個別設定。7. 機制映射——哪個設定做什麼
這個表格是權威參考。這四個術語是不同的——不要混淆它們:| 術語 | 類型 | 它控制什麼 |
|---|---|---|
| 觀察模式 | 工作區設定 | 當工具呼叫解析到沒有政策時的行為。開啟 → 記錄為缺口(Discovered Tools)。關閉 → 靜默允許。 |
audit 裁決 | 政策 / 規則裁決 | 對政策下的工具呼叫的行為,該呼叫匹配(或回退到預設值)。允許 + 記錄。預設的 default_verdict。 |
flag 動作 | 防護欄規則動作 | 防護欄檢查允許流量並記錄匹配項。防護欄的不強制執行而觀察動作。 |
shadow_mode | 每防火牆政策旗標 | 將所有強制執行裁決(deny/sanitize/pending_approval)降級為 audit,並在原因前加上 [shadow] would … 前綴。 |
安全代理基準
推薦的起始姿態和零信任代理安全的五分鐘設定。
代理防火牆
政策、規則、裁決、影子模式和 MCP 閘道的完整參考。
