跳轉到主要內容
當你需要遮罩一個 LLM 提示攜帶的敏感資料——電子郵件、卡號、國民身分證、密鑰——時，閘道會在模型看到之前就地改寫每個匹配項。一個被遮罩的值會變成一個具型別標籤（jane@acme.com → [EMAIL]），所以模型仍能讀到一個連貫的提示，而原始值永遠不會離開你的工作區。 本頁聚焦於遮罩渲染什麼、如何改變標籤，以及如何在單一規則上遮罩某些實體並封鎖其他實體。完整引擎——每種規則類型、階段與路由——請見 防護欄參考，而專門針對請求的遮罩請見 輸入階段規則。

​
1. 用具型別標籤遮罩 LLM 提示攜帶的敏感資料

一條帶有 mask 動作的 pii 規則會偵測一個實體，並把每個匹配項替換為一個具型別隱碼標籤——一個方括號中的大寫標籤，指名什麼被移除而不洩露值：
實體渲染後的標籤
email[EMAIL]
credit_card[CREDIT_CARD]
ssn[SSN]
完整的內建偵測器集合——email、phone、credit_card、ssn、ip、iban、mac_address、jwt、aws_access_key、api_key_openai、bitcoin_address，外加區域性的 jp_mynumber、kr_rrn 和 cn_resident_id——各自渲染它自己的方括號標籤（[PHONE]、[IBAN]、[JP_MYNUMBER] 等等）。標籤是確定性的：同一個實體永遠渲染相同的標籤，所以下游提示保持穩定，你的日誌讀起來乾淨。
就模型品質而言，具型別標籤勝過一概而論的 [REDACTED]。模型仍然知道它看的是一個電子郵件對帳號對電話號碼，所以它能繼續推理資料的形狀——「回覆 [EMAIL]」仍是一條可執行的指令——而永遠不持有真實值。
輸入遮罩完全上線——閘道會在提示抵達模型之前改寫它，無論串流與否。輸出遮罩在非串流回應上也已上線：輸出階段的一條 mask 規則會在完成內容回傳之前改寫它。只有串流輸出遮罩仍在規劃中；在一個串流回覆上，在輸出階段優先使用 block。確切的階段／串流矩陣請見 串流覆蓋。

​
2. 一個具體範例

在主控台中你自己的工作階段下撰寫規則——防護欄設定需要 Developer+，而不是中繼金鑰。在一個名為 pii-shield 的防護欄中新增一條 pii 規則： 
{
  "type": "pii",
  "stage": "input",
  "action": "mask",
  "entities": ["email", "phone", "ssn"]
}
把它綁定到一把金鑰（設定 guardrail_id，或將它標記為工作區預設值——參見 綁定到金鑰），然後用那把 sk-orca-... 中繼金鑰呼叫閘道： 
curl https://api.orcarouter.ai/v1/chat/completions \
  -H "Authorization: Bearer sk-orca-..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-4o-mini",
    "messages": [
      {"role": "user", "content": "Reply to jane@acme.com about her SSN 123-45-6789"}
    ]
  }'
閘道會在轉送前把提示改寫為 “Reply to [EMAIL] about her SSN [SSN]”。上游模型永遠看不到地址或號碼。先在編輯器的 Test 分頁中證明確切的渲染（無上游呼叫，不消耗配額）——參見 測試與評測。

​
3. 用 mask_with 覆寫標籤

內建實體渲染一個固定標籤。自訂實體——你自己疊加於內建集合之上的正規表示式偵測器——讓你用 mask_with 自己設定替換文字： 
{
  "type": "pii",
  "stage": "input",
  "action": "mask",
  "custom_entities": [
    {
      "name": "employee_id",
      "pattern": "EMP-[0-9]{6}",
      "mask_with": "[STAFF_ID]"
    }
  ]
}
mask_with 是那個實體匹配項的逐字替換字串。EMP-004217 變成 [STAFF_ID]。讓它留空，匹配項就會渲染預設標籤 [<UPPERCASE_NAME>]——這裡是 [EMPLOYEE_ID]——所以一個自訂偵測器即使沒有覆寫也永遠產生一個可讀的、具型別的隱碼。
name（小寫 ASCII ／數字／底線，必須以字母開頭）、pattern（一個 Go RE2 正規表示式——線性時間、無回溯參照）、可選的 checksum（luhn 驗證卡號形狀的數字），以及可選的 mask_with。每條規則最多 25 個自訂實體——每個都是對全文的一次掃描，所以這個上限讓熱路徑保持線性。參見 自訂 PII 實體。
一個 name 會以不加引號的形式流入稽核日誌與 Matches 動態，所以讓它保持為以字母開頭的小寫 ASCII 字母、數字與底線（例如 employee_id、internal_ticket）。驗證器會拒絕其他任何內容。

​
4. 遮罩某些實體、封鎖其他實體——entity_actions

單一 pii 規則可透過 entity_actions 對不同實體套用不同動作，而不必堆疊三條重疊的規則。經典形狀：遮罩低敏感度的聯絡資料，但直接封鎖高敏感度欄位。 
{
  "type": "pii",
  "stage": "input",
  "action": "mask",
  "entities": ["email", "phone", "ip", "credit_card", "ssn"],
  "entity_actions": {
    "credit_card": "block",
    "ssn": "block"
  }
}
這裡 email、phone 和 ip 遵循規則頂層的 mask 並渲染 [EMAIL] / [PHONE] / [IP]；而一個 credit_card 或 ssn 匹配則改為以 HTTP 400 guardrail_blocked 封鎖整個請求。
欄位規則
鍵必須是規則上已宣告的一個實體（內建或自訂）。
值block、mask、flag 或 annotate。
一個被封鎖的請求不消耗配額——輸入階段封鎖在計量之前觸發。一個被遮罩的請求會以淨化後的文字通過。所以一條規則可以安靜地遮罩例行欄位並硬性停止受監管的欄位，只需一次綁定且無需修改應用程式。

​
5. Mask 對 block 對 flag

遮罩是一條規則（或每實體覆寫）可以採取的動作之一。依你想擾動流量的程度來選擇：

mask

把匹配項遮罩為一個具型別標籤，並以淨化後的文字讓請求通過。模型永遠看不到原始值。

block

以 HTTP 400 guardrail_blocked 拒絕整個請求。沒有東西抵達模型。用於絕不能傳輸的資料。

flag

不改變流量的任何部分——只記錄一個匹配。在強制執行前衡量一條規則會多常觸發。
一個好的推出是 flag → mask → block：以 flag 衡量影響，在你信任偵測器後 mask，並把 block 保留給你完全不能放行的欄位。參見 動作 和 調校誤報。

​
6. 驗證什麼被遮罩了

每條觸發的規則都會在工作區 匹配動態 中記錄一個 match——規則類型、動作、階段，以及一個詳情字串。匹配到的子字串本身（原始電子郵件、實際卡號）只在 Log raw content 開啟時才會記錄，而它預設為關閉——隱私保守姿態，因為整個重點就是讓原始值不進入你的日誌。
只在你真正需要子字串進行分流時才開啟 Log raw content，且只逐個防護欄開啟。在它關閉時，動態證明一個 [CREDIT_CARD] 被遮罩了而從不儲存號碼。該切換不可追溯生效。參見 日誌與隱私。

​
7. 下一步去哪裡

  • PII Shield 預設——你可以一鍵套用的單規則、遮罩一切的起點。
  • 自訂 PII 實體——用 mask_with 和可選的 luhn 撰寫你自己的正規表示式偵測器。
  • 輸入階段規則——遮罩今天即時執行的地方，在模型之前、計量之前。
  • 封鎖密鑰——對於憑證，封鎖（而非遮罩）才是正確的選擇。
  • 串流覆蓋——今天哪些階段／串流組合是遮罩對封鎖。
閱讀 防護欄參考 以了解完整引擎，或閱讀 PII 暴露 和 密鑰洩漏，以了解遮罩旨在遏制的威脅。