跳轉到主要內容
你的應用程式傳給模型的任何提示詞，都可能挾帶它不該帶的個人資料—— 貼進客服工單的一個電子郵件、CRM 備註裡的一個 SSN、使用者在聊天框裡 打進去的一個卡號。一旦那段文字抵達上游供應商，它就脫離了你的掌控： 被記錄、被快取，可能還被用於訓練。模型的回應也可能把 PII 漏回來， 複述或推斷出某些細節，而那些細節接著就落入你的應用程式日誌。 本頁說明如何用一個 PII 防護欄在閘道處阻止 llm pii leak—— 這是一條工作區範圍限定的規則，在模型看見請求之前，於請求上遮罩或封鎖 敏感實體。它是 代理防火牆在內容層的對應物， 而且無需更動你的應用程式碼。
PII 防護欄審查提示詞與回應的文字。若要治理代理對資料採取的 動作——擷取工具、egress 主機——請參見 資料外洩。這兩個平面可以 組合；大多數團隊兩者並用。

​
1. 外洩如何發生

PII 透過尋常、善意的流量抵達上游供應商：
  • 一位使用者把自己的聯絡細節貼進聊天，而你的應用程式把整則訊息原封不動 轉送出去。
  • 一條 RAG 管線擷取了一份含有客戶記錄的文件，並把它塞進提示詞作為情境。
  • 一個代理讀取了一筆資料庫列，並把原始欄位放進一個工具引數或一個 後續提示詞中。
  • 模型的回應重述或推斷出 PII，而你的應用程式接著把它寫進自己的日誌。
這些都不是攻擊——它們是 LLM 應用程式的正常樣貌。解法是一條在單一咽喉 要道審查每個請求與回應的政策，而不是稽核你程式碼中的每一個呼叫點。

​
2. 用 PII 防護欄防禦 llm pii leak

防護欄是一個工作區範圍限定、命名的內容 政策。其中的一條 pii 規則會偵測敏感實體，並對每一個匹配套用一個 動作：
動作作用
mask把每個匹配替換成一個帶型別的標籤——jane@acme.com → [EMAIL]——並轉送清理後的文字。模型永遠看不到原始值。
block以 HTTP 400 guardrail_blocked 拒絕整個請求。當 PII 絕對不能抵達供應商時使用。
flag不改變流量；記錄一個匹配。在你強制執行之前先衡量外洩程度。
偵測器集是內建且確定性的——純粹的模式匹配，無網路呼叫，在熱路徑上 安全。內建實體： 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。 在 mask 動作上，每個匹配會呈現為它帶型別的標籤——[EMAIL]、[SSN]、 [CREDIT_CARD] 等等——所以提示詞的結構得以保留，而值已經不見了。
需要一個不在內建之列的偵測器（一個內部員工 ID、一個帳號）？加一個 自訂實體——一條 regex，可選用 Luhn 校驗碼，每條規則最多 25 個—— 就放在內建項旁邊。參見 防護欄參考。

​
3. 具體範例——在請求上遮罩 PII

最快的起點是 PII Shield 預設集：一條 pii 規則，遮罩 email、 phone、ssn、credit_card 與 ip。在主控台中設定它——無需程式碼變更， 這一步也不需要金鑰。
1

建立防護欄

在主控台中，開啟 Guardrails 並按一下 New guardrail。從 pii 類別挑選 PII Shield 預設集，或就上述實體手動撰寫一條動作為 mask 的 pii 規則。儲存。（寫入需要 Developer 角色或更高。）
2

在沙盒中驗證

開啟 Test 分頁，貼上 “reply to jane@acme.com”，挑選 input 介面，然後執行。沙盒會傳回 reply to [EMAIL]——在本地，無上游呼叫、 不消耗配額。
3

把它附加到一個金鑰

在 API Keys 中，編輯一個金鑰並從 Guardrail 下拉選單選取該防護欄， 或把該防護欄設為工作區預設值，這樣每個未附加的金鑰都會繼承它。綁定 存在於閘道中的金鑰上。
4

照常呼叫閘道

使用那個金鑰，你的中繼呼叫不變：
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": "Draft a reply to jane@acme.com"}
    ]
  }'
閘道會在轉送之前把該電子郵件改寫成 [EMAIL]。上游模型永遠不會收到 那個地址。
PII Shield 是一條 both 介面的規則，但今天上線的是即時的請求介面遮罩 ——閘道會在提示詞離開前往模型之前先遮罩它。對即時中繼的輸出介面（回應） 遮罩在路線圖上。若要驗證一條輸出介面規則的行為，請在 Test 分頁中 評估它。關於串流，請參見 §5。

​
4. 大部分遮罩、最糟者封鎖——逐實體覆寫

單一規則可以透過 entity_actions 對不同實體套用不同動作。遮罩低風險 識別碼，但硬封鎖你絕不想轉送的那些實體——用一條規則取代三條重疊的規則： 
{
  "type": "pii",
  "stage": "input",
  "action": "mask",
  "entities": ["email", "phone", "ip", "credit_card", "ssn"],
  "entity_actions": {
    "credit_card": "block",
    "ssn": "block"
  }
}
在這裡，電子郵件、電話與 IP 被遮罩並通過；攜帶卡號或 SSN 的提示詞則改為 以 HTTP 400 guardrail_blocked 拒絕。一個被封鎖的請求不消耗配額 ——一個輸入介面封鎖會在計量之前觸發——並被標記為 skip-retry。每個 entity_actions 鍵必須是規則上宣告過的實體（內建或自訂）；它的動作會 對照規則的動作集進行驗證。

​
5. 串流上今天能用什麼

動作與介面與串流的互動方式各異——在你依賴它之前先弄清楚這張矩陣：
完全即時。提示詞會在上游呼叫之前被審查，所以無論回應是否串流， 遮罩與封鎖的運作完全一致。這就是 PII Shield 今天強制執行的介面。
在串流與非串流回應上都強制執行。在串流上，掃描器會在傳輸中途切斷串流， 並在任何被封鎖內容抵達客戶端之前發出一則替代訊息；一個輸出封鎖會退還 預先消耗的配額。
目前僅限非串流。在一個串流回應上，原始區塊會未經遮罩通過—— 傳輸途中的串流改寫是一項計畫中的增強。今天若要做回應遮罩，請使用 非串流請求，或仰賴輸入介面遮罩。請先在 Test 分頁中驗證你確切的 介面／串流組合。

​
6. 看看捕捉到了什麼

每一條觸發的規則都會記錄一個匹配——它的型別、動作、介面，以及一個 細節字串——可在工作區 Matches 動態上看見（GET /api/guardrail/match，對任何成員開放）。從那裡你可以分組、篩選、匯出成 CSV，並標記誤報。
原始值預設不會被記錄。 一個防護欄的 Log raw content 開關預設關閉 ——這是隱私保守的姿態——所以 Matches 動態會記錄一條 PII 規則觸發了以及 哪個實體，但不會記錄匹配到的子字串（電子郵件地址本身）。只在你需要 那個值來做分流時，才逐防護欄打開它；該設定不溯及既往。為了除錯一次 PII 外洩而在你自己的稽核軌跡裡捕捉 PII，會適得其反。

​
7. 更進一步

若要完整的駐留、保留與被遺忘權控制——包括安裝一個合規包，為 GDPR、 HIPAA 或 PCI DSS 物化這些防護欄——請從下方的參考頁面開始。

防護欄參考

每種規則型別、介面、動作、自訂實體、版本控制，以及評估 工具——本頁背後的深度參考。

密鑰外洩

憑證形狀的同胞——AWS、OpenAI、GitHub 權杖——由 Secrets Blocker 防護欄捕捉。

不安全輸出

審查模型送回來的東西，而不只是它收到的東西。

防護欄與防火牆

何時審查文字、何時治理動作——以及為何你通常兩者都想要。