跳轉到主要內容
輸入階段防護欄會在請求抵達模型之前審查呼叫方的請求。這是強制執行內容政策最便宜的位置：閘道在提示進來的途中檢查它，如果一條規則封鎖，請求會在計量之前被拒絕——你不必為這次呼叫付任何費用。這就是你阻止洩漏的密鑰、PII 欄位或注入嘗試觸及上游模型的地方。 完整引擎——每種規則類型、欄位與路由——請見 防護欄參考。本頁聚焦於輸入階段：模型之前執行什麼，以及為何此處的封鎖不消耗配額。

​
1. 給 LLM 應用程式的輸入防護欄，在模型之前

每條防護欄規則都帶有一個階段——input、output 或 both。一條 input 規則會在請求文字抵達的那一刻針對它執行，途中送往上游模型： 
caller → [ input guardrail ] → metering → model → [ output guardrail ] → caller
那個排序就是重點。一條輸入規則會在閘道預先扣除任何配額之前看到提示，所以此階段的封鎖是免費的——請求永不抵達模型也永不計費。對比 輸出階段，它在模型回應之後才審查（輸出封鎖則改為退還已預先扣除的配額）。
輸入規則審查呼叫方的請求。如果你也使用 註冊表提示詞，被注入的系統訊息會在路由中較晚才被加入——所以輸入規則看到的是你應用程式發送的訊息，而不是被注入的提示詞。無論如何，輸出規則都會審查回應。

​
2. 你可以在輸入階段執行什麼

任何規則類型都可以在 input 執行。在模型之前把關請求最常見的理由：

遮罩提示中的 PII

一條帶有 mask 動作的 pii 規則會把實體改寫為具型別的標籤（jane@acme.com → [EMAIL]），讓上游模型永遠看不到原始值。參見 PII Shield。

在密鑰洩漏前封鎖它

一個攜帶 API 金鑰或雲端憑證的請求會在門口被拒絕——計量之前，無上游呼叫。參見 封鎖密鑰。

阻止注入嘗試

Prompt-Injection basics 預設將關鍵字／正規表示式偵測器與一條針對注入意圖的 llm_judge 規則配對。參見 提示注入。

限制提示大小

一條 max_chars 規則會在過大的提示計費任何權杖之前拒絕它。參見 成本防護欄。
七種規則類型——keyword、regex、pii、max_chars、external、llm_judge、grounding——以及五種動作 block、mask、flag、annotate 與 spotlight 在此都適用。（spotlight 會把匹配到的不可信文字包裹在分隔符中，讓模型把它當作資料而非指令——一種輸入階段的提示注入防禦；annotate 在不改變流量的情況下附上一則註記。）一個值得知道的例外是：grounding 會把答案與擷取的來源衡量，所以它本質上是一個輸出階段檢查。其他一切都天然適合輸入階段。
輸入階段遮罩今天已上線——無論串流與否。閘道會在每條路徑上於模型看到請求之前改寫它。輸出 mask 僅遮罩非串流回應；帶內輸出改寫仍在規劃中，所以一條遮罩規則目前還不會遮罩串流回覆。相比之下，輸出 block 在兩種情況下都會強制執行——串流與非串流（參見 串流覆蓋）。

​
3. 一個具體範例

在主控台中撰寫規則（在你自己的工作階段下——防護欄設定需要 Developer+），而不是用中繼金鑰。在一個名為 secrets-shield 的防護欄中新增一條 input 規則： 
{
  "type": "regex",
  "stage": "input",
  "action": "block",
  "pattern": "sk-[A-Za-z0-9]{20,}"
}
將防護欄綁定到一把金鑰（設定 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": "Debug this: OPENAI_API_KEY=sk-abcdefghij1234567890"}
    ]
  }'
請求在輸入階段匹配，並在閘道向上游轉送任何東西之前以 HTTP 400 guardrail_blocked 被拒絕： 
{
  "error": {
    "type": "guardrail_blocked",
    "message": "request blocked by guardrail \"secrets-shield\": regex(...)"
  }
}
完整的回應形狀請見 guardrail_blocked 錯誤。

​
4. 為何輸入封鎖不消耗配額

這是在進來途中捕捉事物的結構性優勢。一個輸入階段的封鎖位於預先扣除之前，所以：
屬性輸入階段封鎖
HTTP 狀態400 guardrail_blocked
計費配額無——在計量之前觸發
上游呼叫從未發出
重試標記為 skip-retry——重跑只會再次封鎖
由於請求永不抵達某個通道，輸入封鎖會被標記為 skip-retry：針對另一個通道重跑同一個提示只會再次封鎖並浪費功夫。輸出階段有所不同——那裡的封鎖會退還閘道已預先扣除的配額。同樣的 400，不同的記帳。

​
5. 解析與回退

只有當一個防護欄確實在請求上解析出來時，輸入階段規則才會執行。解析是明確的：
  1. 金鑰明確的 guardrail_id，如果它存在且已啟用。
  2. 否則是工作區預設防護欄。
  3. 否則無——請求與沒有政策的工作區位元組完全一致。
明確綁定永不會靜默回退。停用一個綁定的防護欄就是關閉開關——它不會落到工作區預設值。（防火牆政策在這裡行為不同；參見 防護欄與防火牆。）

​
6. 上線前先證明它

別憑信任就把一條封鎖性的輸入規則綁定到實際流量上。先驗證的兩種方式：
在防護欄編輯器中開啟 Test 分頁，貼上一個樣本，選擇 input 階段，然後執行。沙盒會在本機評估目前的政策——沒有上游呼叫，不消耗配額——並傳回裁決加上（對於遮罩規則）渲染後的文字。參見 測試與評測。
先把動作設為 flag。flag 不改變流量的任何部分——它只記錄一個匹配——所以你可以在把它翻成 block 之前衡量一條規則在真實輸入上會多常觸發。參見 調校誤報。
每條觸發的規則都會記錄一個匹配——類型、動作、階段，以及一個詳情字串。匹配到的子字串只在 Log raw content 開啟時才會記錄（預設為關閉）。參見 匹配動態 和 日誌與隱私。

​
7. 下一步去哪裡

輸入階段阻止壞輸入抵達模型。若要把關模型的回應，把它與輸出階段配對；若要治理一個代理的工具呼叫，使用防火牆。 閱讀 防護欄參考 以了解完整引擎，或閱讀 安全快速入門 以將輸入防護欄與防火牆串接起來，建立一個代理基準。