跳轉到主要內容
一個長時間運行的自主代理是最難保護的東西。它 自己迴圈數小時、挑選自己的工具、擷取自己的 URL，並 全程花你的錢。失敗模式不是單一一個壞 提示——而是一個一夜燒掉 $400 的重試迴圈、一個你 從未審查過的工具呼叫、一把你為了一週實驗鑄造卻 六個月後仍能運作的金鑰。 本配方圍繞著正是那種形狀的代理串接起四個控制。你 在主控台（或 REST API）中設定它們全部——代理像以前一樣 持續呼叫 https://api.orcarouter.ai/v1/...。
新到這裡？先套用 balanced 基準 並觀察你的代理做什麼 一天。本頁是下一步：把觀察轉化為強制執行， 為一個你無法保姆式照看的代理。

​
1. 安全自主代理配方

一個安全的自主代理需要四樣聊天機器人不需要的東西：

一個硬性成本上限

一條 cap_cost 規則會在 run 的累計花費跨越你的上限後 拒絕該 run——為一個停不下來的迴圈設的斷路器。

飆升偵測

異常偵測會學習代理正常的週小時形狀，並 標記溜過靜態規則的速率與成本飆升。

對危險呼叫的審批

一個 pending_approval 裁決會為一個人類保留破壞性或 不可逆的工具呼叫，而不是信任代理會小心。

一把會過期的金鑰

把代理的金鑰範圍限定到一個到期日與一個額度上限，這樣一個 被遺忘的實驗就無法永遠運行——或花費。
每一個都對應一個防火牆政策或 金鑰欄位。沒有一個 觸及你的代理程式碼。

​
2. 為每次 run 設定成本上限

一個失控的迴圈第一個炸掉的是你的預算。一條 cap_cost 規則是 一個嚴格的預先檢查成本上限：當它匹配時，閘道會估算 請求的成本，並在該 run 的累計花費會超出上限後在派發前 拒絕——所以一個超出預算的呼叫永遠不會抵達供應商。 該上限是run 範圍的。閘道會把整個代理 run 的先前花費 加總，所以一個已經燒掉大部分預算的長 run，即使下一個 個別呼叫很便宜，也會被拒絕。那就是讓它成為一個 斷路器而非一個逐請求限制的原因。 在你的防火牆政策中加入一條萬用字元規則： 
{
  "priority": 50,
  "tool_name_glob": "*",
  "verdict": "cap_cost",
  "cap_cost_cents": 1000
}
這會把 run 的上限設在 $10（cap_cost_cents 以美元分計）。 裁決在預算內時解析為 allow，一旦估算會跨越它就解析為 deny。大多數內建的防火牆範本（Coding、 Support、RAG、Data、DevOps、Browser）都出貨一個正是 這樣的逐 run 成本上限——套用一個並編輯該上限。
Run 範圍的累計需要為工作區啟用 request-log 擷取。 在它關閉時，先前花費的彙總會讀為零，而上限會 退化為僅逐請求——仍然安全，但它不會捕捉一個緩慢的 500 次呼叫滴漏。參見 denial-of-wallet。

​
3. 對照一個習得基準偵測飆升

一個上限阻止災難；異常偵測會在怪異變成 災難之前捕捉它。防火牆會學習每個工作區正常的 工具使用形狀——一個按週小時分桶的 14 天滾動平均， 所以週二 14:00 的流量會對照週二 14:00 的歷史比較，而非一個 平坦的每日均值——並在一個檢視者可讀的動態上浮現偏差：
每個工具的呼叫量會對照習得基準評分。「一小時內 143 次 db.query 呼叫對照基準的 8」即使每個個別呼叫都被 允許也會浮現。
同一個基準，套用於花費而非次數——一個 run 突然 燒得遠比這個小時平常多。
一個卡在重試同一個壞掉呼叫的自主代理的 特徵。參見 excessive-agency。
這個工作區從未做過的一次工具到工具的躍遷——一個 代理走向新地方的形狀。
該動態回報工具名稱、遮罩過的權杖 id 與計數——絕不回報原始 引數。讀取它對任何 Member 開放；一位 Developer+ 可以 在調查期間**暫停（snooze）**該動態達 7 天。把該動態 與一條 cap_cost 規則搭配，這樣一個同時超出預算的飆升就會被阻止， 而不只是被注意到。

​
4. 為一個人類保留危險呼叫

你無法審查一個自主代理發出的每個呼叫——但你可以讓 它在那少數重要的呼叫之前停下並詢問。一個 pending_approval 裁決會在頻道外保留一個工具呼叫：
  1. 代理發出，比方說，一個 payments.transfer 呼叫。規則匹配， 引擎回傳 HTTP 400 firewall_approval_pending，帶一個 審批 id——該呼叫永遠不會抵達工具。
  2. 一位審查者從主控台（Developer+）解決它，或你自己的 系統透過一個 HMAC 簽署的 webhook 回呼到 POST /api/v1/firewall/approvals/:id/callback 解決它。
  3. 代理輪詢 GET /api/v1/firewall/approvals/:id；一旦獲批它就 帶著一個一次性的 X-OrcaRouter-Firewall-Approval 標頭重新提交原始 呼叫，而閘道讓它通過那一次。
一條保留寫入破壞性介面的規則： 
{
  "priority": 20,
  "tool_name_glob": "payments.*",
  "verdict": "pending_approval"
}
先在影子模式中上線 這個——pending_approval 降級為 audit，所以你會看到哪些呼叫 會被保留，而不會真正封鎖你的代理。當動態看起來正確時，把影子翻關。

​
5. 給代理一把會過期的金鑰

那個比每個政策都活得久的控制是金鑰本身。一個 自主代理應該得到一把範圍限定的金鑰，而非你的預設金鑰。在你鑄造它時 設定這些欄位（console → keys，或 token API）：
欄位設為為什麼
expired_time一個 Unix 時間戳實驗結束；金鑰隨之而亡。-1 表示永不——別在這裡用那個。
credit_limit_usd一個美元上限金鑰上獨立於 run 上限的一個花費上限。0 表示無限制。
firewall_policy_id上方你的政策把 cap_cost + 審批規則綁定到這把金鑰。
allow_ips代理的外送 IP一把外洩的金鑰從其他任何地方都沒用。
也設定一個 environment 標籤，這樣金鑰——以及它在 Events 與 Matches 中所做的一切——都可歸因到這個代理。一把會過期、 有額度上限、IP 固定的金鑰是最後一道防線：即使每個政策都 不知怎地被繞過，爆炸半徑也受時間與美元所限。
金鑰設定是一個 console / token-API 動作，且有角色管控。 讀取一把防火牆閘道金鑰的明文需要 Admin+。

​
6. 把它組合起來

一個加固過的自主代理最終會有一個防火牆政策與一把 範圍限定金鑰：
層次控制捕捉
預算cap_cost 規則，run 範圍失控迴圈、denial-of-wallet
行為Anomaly feed（rate / burn / retry / novel）怪異但被允許的
信任破壞性工具上的 pending_approval不可逆的動作
範圍會過期、有額度上限、IP 固定的金鑰被遺忘或外洩的金鑰
把預算與審批規則一起撰寫，用 防火牆規則設定一個逐 run 上限，並讀取 防火牆參考的其餘部分以了解介面、裁決與 可觀測性。關於本配方所防禦的相關威脅，參見 excessive-agency、 dangerous-tool-calls與 denial-of-wallet。

​
7. 下一步

加固一個 MCP 代理

治理一個透過 MCP 伺服器觸及工具的代理。

停止外洩

為一個擷取自己 URL 的代理設定 egress 規則。

強制執行模式

Observe → shadow → enforce，安全的上線。

防火牆規則

上方每條規則背後的匹配語言。