摘要： OpenRouter 在 5 月 29 日上線 Guardrails，把預算限制、ZDR、模型與 provider 限制、prompt injection 防禦和 DLP 收進 workspace 層級治理。規則可套用到整個 workspace、特定成員或 API key，且帳號層級政策只准下層收緊、不准放寬。regex 防禦只是縱深防禦的一層，人名與地址改用 Presidio NLP 時延遲會隨輸入增長。
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 攔截回 403。把這組對應寫進 agent 的錯誤處理，閘門一觸發，馬上就能判斷是哪一層在擋。
| 狀態碼 | 觸發情境 |
|---|---|
| 402 | 花費達到重置窗口的上限 |
| 404 | model 或 provider 遭到限制 |
| 403 | prompt injection 或 DLP 攔截 |
預算機制：以 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。治理面則能封鎖特定 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。掃描對象不只是直白的指令，encoding-based、character-spaced、typoglycemia 這幾種常見繞道手法也都在範圍內。兩個工程特性值得記下：第一，它 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。
限制與落地順序
限制得先說明白。regex 防禦是 deterministic 的：對常見注入與規避手法管用，但碰上精心設計的針對性攻擊，本來就不該指望 100%——它是縱深防禦裡的一層，不是全部。Presidio NLP 的延遲會隨輸入放大，person name 與 address 偵測要不要常駐開啟，拿真實流量實測過再定。guardrails 只能收緊、不能放鬆，前述的環境差異問題，務必在規劃 workspace 時就解決。
落地順序很單純：先用 default guardrail 壓上一個保守的 daily 預算、把 prompt injection blocking 開成基線；接著替高風險的 production keys 疊上更嚴的模型限制與 DLP。Guardrails 的價值不在取代 application 層的安全設計，而是把成本與安全從 codebase 裡抽離，變成一層能夠獨立審計、獨立調整、部署時不必重新 build 的 infrastructure。