跳轉到主要內容
當一個代理在十幾個 MCP 工具間放任奔跑時，事後重要的 問題從來不是「這一個工具安全嗎」——而是「代理實際呼叫了什麼、 防火牆決定了什麼，以及哪一條規則促成那次呼叫」。OrcaRouter 從一個地方回答這件事：mcp 稽核 日誌。MCP 閘道在 mcp 表面上 評估的每一次 tools/call 都會落為一個防火牆事件——裁決、 工具、匹配的規則，以及發出它的那個代理執行——所以你可以即時監控一個 工作階段，或之後重建它。 本頁是閱讀那條軌跡的聚焦操作指南。關於閘道 本身、裁決詞彙與規則 DSL，請見 防火牆與 防火牆：MCP 伺服器。
這裡的每一個讀取都從主控台（或使用你的 工作階段／存取權杖透過 REST API——UserAuth）設定，並受角色控管。只有 /v1/* 轉送呼叫與防火牆閘道路由才攜帶一個 sk-orca-... 形式的 金鑰。

​
1. mcp 稽核日誌記錄什麼

每一次 MCP 工具呼叫都會在 mcp 表面上產生一個防火牆事件。 該事件攜帶你回答「誰呼叫了什麼，以及政策做了什麼」所需的—— 以及不該攜帶的都不攜帶（工具引數會被隱去，見 §4）。
verdict（allow / audit / deny / sanitize / pending_approval / observe）、 surface（這裡是 mcp）、policy_name、rule_label，以及一個人類可讀的 reason。一個 quarantine 旗標標記一個因所屬 技能處於隔離模式而被保留的呼叫。
tool_name（命名空間化的 <server>.<tool>）、當該呼叫 可歸因於一個已註冊技能時的 skill_name、model_name 與 token_name。
agent_run_id、conversation_id 與 request_id——你用來 把一個工作階段的呼叫分組，或從一個請求鑽研到它 扇出的每一次呼叫的鍵。
一個 gap 旗標標記一個你附加的政策看見但 沒有匹配任何規則的 observe 模式呼叫——探索到的工具視圖用來 浮現你的政策尚未涵蓋的工具的訊號。

​
2. 閱讀動態

主控台中的 Events 分頁是主要視圖。要以程式方式 拉取同樣的資料，用你的存取權杖列出事件並篩選到 mcp 表面： 
# 主控台路由（UserAuth）。讀取事件需要 Developer+。
curl "https://api.orcarouter.ai/api/workspace/firewall/events?surface=mcp&verdict=deny,pending_approval" \
  -H "Authorization: Bearer <your-access-token>"
verdict 篩選器接受一個單一值或一個逗號分隔的集合（上面 的「拒絕 + 保留」預設）。一個範例事件： 
{
  "created_at": 1700000000,
  "surface": "mcp",
  "tool_name": "github.create_issue",
  "verdict": "deny",
  "policy_name": "Coding agent",
  "rule_label": "no writes to prod org",
  "reason": "rule matched: no writes to prod org",
  "agent_run_id": "run_8f3a",
  "model_name": "claude-sonnet-4-5",
  "token_name": "ci-agent"
}
要重建一個請求的完整扇出——模型在一個單一轉送請求下 呼叫的每一個工具——依 request id 鑽研： 
curl "https://api.orcarouter.ai/api/workspace/firewall/events/by-request/<request_id>" \
  -H "Authorization: Bearer <your-access-token>"
若要一個工作階段層級的彙總而非原始列，擊中 GET /api/workspace/firewall/events/aggregate?group_by=run（或 group_by=session）——每個代理執行一列，帶有每裁決的分解、 不同工具，以及首見／末見。trace 端點 （/trace/runs、/trace/by-run）會重建該執行的呼叫樹。

​
3. 伺服器治理稽核列

每次呼叫的事件告訴你代理做了什麼。第二條較小的軌跡 告訴你你對一個伺服器的治理做了什麼——而它就是 rug-pull 故事所在之處。當一次探測發現一個已註冊伺服器的 所公告工具集已漂移，而一位 admin 重新建立基準或隔離 它時，那個決策會被寫入工作區稽核日誌：
稽核動作寫入時機
firewall_mcp_schema_changed一次探測發現即時工具集從核准的那個漂移。
firewall_mcp_schema_approved一位 admin 重新建立至新工具集的基準。
firewall_mcp_schema_quarantined一位 admin 隔離（並停用）一個漂移的伺服器。
每一列攜帶伺服器 id、name 與工具計數——永不攜帶工具 引數或憑證。這是 Rug-pull 防禦 背後的鑑識軌跡：一個你週一核准的伺服器無法在週五悄悄 長出一個 shell.exec 工具而不在這裡留下一列。
防火牆政策、規則與設定變更會在這些之外 寫入它們自己的稽核列。當一位平台 admin 做出該變更時，它 也會落入中央 admin 稽核日誌 （GET /api/admin/audit-logs，僅限 admin）；一個一般成員的編輯則停留在 工作區軌跡中。

​
4. 引數預設被隱去

事件串流被建來能被你的團隊閱讀而不洩漏 密鑰。工具呼叫引數永不會被逐字儲存——一個事件至多攜帶 一個受上限約束的、被隱去的 args_summary，而用於異常分組的 原始引數雜湊永不離開伺服器。
因為事件攜帶那個淨化過的引數快照，事件、 彙總與 trace 端點被門檻為 Developer+——一個 Viewer 角色的 成員可以讀取政策與探索到的工具，但不能讀取 另一個成員的工具呼叫來源。據此規劃你的角色。

​
5. 即時監控：異常

事後閱讀是其中一半；另一半是在它發生時 被告知。異常動態會監看 MCP（與每一個其他表面）以發現 偏離工作區學習而來的基準的行為——對照一個按週小時的 剖析的速率與成本尖峰、重試迴圈與新穎的工具路徑—— 並浮現它們，而你無需撰寫一條規則。 
# 異常動態對任何 Member 開放。
curl "https://api.orcarouter.ai/api/workspace/firewall/anomalies?window=5m" \
  -H "Authorization: Bearer <your-access-token>"
一個嘈雜的訊號可以被打盹（最多 7 天），讓它停止 擠滿動態而不被永久靜音。異常讀取對 Member 開放—— 比事件串流更廣——因為它攜帶訊號，而非引數。
把該動態與 shadow 模式搭配：把一個收緊的 政策作為僅稽核推出、在事件串流中觀看本應發生的拒絕 （reason 前綴 [shadow] would …），並在該動態安靜後提升它。

​
6. 保留與抹除

防火牆事件會自動到期——它們不是一個永久儲存，它們是 一個滾動的監控窗口。工作區稽核列（§3中的 伺服器治理軌跡）保留最多 180 天。 而當一個使用者被刪除時，grace-then-scrub 循環會層層串連穿過 防火牆事件與匹配，所以一個離開的使用者的工具呼叫軌跡不會 留存。
資料駐留與保留控制位於 合規性平面。mcp 稽核日誌 繼承工作區的保留姿態；你不會 逐伺服器設定它。

​
7. 下一步去哪裡

MCP 安全總覽

整個 MCP 治理表面——閘道、裁決、技能、egress。

Rug-pull 防禦

§3 中的漂移事件，端到端：偵測、重新建立基準、隔離。

允許清單 MCP 工具

把稽核日誌顯示的內容轉成一個預設拒絕的政策。

防火牆：MCP 伺服器

完整的欄位與路由參考。
初次接觸這個模型？請見 OrcaRouter 如何審查以了解 事件在評估路徑中於何處發出，以及 過度代理權以了解一條 乾淨的稽核軌跡幫你及早抓住的威脅。