跳轉到主要內容
一次單獨的工具呼叫可以看起來完全無害。讀取一筆 CRM 記錄:允許。 呼叫一個匯出工具:允許。擊中一個外部主機:允許。執行的形狀—— 五十次讀取,然後一次匯出,然後在週日凌晨 3 點 egress 到一個你從未 見過的主機——才是攻擊。每呼叫的裁決 孤立地判定每一次呼叫,而從不看見它。 本頁涵蓋那兩個隨時間而非一次一個呼叫地觀察一個執行的防火牆機制: 序列規則（一個由你撰寫的有序鏈）與行為異常偵測（偏離你工作區 習得的正常）。它們合在一起就是你偵測代理攻擊鏈行為的方式——沒有 任何單一的 allow/deny 規則能捕捉到。
這裡的一切都在主控台中設定（Security → Firewall）,其管理路由 使用你的工作階段／存取權杖——而非中繼 sk-orca-… 金鑰。你代理的 /v1/* 呼叫不變。

​
1. 為何每呼叫規則漏掉那條鏈

防火牆的工具 glob與 引數子句在設計上是 無狀態且確定的——它們在熱路徑上快速地決定一次呼叫。那正是你對 「封鎖 shell.exec rm -rf」所要的。它對一個每一次個別呼叫都合法的 慢燒外洩而言正好是錯的。 兩個互補的工具填補了缺口：

序列規則

一條你撰寫的規則,匹配一個時間窗口內呼叫的有序鏈——「批次讀取 → 匯出 → egress」。你為該模式命名。

異常偵測

防火牆學習每個工作區正常的工具使用形狀,並標記偏差——重試 迴圈、前所未見的工具路徑,以及量／成本飆升。無規則可撰寫。

​
2. 序列規則：為攻擊鏈命名

一條 sequence 規則像任何其他規則一樣存在於一個 防火牆政策內部,但它攜帶的 不是單一的 tool_name_glob,而是一份有序的步驟清單。每個步驟是 一個工具 glob,帶有一個可選的 min_count 與一個可選的 egress: true;步驟必須依序發生（與不相關的呼叫交錯沒問題）,而整條鏈 必須在 window_seconds 內完成。 
{
  "label": "bulk-read-then-exfil",
  "verdict": "audit",
  "sequence": {
    "window_seconds": 600,
    "steps": [
      { "match": "crm.*",   "min_count": 50 },
      { "match": "*.export" },
      { "match": "*", "egress": true }
    ]
  }
}
當一個代理讀取 50+ 筆 crm.* 記錄,然後呼叫任何 *.export 工具, 然後做任何 egress 呼叫——全都在十分鐘內——這條規則就觸發。每一次 呼叫自身都會通過;那個模式才是訊號。
一個序列是在完成它的那次呼叫上被評估的。 內聯規則迴圈會跳過 鏈規則（一次呼叫無法滿足一條多步驟鏈）;當一次呼叫可能是一條鏈的 最終步驟時匹配才執行,此時防火牆會拉取該主體的近期事件並測試 該鏈。你在規則上設定的 verdict 就是接著對完成的呼叫所發生的事: audit 記錄它並讓它通過,pending_approval 為 人工審查保留它,而 deny 封鎖 它。所以一條鏈能即時停止它的最終呼叫——挑選裁決以匹配。當你只想 偵測並提醒時用 audit;當你需要一個硬停止時用 pending_approval 或 deny（或與一條每呼叫的 deny / egress 規則搭配）。
完整的 sequence 欄位語法——window_seconds: 0 代表無時間界限、 min_count 預設值、步驟排序語意——在 規則綱要中。在主控台規則 編輯器中撰寫序列規則;儲存是一項 Developer+ 動作。

​
3. 異常偵測：偏離習得的正常

序列規則問的是「這個特定模式發生了嗎」,異常偵測問的則是「關於 這個執行的任何東西對這個工作區而言是否反常」。它不需要規則—— 防火牆從你自己的流量建立一個基線,並對照它對即時活動評分。四種會 浮現：
每（工具,金鑰）呼叫量對照這個週小時習得的基線評分。當計數 清過一個絕對底線且相對基線跑得高時,或當它的 z-score 跨越統計 門檻時,一個列就浮現。所以「週日凌晨 3 點 100 次 db.query 呼叫」 會突顯出來,即使一個週二下午 2 點同樣大小的爆發不會。
同一個想法套用於花費:一個工具燒掉它這個週小時習得基線成本的 數倍。那個拒絕錢包（denial-of-wallet）的早期警告——將它與一條 cap_cost規則搭配以強制執行一個 硬上限。
一個 (conversation, tool, arguments) 群組在一個緊窗口內重複很多 次——一個卡住的代理一遍又一遍地以相同引數呼叫同一個失敗的工具, 而非緩慢的正當輪詢。
這個工作區從未做過的一個 tool_a → tool_b 轉移。一個代理第一次 從 read_file 直接走到 http_fetch 時,那條邊就亮起來,即使兩個 工具個別都被允許。

​
週小時基線

該基線是一個按週小時（weekday × 24 + hour）分桶的 14 天滾動 平均,所以週二 14:00 是專門對照過去的週二 14:00 歷史比較——而不是 一個會沖淡你真實每日與每週節奏的全時段平均。一個尚無習得常態的 全新工作區仍會透過一個絕對底線捕捉到一次明顯的洪流,所以你從第一天 起就受到保護。
該動態回報工具名稱、遮罩過的金鑰 id、計數,以及一個 z-score—— 絕不回報原始金鑰材料。每個異常都攜帶一個建議的補救 （rate_limit、review 或 block_tool）,所以下一步是一鍵,而非 一個猜測。

​
4. 一次具體演練

假設一個被入侵的提示驅使你的代理之一進入一個緊的失敗迴圈,然後 探測一個它從未觸及過的匯出路徑。以下是你看見的——事先沒有撰寫 任何規則：
1

代理失常

被注入的指令推動代理以相同引數重試一個失敗的 db.query,然後 呼叫 report.export,接著一次外送擷取——一條這個工作區從未跑過的 路徑。
2

開啟異常動態

在 Security → Firewall → Anomalies 中,該執行浮現出一個在 db.query 上的 retry_loop,以及一個在 report.export → http_fetch 邊上的 novel_path。讀取該動態是一項 Member 動作——團隊上的 任何人都能分流。
3

在事件追蹤中確認

點進事件記錄與 執行分析,以看見精確的呼叫 序列,與該代理執行與對話相關聯。異常動態是 Member 可讀的,但 事件記錄與執行追蹤攜帶工具呼叫來源,且是 Developer+。
4

將發現轉換為一條規則

既然你已經看見那條鏈,就把它編碼:在那個危險匯出上一個 deny、在那個擷取上一個 egress 允許清單,或一條 下次稽核整個模式的序列規則。異常偵測找出未知;一條規則釘住已知。
如果在你調校時該動態很吵——譬如一個真的每週日飆升的正當批次工作 ——在你調查時將異常動態**暫停（snooze）**最多 7 天。暫停是一項 Developer+ 動作;該窗口是伺服器夾限的,所以偵測總是會自行回來。

​
5. 序列規則 vs. 異常偵測

它們解決相鄰的問題——挑選與你所知相符的那一個：
序列規則異常偵測
你撰寫精確的鏈什麼都不寫——它學習
捕捉一個已知的多步驟模式未知／反常的東西
行動將規則的裁決套用於完成的呼叫（audit / pending_approval / deny）浮現在動態上
一個成熟的工作區兩者都跑:異常偵測是浮現出你未預料到的鏈的雷達 ——只浮現,絕不封鎖;序列規則是你如何編纂你已有的那些,讓它們被 標記、被追蹤,並且（以一個 pending_approval 或 deny 裁決）能把關 完成的呼叫。對一個無論任何鏈、針對單一呼叫的硬停止,去拿一個 每呼叫的裁決。

​
6. RBAC 與動態背後的路由

異常動態與序列規則坐落在工作區防火牆管理路由之下——你的 工作階段／存取權杖,絕非一個中繼金鑰：
方法與路徑角色用途
GET /api/workspace/firewall/anomaliesMember讀取異常動態（?window=）。
POST /api/workspace/firewall/anomalies/snoozeDeveloper+暫停動態（{until},夾限到 7 天）。
POST /api/workspace/firewall/rulesDeveloper+在一個政策下建立一條序列（或任何）規則。
POST /api/workspace/firewall/testDeveloper+在你依賴它之前對照一個樣本呼叫乾跑一個政策。
對動態的讀取對每個 Member 開放,這樣整個團隊都能分流;撰寫規則與 暫停動態是 Developer+ 寫入,與防火牆 RBAC 模型的其餘部分一致。

​
接下來去哪裡

規則綱要

完整的 sequence 欄位——steps、min_count、window_seconds,以及 每個其他規則欄位。

事件記錄

匹配到的序列與異常落入的地方——按執行、介面與裁決篩選。

成本上限

將一個 burn_spike 訊號變成一個硬的每執行花費上限。

Egress 控制

在網路邊界阻止一條鏈的最終外洩步驟。
關於這些機制反制的攻擊者攻略,參見 鏈式攻擊、 資料外洩,以及 過度代理權。關於深入的 防火牆參考,參見防火牆規則。