這裡的一切都是唯讀或沙盒的——沒有面向使用者的封鎖、沒有
受影響的生產流量。(Keyword、regex 與 PII 規則完全在本機
運行;一條
llm_judge 規則仍會呼叫它設定的模型,所以一個對
judge 政策的 eval 確實會做那個呼叫。)重點是在你的條件下、在發布
之前把東西弄壞。1. 如何在發布前對一個 AI 代理做紅隊演練
一次發布前紅隊演練回答三個問題,而 OrcaRouter 為每一個都有一個 工具:我的防護欄能捕捉攻擊嗎?
對照捆綁的對抗性語料庫運行防護欄的 Eval
框架,並讀回 precision / recall / F1。
我的防火牆會弄壞什麼?
開啟影子模式,並觀察哪些真實的工具呼叫本來會被
拒絕——而尚未拒絕它們任何一個。
一個更緊的姿態安全嗎?
模擬一個自主等級,以在你套用它之前對照你的流量
預覽它確切會改變什麼。
2. 對照對抗性語料庫為你的防護欄評分
知道一個內容政策是否在與一個攻擊者接觸後存活的最快方式, 是把一個已知攻擊的語料庫扔向它並讀取分數。 防護欄編輯器的 Eval 分頁正是做這個:它把一個語料庫中的 每個樣本透過你目前的政策重放,並把裁決 與每個樣本的預期結果比較——在本機對照你的規則重放語料庫,絕不對照即時流量。 OrcaRouter 出貨捆綁的紅隊語料庫,這樣你就不必取得 你自己的。其中包括:| 語料庫 | 它是什麼 |
|---|---|
advbench_harmful_behaviors | 經典的對抗性後綴目標集——每一列都是一個防護欄應封鎖的不安全請求。 |
anthropic_hh_redteam | 對照一個助理的真實多回合人類紅隊文字記錄。 |
deepset_prompt_injections | 標記好的提示注入 vs 良性請求——一個輸入階段 block 的 precision/recall 基準。 |
databricks_dolly_benign | 一個純良性的基準:一個過度嚴格的政策應該一個都不封鎖。 |
deepset_prompt_injections 語料庫運行一個 eval:
- TP / FP / FN / TN——真/假陽性與陰性,其中一個 「假陽性」包括以錯誤的動作類別捕捉一個攻擊 (例如在你預期一個 block 時遮罩)。
- Precision / Recall / F1——頭條數字。低 recall 表示 攻擊溜了過去;低 precision 表示你正在封鎖良性 流量。
提示注入防禦存在於何處。 捆綁的 Prompt-Injection
Basics 預設集是一條 flag 動作上的 keyword 規則——它為
常見的越獄片語浮現以供審查而不封鎖使用者。對於
沒有任何 keyword 清單能捕捉的語意注入意圖,加一條
llm_judge 規則並以相同方式對它做紅隊演練:對照
deepset_prompt_injections 與 anthropic_hh_redteam 對它 eval 並讀取 F1。
參見防護欄參考。3. 對真實流量影子化防火牆
一個防護欄 eval 對照一個固定語料庫測試文字。相對地,你的 防火牆需要對照你的代理實際做什麼的混亂現實來測試—— 而在發布前做那件事最安全的方式是 影子模式。 影子模式是一個逐政策的旗標,讓防火牆完全像在生產環境中那樣 評估並記錄每個工具呼叫,但把 每個強制執行的裁決降級為audit。一個 deny 變成一個 audit 列,其
原因被加上前綴 [shadow] would …。沒有東西被封鎖。沒有東西
壞掉。但 Events 動態現在向你顯示你的政策本來會
拒絕的呼叫的精確清單。
這就是防火牆紅隊演練:撰寫你最嚴格的預期政策、
翻開影子模式、讓你的代理跑過一次擬真的發布演練,
然後讀取 [shadow] would … 事件。
撰寫政策,然後影子化它
撰寫政策,然後影子化它
在主控台中建構你的強制執行政策(Developer+)——對於一次
發布乾跑,把
default_verdict 設為 audit 並加上你打算
出貨的 deny 規則。把影子模式切換開。整個政策
現在記錄而不強制執行。像發布日那樣演練代理
像發布日那樣演練代理
用一把附加到被影子化政策的金鑰,對照閘道運行你真實的
代理流程。每個工具呼叫——inbound、response、MCP
派發、egress——都被評估並記錄。
讀取本來會封鎖的清單
讀取本來會封鎖的清單
開啟 Firewall → Events(Developer+)並按
[shadow] would … 原因篩選。每一個都是你的政策本來會在生產環境中
拒絕的一個呼叫。確認每個條目都是你想要拒絕的呼叫——而且
清單上沒有任何合法的東西。翻關影子以上線
翻關影子以上線
一旦本來會封鎖的清單乾淨了,把影子模式翻關。緊接的
下一個匹配呼叫就會真正被強制執行——沒有其他變更。
4. 在你承諾之前模擬一個更緊的姿態
第三個紅隊招式是最便宜的:在你套用一個更嚴格的 自主等級之前,模擬 它。模擬器會對照你工作區最近的流量預覽套用tight(或任何等級)本來會
改變什麼——多少呼叫會翻為 deny——而不寫入任何一個政策列。
tight 準備好了嗎?」在發布前:如果預覽顯示在你代理
依賴的呼叫上有一面本來會拒絕的牆,你就有規則要在
go-live 之前軟化,而不是在它之後的一次事件。
模擬是僅預覽的——它絕不變更你的政策。套用一個
自主等級是一個分開的 Developer+ 動作,且它是一個帶
一鍵還原的交易,如果即時結果仍然讓你意外。
5. 發布前紅隊演練檢查清單
把三個過程組合起來,你就有了一個發布閘門:| 過程 | 工具 | 綠燈條件 |
|---|---|---|
| 內容政策 | 防護欄 Eval vs 攻擊 + 良性語料庫 | 對攻擊高 recall、對良性無封鎖 |
| 動作政策 | 防火牆 影子模式 vs 演練流量 | 每個 [shadow] would … 都是預期的 |
| 涵蓋範圍 | 觀察模式 + Discovered tools | 沒有意外的工具坐在一個涵蓋缺口中 |
| 姿態 | 模擬目標自主等級 | 預覽符合你的預期 |
https://api.orcarouter.ai/v1/...。
6. 下一步
強制執行模式
Observe → shadow → enforce,本配方演練的安全上線。
Secure Agents 基準
每個自主等級設定什麼——以及
simulate 如何預覽它。提示注入
你的防護欄 eval 所對照評分的威脅。
上線
紅隊演練通過後的生產切換。
