OpenRouter 在 5 月 29 日推出 Guardrails：一組 workspace 層級的可組態 security 與 governance 工具，涵蓋 budget enforcement、zero data retention（ZDR）與 model/provider 限制、prompt injection 防禦，以及 data loss prevention（DLP）。對正在管理 API 用量、需要應付治理要求，或者只是想防止自己寫的 agent 意外燒掉預算的 builder 來說，這個功能值得放進工具箱。
更關鍵的是位置：這些規則不寫進 application code，而是掛在 OpenRouter 的 workspace 層。你可以用一組規則治理整個 workspace，也可以為特定 team member 群組或單一 API key 建立專屬 guardrail——全程不用改任何程式碼。設定入口在 dashboard 的 Workspaces > Guardrails 頁面，或直接走 management API。
三種攔截碼先記住
Guardrails 的行為最終會反應在 HTTP status code 上，三個數字值得先記：預算超限回 402、打到被禁用的 model 或 provider 回 404、prompt injection 或 DLP 的 block 回 403。把這組對應寫進 agent 的錯誤處理，閘門被觸發時就能立刻分辨是哪一層在擋。
| 攔截碼 | 觸發條件 |
|---|---|
| 402 | 花費超過重置窗口上限 |
| 404 | model 或 provider 被限制 |
| 403 | prompt injection 或 DLP block |
預算控制：per-entity，而且會疊加
Budget enforcement 支援 daily、weekly、monthly 三種重置窗口的花費上限，超限的請求直接以 402 失敗。容易被忽略的細節是 per-entity 設計：把 $50/day 的 guardrail 指派給三位成員，不是三人共享一個 $50，而是每人各有獨立的 $50——額度不會被同事吃掉，問責也才算得清楚。
API key 的預算會獨立疊在 member 預算之上。以官方範例的數字看：某位成員的 member 上限是 $100/day，他名下某把 key 的上限是 $30/day，這把 key 最多用到 $30，而該成員在 workspace 內所有 key 的合計上限仍是 $100。兩個限制在每次請求都會檢查——key 層可以比人層更緊，但永遠不會更鬆。這組設計也把「誰可以花多少錢」從口頭約定變成可執行的邊界：超額不是發通知，而是直接失敗，因此 agent 的重試邏輯應該把 402 當成一級公民處理，而不是把它混同於一般錯誤無限重試。
ZDR 與模型限制：只能更嚴的繼承
隱私側的一鍵選項是 ZDR：停用所有會 retain 或 train on data 的 endpoints。治理側則可以 block 個別 models 或 providers，或反過來設 allowlist；被禁止的請求以 404 失敗。
真正構成骨架的是繼承規則：帳號層級的 privacy policies 與 provider restrictions 預設被 workspace 繼承，而 guardrails 只能比帳號設定更嚴格，無法放寬。換句話說，治理下限由帳號鎖死，往下每一層只能往上加嚴。這對多環境管理有直接含義：如果 staging 需要比 production 寬鬆，得在 workspace 結構上先想清楚，而不是事後用 guardrail 放寬。
Prompt injection 防禦：30 條 regex 在出口前攔截
輸入側的防禦用超過 30 條 regex patterns 掃描 prompt injection 與 jailbreak，規則來源包括 OWASP 的 LLM Prompt Injection Prevention Cheat Sheet。掃描不只匹配直接指令，也涵蓋 typoglycemia、encoding-based、character-spaced 這類常見規避手法。兩個工程性質值得注意：一是 deterministic，latency 可忽略；二是它發生在請求送達 model provider 之前——被擋下的流量根本不會離開 OpenRouter。
處理動作分三段：Flag 讓請求原樣通過、只記錄偵測結果，適合先收集 observability 再評估；Redact 把匹配段落替換成 [PROMPT_INJECTION] 後照常送出；Block 以 403 拒絕整個請求，並附帶 pattern 類型的 metadata。實務上合理的路徑是先開 Flag 觀察一段時間，依誤判率再決定收緊到 Redact 或 Block。
DLP：七種內建類型，Presidio 是唯一例外
資料外洩防護內建七種 sensitive info 類型，並可用 custom regex 增補內部代號、proprietary IP 這類網域特定資料；動作同樣是 Redact 或 Block，block 一樣回 403。偵測方式有一個分叉要記得：多數內建類型與全部 custom patterns 走 regex，維持 deterministic 與低延遲；person names 與 addresses 則走 Microsoft Presidio 的 NLP，latency 會隨輸入大小增加——高吞吐場景要把這個例外算進回應時間的預算。
疊加模型與自動化
每個 workspace 都有一個 default guardrail 作為 baseline，自動套用所有 keys 與 members；額外 guardrails 疊加其上，而指派給 member 的規則會涵蓋該成員的所有 keys。需要程式化管理時，management API 支援 create、update、delete、list、assign 全套操作，官方 curl 範例的關鍵欄位如下：
{
"limit_usd": 100,
"reset_interval": "daily",
"allowed_models": ["..."],
"content_filter_builtins": [{ "slug": "...", "action": "block" }]
}limit_usd 配 reset_interval 定義預算窗口，allowed_models 是模型 allowlist，content_filter_builtins 用 slug 加 action 逐條開啟內容過濾規則。team onboarding 或 key rotation 的自動化可以直接建立在這組 API 上，不必回頭改 codebase。
取捨與 builder 建議
限制要先講清楚。regex 防禦是 deterministic 的：對常見注入與規避手法有效，但面對精心設計的針對性攻擊本來就不該期待 100%——它是縱深防禦的一層，不是全部。Presidio NLP 的延遲隨輸入增長，person name 與 address 偵測要不要常開，先用真實流量量過再決定。guardrails 只能更嚴不能更鬆，前面提過的環境差異問題，要在 workspace 規劃階段就處理掉。
落地順序則很直接：先用 default guardrail 設一個保守的 daily 預算、開 prompt injection blocking 當基線；再為高風險的 production keys 疊加更緊的模型限制與 DLP。Guardrails 的價值不在取代 application 層的安全設計，而是把成本與安全從 codebase 抽出來，變成一層可以獨立審計、獨立調整、而且部署時不用重新 build 的 infrastructure。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。