跳轉到主要內容
每條防護欄規則回答三個問題——尋找什麼（類型）、在哪裡尋找（階段），以及對它做什麼（動作）。本頁談的是第三個選擇。一條規則的動作是它上面最具後果性的單一欄位：它決定一個匹配是停止請求、安靜地改寫它，還是只留下一個痕跡。 規則建構器總共呈現五種動作——block、mask、flag、annotate 和 spotlight。本頁涵蓋你最先會用到的三種強制執行選擇：block、mask 和 flag。每條規則挑一個（或者，對於 PII 規則，把不同實體導向不同動作；參見 §5）。另外兩個是塑形提示、非封鎖的動作：annotate 向上游注入一則安全註記（參見 程式碼安全），而 spotlight 把匹配到的不可信輸入包裹在分隔符中，讓模型把它當作資料而非指令。完整名單請見 防護欄總覽。 更廣的引擎——規則類型、階段、將政策綁定到金鑰——請從 防護欄總覽 或完整的 防護欄參考 開始。

​
1. 一行說清 block mask flag 決策

block

以 HTTP 400 guardrail_blocked 拒絕呼叫。模型永不執行（輸入階段）或它的答案永不回傳（輸出階段）。

mask

遮罩每個匹配項——例如 jane@acme.com → [EMAIL]——並讓淨化後的文字通過。請求繼續。

flag

不改變流量的任何部分。在動態中記錄一個匹配然後繼續。僅觀察。
這些是三種強制執行動作。你設定的任何一個都會在規則執行的所有地方被遵守——主控台規則建構器、Test 沙盒 與實際的 /v1/* 中繼路徑全都讀取相同的 block / mask / flag 值。

​
2. 一個具體範例——三條規則、三個動作

這是一個防護欄，它的三條規則各挑選一個不同的動作。你在主控台（/console/guardrails）的工作階段上撰寫它——sk-orca-... 中繼金鑰只用於 /v1/* 呼叫，絕不用於編輯政策。建立或編輯防護欄需要 Developer+ 角色。 
{
  "rules": [
    { "type": "keyword", "stage": "input",  "action": "block",
      "keywords": ["internal-only", "do-not-share"] },
    { "type": "pii",     "stage": "input",  "action": "mask",
      "entities": ["email", "phone"] },
    { "type": "regex",   "stage": "output", "action": "flag",
      "pattern": "(?i)acme\\s+confidential" }
  ]
}
每條規則對一個請求做什麼：
  • block 規則拒絕任何包含那些字面詞彙之一的提示——HTTP 400，模型永不執行。
  • mask 規則在模型看到提示之前，把提示中的電子郵件與電話號碼改寫為 [EMAIL] / [PHONE]。
  • flag 規則監看模型的輸出是否有機密標記，並在不變更回應的情況下記錄一個匹配——這樣你就能在決定強制執行前衡量它出現的頻率。
引擎會執行每一條適用的規則，並把結果摺疊成單一裁決。如果有任何規則封鎖，請求就被封鎖。

​
3. block——以 HTTP 400 拒絕

一個 block 動作會拒絕整個呼叫。呼叫方會得到 HTTP 400，錯誤代碼為 guardrail_blocked，並附上指名觸發的防護欄與規則的訊息。
輸入階段封鎖在計量之前觸發，所以什麼都不消耗。輸出階段封鎖會在拒絕答案後退還已預先扣除的配額。無論哪種情況，呼叫方都不為被封鎖的呼叫付費。
一個 guardrail_blocked 結果是 skip-retry——針對另一個通道重跑同一個提示只會再次封鎖，所以閘道不會浪費一次重試。參見 guardrail_blocked 錯誤。
在非串流回應上，答案會在回傳前被審查。在串流回應上，一個掃描器會在飛行途中切斷串流，並在任何被封鎖的內容抵達客戶端之前發出一則替代訊息。參見 串流覆蓋。
當一個匹配意味著請求絕不能繼續時，使用 block——提示中的密鑰、一次越獄嘗試、一條硬性合規界線。

​
4. mask——遮罩並繼續

一個 mask 動作會遮罩每個匹配項並以淨化後的文字讓請求通過。上游模型永遠看不到原始內容。在一條 PII 規則上，每個匹配項會被替換為一個從實體衍生的具型別標籤——電子郵件變成 [EMAIL]，SSN 變成 [SSN]，信用卡變成 [CREDIT_CARD]，依此類推。（你可以為每個自訂實體覆寫替換字串；參見 遮罩格式。）
輸入階段遮罩在每種串流上都已上線。 它會在模型執行之前改寫請求，無論串流與否。輸出階段遮罩僅套用於非串流回應——遮罩後的文字會在完整答案被審查後轉送。在串流回應上，閘道會計算遮罩但尚未轉送遮罩後的文字，所以一條遮罩規則今天不會遮罩串流回覆；帶內輸出遮罩仍在規劃中。（一個輸出 block 仍會在飛行途中切斷串流——參見 §3。）先在沙盒中證明你確切的階段／串流組合。參見 串流覆蓋。
當內容沒問題但某個子字串不該抵達模型時，使用 mask——PII 遮罩是典型案例。一站式起點是 PII Shield 預設；參見 PII Shield。

​
5. flag——僅記錄，不改變任何東西

一個 flag 動作是僅觀察：請求與完全沒有規則時位元組一致，除了一個匹配被記錄到 匹配動態 中。沒有東西被封鎖，沒有東西被遮罩。
flag 是你在強制執行之前衡量一條規則的方式。把一個新的關鍵字或正規表示式以 flag 出貨，觀察 Matches 動態幾天以查看它在真實流量上的真陽性對假陽性比率，然後在你信任它之後把它晉升為 mask 或 block。以 flag 開啟來調校一個吵雜的模式，勝過在生產中以 block 開啟才發現那些誤報。參見 調校誤報。
一個被標記的匹配會記錄規則類型、動作、階段，以及一個詳情字串——而匹配到的子字串只在該防護欄的 Log raw content 開啟時才記錄（預設為關閉，隱私保守姿態）。參見 日誌與隱私。

​
6. 每實體動作覆寫

單一 PII 規則可透過 entity_actions 把不同實體導向不同動作，而不必堆疊重疊的規則。每個覆寫值必須是 block / mask / flag / annotate 之一，且必須引用該規則已宣告的實體——驗證器會拒絕其他任何內容。 
{
  "type": "pii",
  "stage": "input",
  "action": "mask",
  "entities": ["email", "phone", "ip", "credit_card", "ssn"],
  "entity_actions": {
    "credit_card": "block",
    "ssn": "block"
  }
}
這一條規則遮罩電子郵件、電話與 IP，但在卡號或 SSN 上直接封鎖請求。參見 自訂 PII 實體，以在相同的覆寫模型下疊加你自己的偵測器。

​
7. 選擇正確的動作

如果你想…使用效果
完全停止請求blockHTTP 400、無配額、skip-retry
剝除一個子字串、保留呼叫mask轉送遮罩後的文字
觀察而不觸碰流量flag僅記錄匹配
動作與階段組合。同一個動作在輸入對輸出上的行為略有不同——輸入封鎖在前端省下配額；輸出封鎖退還配額；輸出遮罩僅套用於非串流回應，而輸出封鎖在串流與非串流回應上一律切斷。請把 輸入階段 和 輸出階段 與本頁一起閱讀。

​
8. 下一步去哪裡

guardrail_blocked 錯誤

一個 400 長什麼樣、為何不消耗配額，以及 skip-retry 如何運作。

遮罩格式

具型別標籤、自訂替換字串，以及一個遮罩後的提示對模型而言讀起來像什麼。

串流覆蓋

今天確切強制執行哪些 動作 × 階段 × 串流 的組合。

強制執行模式

block / mask / flag 如何對應到閘道更廣的強制執行模型，包括防火牆的稽核裁決。
防火牆對工具政策有它自己的裁決詞彙（allow、audit、deny、sanitize 等等）——與這些內容動作不同。參見 防護欄與防火牆。