跳轉到主要內容
一個代理不必洩漏資料就能傷害你。它可以單純地花錢——一個捶打昂貴模型的 重試迴圈、一個扇出一千個工具呼叫的提示注入指令，或一個累積推論直到帳單 寄達的外洩 API 金鑰。這就是拒絕錢包：攻擊就是成本本身。不同於典型的 拒絕服務，閘道仍然在線，而且每個請求個別看來都合法——傷害是總和花費。 OrcaRouter 給你三個獨立的天花板，全都駐守在上游模型之前，所以沒有任何 單一失控路徑能讓你的帳單無上限地跑。

​
1. denial of wallet ai 威脅

一次拒絕錢包事件通常追溯到三種形狀之一：
一個代理在一個緊湊的迴圈中重試同一個失敗的工具或重新規劃，在每一輪 上重新付權杖的錢。無需惡意——一個壞的停止條件就夠了。
一次 提示注入把代理引向 洗版一個工具或發出超大請求，每一輪倍增花費。
一個金鑰落到它不該在的地方——一個被提交的 .env、一個共享的 notebook——而一個攻擊者在你的帳戶上運行推論，直到花費被注意到。
這三種情況的防禦都一樣：一個攻擊者無法用言語繞過的硬天花板，在閘道處 強制執行，而不是在你的代理程式碼裡。

​
2. 用 cap_cost 設定逐執行成本天花板

防火牆的 cap_cost 裁決是針對失控迴圈的斷路器。你把它撰寫成一條帶有 逐執行分（cents）上限的規則；引擎會把該代理執行的累計花費加總，一旦執行 跨越上限，就把裁決解析為 deny——那次執行中之後的每一個工具呼叫都會被 封鎖。 cap_cost 是一個派發前天花板：它在呼叫抵達工具之前評估，所以它阻止的 是下一個昂貴的呼叫，而不是退還一個已經發生的。一個對每個工具的典型 全攔截上限： 
{
  "priority": 50,
  "label": "cap runaway spend at $5 per run",
  "tool_name_glob": "*",
  "verdict": "cap_cost",
  "cap_cost_cents": 500
}
在上限之下呼叫被允許；超過它，該執行就被以 HTTP 400 firewall_blocked 拒絕——被標記為 skip-retry，所以迴圈無法繞著拒絕捶打。天花板是 逐代理執行的，且在你整個工作區政策間加總，所以一次失控的對話不能 滲入另一次的預算。
cap_cost 從你的請求日誌讀取執行中的花費。讓工作區的請求日誌捕捉保持 開啟，這樣執行中花費的彙整才有列可加總——否則先前花費的估計會被保守地 設為 0，而上限就看不見一次執行已經花了多少。
完整的匹配語言，以及 cap_cost 在其他裁決之間的位置，參見 防火牆規則參考。

​
3. 用 credit_limit_usd 為每個金鑰設定硬預算

cap_cost 界定的是單一執行。要界定一個金鑰——它曾發出的每一次執行 ——請在 API 金鑰上設定 credit_limit_usd。它是那個金鑰終身花費上的一個 硬 USD 天花板：閘道把它轉換成該金鑰剩餘的配額，一旦金鑰花完它的額度， 進一步的中繼呼叫就會因額度不足而被拒絕。0 表示無上限。 把它與金鑰的其他範圍配對，這樣一個外洩的金鑰會在每一個軸上同時被界定：

credit_limit_usd

金鑰的硬 USD 花費天花板（0 = 無上限）。

expired_time

自動到期時間戳（-1 = 永不）。一個短壽命的金鑰界定了爆炸半徑視窗。

allow_ips

把金鑰釘到已知的來源 IP——一個外洩的金鑰在網路之外毫無用處。

model_limits

把金鑰限制到特定模型，這樣它根本無法觸及最昂貴的那些。
給每個代理它自己的窄範圍金鑰，附上一個它合法情況下絕不該超過的 credit_limit_usd。這個限制是預算，而不是對攻擊者行為的猜測——即使是 一個完全被攻陷的金鑰也會停在天花板。
從主控台金鑰編輯器（或 token API）在你的工作階段下設定這一切——這些是 金鑰設定，而不是中繼呼叫。只有 /v1/* 推論請求使用 sk-orca-... 金鑰 本身。編輯限制會在金鑰的下個請求時生效；無需重新部署。

​
4. 捕捉你沒預測到的飆升：成本異常

一個靜態上限阻止的是你預期的花費。防火牆的異常偵測捕捉的是你沒預期的 花費。它對照一個週小時基線（一個 14 天滾動平均）學習每個工作區正常的 工具使用形狀，並在一個 Member 可讀的動態上浮現偏差：
異常它標記什麼
burn_spike一個工具的成本遠高於其習得的基線成本——拒絕錢包訊號。
rate_spike呼叫量遠高於基線——扇出與洪流。
retry_loop同一個工具、同樣的引數在一個緊湊的視窗內重複——經典的失控迴圈。
所以「這個工具這個小時燒掉了它通常成本的 40 倍」會凸顯出來，即使每一個 個別呼叫都被政策允許。在你調查時，你可以**暫停（snooze）**一個異常達 7 天。
異常偵測是你的早期預警；cap_cost 與 credit_limit_usd 是硬停止。 觀察該動態以發現你真正的花費住在哪裡，然後圍繞它撰寫一個上限。

​
5. 把它組合起來

把三者疊起來，讓一個失控永遠不會抵達帳單：
控制範圍何時觸發
cap_cost 規則一個代理執行執行的累計花費跨越分（cents）上限
credit_limit_usd一個金鑰，終身金鑰的總花費命中其 USD 天花板
burn_spike / retry_loop工作區，習得花費或重複模式偏離基線
一個務實的基準：對 * 的一個逐執行 cap_cost、每個代理金鑰上的一個 credit_limit_usd，以及一個檢查異常動態的習慣。先以 影子模式上線一個新的 cap_cost 政策——它記錄 [shadow] would deny 而不封鎖——這樣你就能在 它咬下去之前，對照真實流量去調整上限大小。
cap_cost 與異常動態界定的是穿越閘道的工具呼叫與執行。一個代理完全 在自己行程內執行的工具永遠不會抵達引擎。把模型中介的與 MCP 工具呼叫 透過閘道路由——並給每個金鑰一個 credit_limit_usd——這樣無論代理如何 迴圈，天花板都站得住。

​
6. 相關威脅

拒絕錢包很少單獨出現——燒掉你預算的迴圈往往是被上游的某個東西驅動的：
  • 提示注入——被注入的 指令是扇出與工具洗版的常見觸發。
  • 過度代理權——一個擁有 過多自由度的代理有更多花錢的方式。
  • 危險的工具呼叫—— 同樣的防火牆規則平面界定一個工具可以做什麼，而不只是它花多少錢。
  • 威脅模型——失控成本在完整的 代理攻擊面中的位置。

防火牆總覽

裁決、異常偵測、自主等級，以及可觀測性。

範圍金鑰與政策

金鑰限制、防護欄與防火牆政策如何逐金鑰組合。