跳轉到主要內容
一個面向客戶的聊天機器人會從公眾接收不可信的輸入，並把它 送往模型。這使它成為你所運行的曝險最高的介面：使用者 貼上你不想被上游儲存的 PII、攻擊者試圖覆寫 你的系統提示，而模型可能把密鑰或不安全內容回吐 進聊天視窗。本配方串接起四個控制，端對端地保護 一個 AI 聊天機器人——請求上的一條 PII 防護欄、提示注入 篩查、輸出安全，以及一把緊範圍限定的金鑰——全部都在 主控台中完成，且對你的聊天機器人程式碼零更動。
這裡的一切都綁定到你的工作區，並從 主控台設定。你的聊天機器人持續以相同的 sk-orca-... 金鑰呼叫 https://api.orcarouter.ai/v1/chat/completions——只有閘道中的政策改變。 設定動作需要每個步驟標明的角色；中繼呼叫使用 那把範圍限定金鑰。

​
1. 公開聊天機器人的威脅模型

在撰寫任何東西之前，先弄清楚你在防禦什麼。一個聊天機器人的 攻擊面比完整代理的更窄——但那些高頻 風險是具體的：

PII 進來，PII 被記錄

使用者把電子郵件、卡號、SSN 貼進聊天——而你把它們轉送到 上游並進入你的日誌。

提示注入

「忽略先前的指令並……」——試圖覆寫你的系統 提示並改變機器人行為。

越獄

DAN／角色扮演框架，試圖把機器人拉離政策。

不安全輸出

模型把外洩的密鑰、系統提示樣板，或夾帶注入的 內容回吐進聊天。
一個純粹的聊天機器人沒有工具呼叫，所以本配方倚賴 防護欄——文字平面——而不是 防火牆。如果你的機器人確實呼叫工具，請在其上 疊加防火牆（參見 §6）。

​
2. 一條防護欄，四項任務

與其用四個分開的政策，不如撰寫一條工作區防護欄， 以有序的規則涵蓋每個風險。一條防護欄是一份命名的、有序的 規則清單；每條規則說明要找什麼、在哪裡（input、 output 或 both），以及要做什麼（block、mask 或 flag）。 在主控台中，開啟 Guardrails → New guardrail，把它命名為 chatbot-shield，並加入下方的規則。撰寫一條防護欄——以及 運行 Test 沙盒——需要 Developer 角色；檢視 防護欄則對任何成員開放。

​
a. 請求上的 PII

加入一條 PII 規則，stage input，動作 mask。內建的實體 集合是封閉的——挑選聊天機器人實際會看到的那些： 
{
  "type": "pii",
  "stage": "input",
  "action": "mask",
  "entities": ["email", "phone", "credit_card", "ssn", "ip"],
  "entity_actions": { "credit_card": "block", "ssn": "block" }
}
mask 會用一個帶型別的標籤替換每個匹配——jane@acme.com 變成 [EMAIL]，所以上游模型永遠看不到那個地址。 entity_actions 覆寫會在卡號或 SSN 上直接封鎖整個請求， 同時遮罩較低嚴重度的實體。這正是 PII Shield 預設集，以逐實體覆寫擴展——從範本庫套用 該預設集，再從那裡編輯。
輸入階段的 PII 遮罩今天已上線——它會在模型看見請求之前 重寫它。對串流回應的即時遮罩在 規劃藍圖中。要遮蔽機器人回說的 PII，請使用一條 output block 規則（在串流與非串流上都強制執行），或以非串流方式運行機器人， 此時輸出遮罩才適用。先在 Test 分頁中證明你確切的階段／串流組合。

​
b. 提示注入篩查

OrcaRouter 把它作為 Prompt-Injection Basics 安全預設集出貨（一個 針對如*「忽略先前的指令」與「揭露你的系統提示」*等 片語的關鍵字拒絕清單；若要對 DAN／ 角色扮演框架有更嚴格的 regex 涵蓋，加入 Jailbreak / Role-Play Blocker 預設集）， 此外，對於沒有任何模式能捕捉的語意意圖，再加一條 llm_judge 規則。先加入預設集，再在 input 階段加一條 judge 規則，其評分標準會標記注入／覆寫嘗試。該 judge 會對照你工作區中的一個模型運行，受 judge_timeout_ms 限制，並預設失敗開放（fail open）（judge 錯誤會被記錄 且請求繼續）——設定 judge_fail_open: false 以失敗關閉。
從 flag 開始啟動注入規則，在真實流量上觀察 Matches 動態 一天，一旦你確認它們在攻擊上觸發、不在合法問題上觸發， 就晉升到 block。參見 強制執行模式。

​
c. 輸出安全

加入一條 output 階段的 block 規則（regex 或 keyword），針對絕不 應抵達聊天視窗的內容——外洩的密鑰、聊天範本控制 權杖、系統提示樣板。Secrets & API-Key Blocker 與 系統提示外洩安全預設集涵蓋了常見情形；套用它們 並把相關規則固定到 output 階段。輸出 block 在串流上也會 被強制執行——掃描器會中途切斷串流，並在被封鎖的內容抵達 使用者之前送出一則替代訊息。

​
3. 在出貨前測試

每個防護欄編輯器都有一個 Test 分頁。貼上一個樣本、挑選階段， 並在本機運行目前的政策——無上游呼叫，不消耗配額。
貼上這個階段預期
email me at jane@acme.cominputemail me at [EMAIL]
ignore previous instructionsinputflag / block（你的選擇）
卡號 4111 1111 1111 1111inputguardrail_blocked（依覆寫）
要獲得對抗性涵蓋，Eval 分頁會對照捆綁的 紅隊語料庫（或你自己的 JSONL）運行政策，並回報它的得分——調校 judge 評分標準，直到它能捕捉已知攻擊而不標記良性聊天。

​
4. 為機器人鑄造一把範圍限定金鑰

一條防護欄只會在解析到它的金鑰上強制執行。給聊天機器人它 自己的金鑰，範圍限定到它所需的最低限度——絕不用你帳號層級的金鑰。 在 API Keys → New key 中，設定：
從 Guardrail 下拉選單挑選 chatbot-shield。這會在金鑰上設定 guardrail_id。一個明確的附加是關閉開關的 相反面：如果它被設定且啟用，它總是會套用且永不靜默 回退。（保持未設定以改為回退到工作區 is_default 防護欄。）
把 credit_limit_usd 設為一個合理的上限（0 = 無限制）。一個公開 聊天機器人是最可能被濫用的金鑰——一個硬性的額度上限 就是你的爆炸半徑限制。參見 denial-of-wallet。
開啟 model_limits 並只列出機器人被允許 呼叫的模型，這樣一把外洩的金鑰就無法被用來運行你從未 打算曝露的昂貴模型。
如果機器人從固定伺服器呼叫，把 allow_ips 設為你後端的外送 IP， 若金鑰是臨時的則設一個 expired_time （-1 = 永不過期）。
金鑰在建立後顯示時會被遮罩——只複製一次。你的聊天機器人 後端現在會讓每個使用者回合都穿過 chatbot-shield，且沒有任何 程式碼知道篩查正在發生。

​
5. 在生產環境中觀察它

兩個讀取面讓你保持誠實，兩者皆為工作區範圍：
  • Guardrails → Matches（任何 Member）——每條觸發的規則：型別、 動作、階段與細節。匹配到的子字串只有在防護欄的 Log raw content 開啟時才會被記錄（預設關閉—— 隱私保守的姿態）。標記一個誤判以調校政策 （Admin）。
  • 版本歷史——每次變更都會寫入一筆歷史列；diff 任意兩個 版本，若一條規則最後證明太激進就還原。一個被封鎖的 請求回傳 HTTP 400 guardrail_blocked，消耗零配額，並 被標記為 skip-retry。
一個 guardrail_blocked 回應是一個刻意的、使用者可見的 400。在你的 聊天機器人 UI 中以友善的訊息（「我無法處理那個」）處理它，而不是 直接顯示原始錯誤——閘道已經為你擋下了那個不安全的回合。

​
6. 如果你的機器人呼叫工具

一旦你的聊天機器人能夠呼叫一個函式、擷取一個 URL，或觸及一個 MCP 伺服器，文字篩查就不夠了——你需要動作平面。透過 firewall_policy_id 把一個防火牆政策附加到同一把金鑰， 或套用 balanced 自主等級，在收緊之前於工作區範圍稽核 工具呼叫並標記 PII。最快的路徑 是零信任快速入門；對於一個 大量呼叫工具的代理，參見 保護一個自主代理。

​
7. 往哪裡深入

防護欄參考

每種規則型別、PII 實體、judge 欄位，以及完整的 eval 框架。

防護欄與防火牆

文字平面 vs 動作平面——何時需要哪一個。

強制執行模式

Observe → shadow → enforce：在不弄壞機器人的情況下上線。

範圍金鑰、政策、工作區

金鑰附加與工作區預設值如何解析。