跳轉到主要內容
當一個代理呼叫一個工具時，它傳入的引數與產生它們的提示一樣有 風險——一個丟進 command 欄位的 sk-… 金鑰、一個貼進 body 的 客戶 SSN、一個請求標頭中的內部權杖。防火牆 sanitize 裁決會在 工具呼叫引數中捕捉那些材料，用一個有類型的遮罩權杖替換它，並 轉送清理後的呼叫——所以動作仍會執行，但密鑰永遠不離開閘道。
「淨化工具輸出」指的是呼叫引數，而非工具結果。 人們搜尋 sanitize tool output，期待防火牆擦除一個工具回傳的東西。sanitize 裁決不觸及工具結果——它遮罩你的代理傳入一次工具呼叫的引數。 如果你需要審查一個工具或模型回傳的文字，那是一個 防護欄的輸出介面 工作，而不是一條防火牆 sanitize 規則。
這是防火牆匹配語言中的一個裁決。完整集合參見 裁決與 規則參考;本頁是針對撰寫並推理 sanitize 的聚焦指南。

​
1. Sanitize 做什麼——以及它絕不觸及什麼

一條帶有 verdict: sanitize 的規則會在呼叫被派發之前對工具呼叫 引數執行一個遮罩引擎。每個匹配都被替換為一個典範權杖，而呼叫 帶著清理後的引數進行——工具仍會執行，只是其中沒有原始密鑰。

遮罩

一個模型發出的 tool_call 或一個 MCP tools/call 的 JSON 引數——command、body、headers，任何一個密鑰或 PII 落入的 字串欄位。

絕不遮罩

一個工具回傳的內容、提示、模型的回應文字。Sanitize 是一個 僅限引數的遮罩器。文字審查是一個 防護欄的事。
遮罩器用一個有類型的權杖替換每個匹配：一個預設集匹配變成 [redacted:<preset>]（例如 [redacted:openai_key]），而一個自訂模式 匹配變成 [redacted:custom]。引數的形狀被保留——只有敏感的子字串 改變——所以一個期待有效 JSON 的工具仍收到有效 JSON。

​
2. 內建的偵測器預設集

一條 sanitize 規則指名一個或多個預設集（知名的密鑰／PII 形狀） 以及／或自訂 regex 模式。內建的預設集：
預設集捕捉
aws_access_keyAWS access key id（AKIA… / ASIA… + 16 字元）
aws_secret_key一個 40 字元的 AWS 密鑰（邊界感知）
openai_keysk- + ≥32 字元
anthropic_keysk-ant- + ≥40 字元
bearer_tokenBearer + 一個 ≥16 字元的權杖（保留關鍵字）
email一個電子郵件位址
ssn_us一個 3-2-4 形式的美國 SSN
credit_card一段通過 Luhn 檢查的 13–19 位數字
一條 sanitize 規則必須宣告至少一個預設集或自訂模式——當你儲存 規則時一個空的淨化器會被拒絕。一個 credit_card 匹配會額外經過 Luhn 檢查,所以一個同樣長度但不是有效卡號的數字會被保留不動,而 不是被過度遮罩。

​
3. 一個具體範例

在主控台規則編輯器中撰寫這個。此範例會從你代理發出的任何 http.* 工具呼叫的引數中遮罩一個 OpenAI 金鑰與任何電子郵件,然後轉送 清理後的呼叫： 
{
  "label": "strip secrets from http tool args",
  "stage": "response",
  "tool_name_glob": "http.*",
  "verdict": "sanitize",
  "sanitize_json": "{\"presets\":[\"openai_key\",\"email\"],\"custom\":[]}"
}
如果模型發出一個像這樣的呼叫： 
{ "name": "http.post", "arguments": { "url": "…", "body": "key=sk-AAAA…BBBB user=jo@acme.com" } }
閘道會轉送它,主體被改寫為 key=[redacted:openai_key] user=[redacted:email]——請求仍會執行,而 密鑰與位址永遠不離開閘道。
將該規則固定到 response 介面（模型發出的 tool_calls）或將 介面留空以也涵蓋 mcp 介面。那些是攜帶呼叫時引數的介面,那正是 sanitize 所遮罩的。

​
4. 在 inbound 介面上,sanitize 升級為 deny

inbound 介面評估的是一個代理在 一個請求上公告的工具——工具定義,它們尚不攜帶呼叫時引數。 那裡沒有東西可遮罩,所以 inbound 介面上的一個 sanitize 裁決會 升級為一個 deny（失敗關閉）:該請求會以 firewall_blocked 被 封鎖,而不是未遮罩地轉送。
不要撰寫一條 sanitize 規則,期待它清理一個 inbound 工具公告——它 會封鎖它。如果你想要一個工具定義從請求中消失,使用一個明確的 deny。將 sanitize 保留給 真實引數存在的 response 與 mcp 介面。

​
5. Sanitize vs. 處理一個密鑰的其他方式

三個層次可以對一個代理即將外洩的密鑰採取行動——依什麼與在哪裡 挑選：
從一次工具呼叫的引數中剝除密鑰,並仍然執行該呼叫。當動作 正當但代理在某個欄位中放了某個敏感東西時使用它。僅限引數層。
完全停止該呼叫。當動作本身危險、而不只是一個引數危險時使用 它。這也是 sanitize 在 inbound 介面上所變成的東西。參見 封鎖工具。
Secrets Blocker 與 PII 防護欄 審查一個請求或回應的文字（包括在輸出介面上的模型產生內容）。 那是針對「一個工具或模型回傳什麼」的層次——sanitize 不做的 那件事。
在你強制執行之前測試。 Sanitize 會在 response 與 mcp 介面上 改寫一次即時呼叫的引數。先在 影子模式下撰寫你的 sanitize 規則,並觀察事件動態,以在任何 引數實際被改寫之前確認它們匹配你預期的東西。

​
6. Sanitize 出現在你軌跡的哪裡

像每個裁決一樣,一次 sanitize 評估會被記錄為一個防火牆事件——可在 事件記錄中按裁決、介面、工具 與執行篩選,並在分析中彙整。在 影子模式下,一個 sanitize 裁決（像每個強制執行的裁決一樣）會被降級為 audit,原因會被加上 前綴 [shadow] would …,所以你能在任何引數實際被改寫之前衡量影響。

​
接下來去哪裡

所有裁決

allow、audit、deny、sanitize、pending_approval、cap_cost。

驗證引數

依在它引數中的東西匹配一次呼叫——JSONPath 子句文法。

封鎖工具

當動作本身就是問題時,拒絕整個呼叫。

防火牆 + 防護欄

審查一個工具或模型回傳的文字——sanitize 不涵蓋的那一層。
關於 sanitize 幫助遏制的威脅,參見 資料外洩與 危險的工具呼叫。關於 該裁決背後完整的規則文法,參見 防火牆規則參考。