跳轉到主要內容
你連接了一個 MCP 伺服器，而現在你想讓閘道在一次工具呼叫 抵達真正伺服器之前把一個外洩的密鑰剝除——並阻止 那個工具回傳的任何內容把一個憑證（或一個注入 酬載）夾帶回模型。那是兩件不同的工作，由兩個 不同的控制處理，而誠實的版本很重要：如果你假設一個旋鈕 涵蓋兩者，你會出貨一個缺口。 本頁是 OrcaRouter 上淨化 mcp 輸出的聚焦指南—— 防火牆 sanitize 裁決實際隱去什麼、它不隱去什麼， 以及哪個控制治理一個工具回傳的內容。
sanitize 裁決隱去工具呼叫的引數，永不隱去一個 工具回傳的結果。 它改寫你的代理送入一個工具的內容。要治理 一個工具送回的內容，你使用一個在模型回覆上的 output 階段 防護欄——請見 §3。

​
1. 「sanitize」在 mcp 表面上意味著什麼

當一個代理透過 MCP 閘道呼叫一個工具時， 每一次 tools/call 在派發前都會在 mcp 表面上被評估。一條 匹配的規則可以攜帶可撰寫的防火牆裁決 之一——allow、audit、deny、sanitize、pending_approval 或 cap_cost。sanitize 裁決是那個會隱去的：
  • 它在該呼叫的引數（模型傳入工具的 JSON）上執行一組 密鑰形狀偵測器。
  • 每一個匹配都被替換為一個像 [redacted:openai_key] 的正規 權杖，而改寫後的引數就是被轉送到伺服器的內容。
  • 該工具仍然執行——sanitize 是一個非封鎖、放行的裁決。 代理不崩潰；它只是永不把原始密鑰交給該工具。
內建偵測器涵蓋眾所周知的密鑰形狀（AWS access key、 sk- 形式的 API key、Bearer token、US SSN、Luhn 有效的卡號、 email），而一條規則可以加上自訂的 regex，其匹配會呈現為 [redacted:custom]。
在 inbound 表面上——一個請求宣告的所公告 tools[]， 在任何工具被呼叫之前——沒有呼叫時的引數可隱去，所以 那裡的一個 sanitize 裁決會 fail closed 並升級為 deny。Sanitize 只在有一個即時引數酬載可改寫的地方才有意義： mcp 與 response 表面。

​
2. 一條具體規則

假設你想讓任何引數含有一個 OpenAI 形式金鑰的工具呼叫被 轉送時把該金鑰清除掉，而非被封鎖。在 mcp 表面上撰寫一條 帶有 sanitize 裁決、設定為偵測那個密鑰形狀的規則。從 主控台做這件事（Firewall → policy → rules）；寫入需要 Developer+。 該規則，概念上：
欄位值
表面mcp
tool_name_glob*（或限定到一個伺服器，例如 github.*）
裁決sanitize
Sanitize presets要啟用的密鑰偵測器
在呼叫時，一個像這樣的引數酬載： 
{ "note": "use key sk-AAAABBBBCCCCDDDDEEEEFFFFGGGGHHHH for the upstream" }
會被轉送到伺服器為： 
{ "note": "use key [redacted:openai_key] for the upstream" }
該呼叫成功；密鑰永不抵達伺服器。防火牆事件 會記錄 sanitize 裁決、表面與匹配的規則。
當一個工具合法地需要一個引數的大部分，但偶爾有一個 密鑰在自由文字中順帶而來時，伸手去拿 sanitize。當整個呼叫都 危險時，改用 deny（或 pending_approval）——請見 允許清單 MCP 工具。

​
3. 工具結果不可信——在模型回覆上治理它們

這是大多數「淨化輸出」設定弄錯的部分。sanitize 裁決只觸及引數。一個工具的結果——一個 MCP 伺服器 交回的文字或 JSON——永不會被一個防火牆裁決改寫。 OrcaRouter 把工具結果內容視為對模型的不可信輸入。 一個被入侵或下毒的 MCP 伺服器可以回傳一個密鑰、一筆 PII 記錄，或一個 偽裝成資料的提示注入酬載。針對那個內容的控制是 一個在 output 階段——模型的回覆，在模型納入工具結果之後 評估——上的防護欄。
附加一個帶有 Secrets & API-Key Blocker 預設（類別 secrets）的防護欄。它會封鎖 AWS / OpenAI / GitHub 形式的憑證； 把它與 Private Keys & Cloud Tokens 搭配以涵蓋 PEM 金鑰、Slack/Stripe token、Google 金鑰與 JWT。一個 output 階段的封鎖會回傳 guardrail_blocked（HTTP 400）並退還該請求的配額。
PII Shield 預設會遮罩已分類的實體——[EMAIL]、[SSN]、 [CREDIT_CARD]、…——把匹配的值呈現為標籤。Input 階段的 遮罩在每一個請求上都即時運作（無論串流與否）：它會在模型看見之前 遮罩請求。Output 階段的遮罩只在非串流回應上改寫 模型回覆；串流回覆的帶內改寫在規劃中，所以一條 遮罩規則尚未隱去一個串流回覆。
一個下毒的結果可以攜帶「忽略先前指令」形式的文字。 Prompt-Injection Basics 安全預設（關鍵字/regex）加上一條 為注入意圖評分的 llm_judge 規則是這裡的控制。 請見 MCP 工具下毒與 提示注入。
Output 強制執行與串流。 Output 階段的封鎖在 串流與非串流回覆上都強制執行——在一個串流上，一個封鎖在它 匹配時切斷串流並發出一個通用的封鎖通知。Output 階段的 遮罩只套用於非串流回覆；串流回覆的帶內改寫 在規劃中，所以一條遮罩規則尚未隱去一個串流回覆。

​
4. 每個控制位於何處

兩個表面的精簡地圖，讓你把正確的旋鈕接到正確的 風險：
你想治理…控制位於何處
一次工具呼叫的引數中的密鑰防火牆 sanitize 裁決（mcp 表面）防火牆規則
一個工具的結果中的密鑰 / PII / 注入output 階段上的防護欄防護欄
不要試圖讓 sanitize 涵蓋工具結果——它看不見它們。而且 不要假設一個 input 階段的防護欄會抓住一個工具在對話中途 回傳的內容；工具結果內容在模型的回覆上治理， 那是 output 階段。

​
5. 附加與觀察

兩個控制都是工作區限定、具名且有序的，且兩者都以 同樣的兩種方式附加：
  • 每金鑰——在代理使用的金鑰上設定 firewall_policy_id（給 sanitize 規則）與 guardrail_id（給 output 政策）。
  • 工作區預設——把一個政策／防護欄標記為工作區預設， 讓每個金鑰繼承它。
從主控台用你的工作階段／存取權杖設定這一切 （管理路由使用 UserAuth，而非轉送金鑰）。防火牆寫入 需要 Developer+；防護欄寫入需要 Developer+。 一旦上線，sanitize 匹配會顯示為防火牆事件（裁決、表面、 匹配的規則），而防護欄匹配會顯示在防護欄匹配動態中。 兩者有不同的讀取門檻：防火牆事件動態需要 Developer+，而防護欄匹配動態任何工作區成員皆可讀取。預設 情況下，一個匹配會記錄它的類型、動作與階段，但不記錄 原始匹配內容；只在你需要該子字串以供分流時才打開記錄原始內容。

​
6. 下一步去哪裡

允許清單 MCP 工具

預設拒絕一個伺服器，只允許你審查過的工具。

防火牆規則

完整的規則 DSL——裁決、globs、args-match、sanitize 設定。

防護欄

內容政策、預設、PII 實體與 output 階段強制執行。

MCP 工具下毒

一開始就使工具結果不可信的威脅。
初次接觸這兩層之間的分工？閱讀 防護欄 vs. 防火牆，然後是 資料外洩以了解 sanitize 與 output 防護欄一起封堵的洩漏路徑。