跳轉到主要內容
當你的防火牆政策判定一次工具呼叫時,它 會寫一列。事件動態就是那條運行的記錄:每一次評估一筆記錄,攜帶 裁決、它觸發的介面、工具、原因,以及它所屬的執行/工作階段。它是你 如何回答你發布一個政策後唯一重要的問題——防火牆是否真的做了我 認為它做的事,在我認為它做了的那些呼叫上? 這是你的 AI 防火牆記錄介面。每一個 allow、每一個 deny、每一個 被保留的審批、每一個影子模式的「本會」都落在這裡,可篩選並關聯回 產生它的代理執行。
事件動態是 Developer+ 才能讀取。每一列保留一個有上限的 args_summary 欄位給一個工具呼叫引數快照,所以這個介面坐落在 Member 可讀的那些（設定、政策、discovered tools、 異常動態）之上。從主控台設定這一切—— 這些是工作階段驗證的路由,而非中繼呼叫。

​
1. 什麼落入事件動態

引擎執行的每一次評估都被記錄——不只是封鎖。一個 allow 與一個 audit 會像一個 deny 一樣留下一列,所以該動態是一條完整的軌跡, 而非一個例外記錄。 一列上的裁決是代理實際看見的那個：
裁決意義
allow / audit讓通過;audit 把它標記為你想觀察的某個東西。
deny被封鎖——inbound 為 firewall_blocked（HTTP 400）、mcp 為工具錯誤。
sanitize被轉送,匹配到的子字串從呼叫的引數中遮罩。
pending_approval為一個人類保留;該列標記該呼叫被把關。
observe沒有政策匹配——一個觀察模式的涵蓋缺口。
你絕不會在動態中看見一個字面的 cap_cost。一條 cap-cost 規則在評估時解析為一個 具體的 allow 或 deny,而那才是被記錄的——該執行實際經歷的裁決。
在影子模式下,強制執行的 裁決被降級為 audit,原因加上前綴 [shadow] would …,所以該動態 精確顯示一個政策在你將它切換為即時之前會封鎖什麼。

​
2. 每個事件記錄什麼

一個單一事件是一個反正規化的快照——足以重建該決定而無需聯結回 任何東西：
verdict、surface（inbound / response / mcp / egress）、 tool_name,以及一個人類 reason（「destructive shell command」、 「egress to 169.254.169.254 denied」）。當匹配到的規則有一個標籤時, policy_name 與 rule_label 指名觸發的確切規則——所以該列直接 指回你寫的那一行。
request_id 把事件聯結到請求記錄;conversation_id 把一個多回合 工作階段分組;agent_run_id（帶有 step_id / parent_step_id） 把它繫到一個完整的代理執行與請求該工具的 LLM 呼叫。這些就是讓 該動態成為一條追蹤、而非一份扁平清單的東西——參見 §4。
token_name、model_name,以及呼叫者 ip——呼叫背後的金鑰、 模型與來源。當呼叫可歸因於一個技能 時,skill_name 指名擁有它的技能,而 quarantine 標記一次技能 隔離保留。
args_summary 是那個有上限的工具呼叫引數快照欄位（這個介面是 Developer+ 的原因）。在一個 egress 事件上,egress_host 記錄 被判定的外送目的地。
args_summary 是有上限的——原始引數位元組絕不逐字寫入動態,而 支撐異常偵測的 retry-loop 分組雜湊是僅伺服器的:它絕不在 API 中 出貨。

​
3. 一個具體範例

你的代理發出了一個帶有 rm -rf /data 的 shell.exec 呼叫、一條 deny 規則捕捉了它,而你想看見那一個決定。按裁決與工具篩選動態： 
# Developer+ console session — GET /api/workspace/firewall/events
curl https://api.orcarouter.ai/api/workspace/firewall/events?verdict=deny&tool=shell.exec \
  -H "Authorization: Bearer $ORCA_CONSOLE_TOKEN"

{
  "events": [
    {
      "verdict": "deny",
      "surface": "response",
      "tool_name": "shell.exec",
      "reason": "destructive shell command",
      "policy_name": "agent-baseline",
      "rule_label": "block destructive shell",
      "model_name": "gpt-4o",
      "token_name": "prod-agent",
      "agent_run_id": "run_abc",
      "request_id": "req_…"
    }
  ],
  "total": 1
}
主控台把同樣的列渲染為一個可篩選的表格——你很少手動打這個路由。 從事件檢視設定篩選、鑽入一個執行,並匯出;上面的 curl 只是用來顯示 形狀。
$ORCA_CONSOLE_TOKEN 是你的工作階段／存取權杖,而非一個 sk-orca-… 中繼金鑰。/api/workspace/firewall/* 路由是主控台驗證 且角色把關的;只有 /v1/* 流量使用一個中繼金鑰。

​
4. 按執行與工作階段關聯

每個事件攜帶 agent_run_id 與 conversation_id 的原因,是讓你能 停止孤立地看待呼叫,並開始問這個代理在它整個執行中做了什麼：
篩選它回答的問題
run_id=<run>一個代理執行中的每個裁決——完整的動作軌跡。
session_id=<conv>一個多回合對話中的每個裁決。
verdict=deny,pending_approval一個查詢中的「什麼被停止或保留」檢視。
surface=egress只有外送目的地的決定——外洩透鏡。
事件清單也接受 since / until（unix 秒）與 limit / skip 用於 分頁。對於彙整檢視——每執行或工作階段一列,帶有每裁決細分、 不同的工具與模型,以及首次／最近一次出現——主控台讀取 GET /api/workspace/firewall/events/aggregate?group_by=run（或 group_by=session），而代理追蹤樹讀取 /trace/by-run。兩者都是 Developer+,與原始動態相同。
從請求記錄抽屜你可以向另一個方向樞轉: GET /api/workspace/firewall/events/by-request/:request_id 傳回在單一 請求下捕捉的每個防火牆事件——當一個請求跨介面絆到數條規則時很方便。

​
5. 保留與抹除

防火牆事件攜帶它們自己的保留期限——一個 30 天預設,伺服器夾限 到一個 365 天的硬上限。每個事件以一個到期時間寫入,並由一個 TTL 索引自動老化淘汰;動態中沒有東西活過你的保留設定。 一個抹除權請求也 在這裡層疊:刪除一個使用者啟動一個 30 天寬限期,之後他們的 PII 被 擦除,而他們的防火牆事件與同範圍的請求記錄和防護欄匹配一起被清除。

​
接下來去哪裡

裁決

動態中的每個裁決實際對該呼叫做了什麼。

影子模式

在你強制執行之前以「本會」模式讀取動態。

介面與介面層

surface 欄位指名的四個介面。

防火牆參考

完整的政策、規則與 API 參考。
關於這些記錄幫助你當場捕捉的威脅,參見 資料外洩與 危險的工具呼叫。關於 防火牆如何與提示/回應文字審查搭配,參見 防火牆 + 防護欄。