跳轉到主要內容
靜態的防火牆規則捕捉你知道要指名 的呼叫。它們無法捕捉那個個別被允許但在總和上錯誤的呼叫——週日 凌晨 3 點 200 次 db.query 呼叫、一個在緊迴圈中敲打一個失敗工具的 代理、一個這個工作區從未做過的工具到工具跳轉。每一次呼叫都通過 每一條規則;那個模式才是問題。 防火牆異常偵測是那個行為層。閘道學習你工作區正常的工具使用 形狀,並對照它對即時活動評分,在一個任何 Member 都能讀取的動態 上浮現那些偏差。它是你如何在沒有為一個你從未見過的形狀預先寫一條 規則的情況下,注意到一個被入侵的代理或一個失控的迴圈。本頁是針對 那個 firewall anomaly detection 動態的聚焦著陸點; 防火牆總覽是深入參考。
異常動態是偵測,而非強制執行。它告訴你什麼看起來不對勁——它 不封鎖。當一個模式是真實的,你把它變成一條規則 或一個限速的裁決,這樣下一次 發生會被內聯阻止。讀取該動態對每個 Member 開放;把一個發現變成 政策是 Developer+。

​
1. 防火牆異常偵測標記什麼

四種訊號類型,各自繫於一個不同的失效模式：
每工具呼叫量對照一個習得的週小時基線評分。當一個工具的計數 清過一個絕對底線且相對那個小時的基線跑得高時,或當它的 z-score 跨越門檻時,它觸發 rate_spike。以週小時（而非日小時） 設鍵意味著週二 14:00 是對照過去的週二 14:00 比較,所以正當的 平日高峰流量不會讀作一次飆升,而週日凌晨 3 點同樣的量則會。
同一個週小時比較,套用於累計成本而非呼叫計數。一個花費遠 超過它習得成本常態的工具會浮現為一個 burn_spike——一個代理在 它具破壞性之前就昂貴的早期警告訊號。
一個 (conversation, tool, arguments) 群組在一個短窗口內重複很多 次——一個卡住的代理一再重發同一個失敗的工具呼叫而非復原。緩慢、 正當的輪詢不會絆到它;訊號是一個緊迴圈。
一個這個工作區沒有習得基線的 tool_a → tool_b 連續轉移。一個 代理第一次走,譬如,crm.read → http.fetch,那條邊是新穎的——正是 一個資料外洩鏈會採取 的那種步驟。
異常偵測與序列規則互補。 一條序列規則匹配一個你事先定義的鏈;novel_path 標記一個你沒有 定義的轉移——它是你如何發現值得為之撰寫一條序列規則的鏈。

​
2. 14 天基線

偵測器不是一個固定門檻——它是一個習得的常態。對每一個 (tool, hour-of-week) 桶,閘道保留一個滾動的預期呼叫計數與成本, 從一個 14 天回看回填（每個週小時桶約兩次出現——足以平滑一個 單一的奇怪日子而不失去每週形狀）。novel_path 使用平行的轉移基線: 那個週小時中每條 tool_a → tool_b 邊的習得出現計數。 一個全新的工作區尚無基線。那沒問題:沒有習得常態時,量偵測器 回退到一個絕對底線,所以一次明顯的洪流仍會在第一天被捕捉,同時 每小時的常態填補進來。
訊號它從什麼學習
rate_spike / burn_spike每 (tool, hour-of-week) 計數與成本,14 天滾動。
novel_path每 (tool_a → tool_b, hour-of-week) 轉移計數。
retry_loop無基線——(conversation, tool, args) 上一個窗口化的重複門檻。
該動態只回報工具名稱、遮罩過的權杖 id 與計數。一個原始 API 金鑰 id 絕不出現——每個項目攜帶呼叫權杖的一個單向摘要,所以你能分辨兩個 異常而動態絕不洩漏它們背後的金鑰。

​
3. 一次具體讀取

假設一個代理金鑰開始迴圈。在主控台中於 Security → Firewall → Anomalies 下拉取動態,或直接讀取它——任何 Member 都可以： 
curl https://api.orcarouter.ai/api/workspace/firewall/anomalies \
  -H "Authorization: Bearer $ORCA_SESSION_TOKEN"

{
  "data": {
    "items": [
      {
        "id": "3f1c9a7b0e2d4a86",
        "kind": "retry_loop",
        "tool_name": "db.query",
        "token_id_redacted": "sk-***-9f2a",
        "count": 412,
        "baseline": 0,
        "z_score": 0,
        "suggested_action": "rate_limit",
        "first_seen": 1749470400,
        "last_seen": 1749470520
      }
    ],
    "snoozed_until": 0
  }
}
一個 retry_loop 項目不攜帶 baseline 或 z_score（那些欄位保持 0——它們屬於量／成本偵測器）,而它攜帶一個穩定的不透明 id,這樣 同一工具上的兩個不同迴圈不會在一列上相撞。一個 rate_spike 則相反: 它回報一個習得的 baseline 與一個 z_score,並讓 id 為空。
$ORCA_SESSION_TOKEN 是你的主控台工作階段／存取權杖——與每個 /api/workspace/firewall/* 管理路由相同的 auth。它不是一個中繼 sk-orca-… 金鑰（那些只給 /v1/* 模型呼叫）也不是一個防火牆 閘道金鑰。一個中繼金鑰在這個路由上會被拒絕。
每個項目指名工具、遮罩過的權杖、觸發了多少次呼叫、z-score（僅量／ 成本訊號）,以及一個 suggested_action（rate_limit、block_tool, 或 review）。從這裡你行動:在該工具上放一條 deny 規則、 驗證它的引數,或開啟 事件記錄以精確看見代理做了 什麼。

​
4. 暫停動態

一個已知的負載測試或一個計畫中的回填會點亮動態。與其追逐噪音,不如 暫停它——最多 7 天： 
curl -X POST https://api.orcarouter.ai/api/workspace/firewall/anomalies/snooze \
  -H "Authorization: Bearer $ORCA_SESSION_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"until": 1749643200}'
當一個暫停作用中時,動態傳回無項目並回報 snoozed_until;它在期限 通過的那一刻自行清除。該上限是一個硬天花板——一個手誤的或惡意的 更遠的 until 會被夾限,這樣異常偵測無法被無限期靜音。POST 一個 過去或當下的 until 會清除一個既有的暫停。
讀取動態是一項 Member 動作;暫停它是 Developer+——把一個 工作區範圍的安全訊號靜音是一個寫入,而非一個讀取。

​
5. RBAC 一覽

分析介面沿著一般的讀取/行動線分裂：
動作角色
讀取異常動態Member
讀取設定、政策、discovered toolsMember
暫停動態Developer+
Events、runs、aggregate、traceDeveloper+
從一個發現撰寫一條規則Developer+
較輕的彙整檢視——設定、政策,以及 discovered-tools 涵蓋地圖——也是 Member 讀取;列層級的事件與執行 細節是 Developer+,因為它攜帶每呼叫的引數資料。

​
6. 從訊號到政策

該動態是一個迴圈的開始,而非結束：
1

發現模式

一個 novel_path 或 rate_spike 顯示一個你未預期的形狀。對照 事件記錄讀取它以確認它是 真實的,而非一次性的。
2

撰寫規則

把發現變成強制執行——一個封鎖、 一個引數子句、一條 針對該鏈的序列規則,或 針對該燒費的一個成本上限。
3

安全地推出

先在影子模式下落地該規則, 這樣你能在它封鎖任何一次呼叫之前衡量它的波及範圍,然後強制執行。

​
接下來去哪裡

防火牆總覽

完整的異常偵測參考與政策平面的其餘部分。

事件記錄

從一個異常鑽入它背後的確切呼叫。

封鎖一個工具

把一個發現變成一條強制執行的規則。

強制執行模式

偵測、audit、影子與強制執行如何契合在一起。
關於這些訊號暴露的威脅,參見 資料外洩與 過度代理權。