缺乏歸因與鑑識

當一個代理出了差錯時，第一個問題總是一樣的：*它到底做了什麼，以及誰 改了那個讓它得逞的政策？*沒有軌跡你兩者都答不出來。你無法向稽核員證明 某個控制在當天有效、你無法把一次真實攻擊與一個吵雜的誤報區分開來， 而你也無法重建那次外洩了該列的執行。 OrcaRouter 邊走邊記錄答案。每一個被審查的提示詞、每一次工具呼叫、每一次 審批，以及每一次政策編輯，都會落入一份工作區範圍、可查詢的記錄——關聯回 產生它的那次代理執行與工作階段。本頁說明如何把那份記錄當成一份 ai agent audit trail 來使用：從單一可疑執行，到你交給稽核員的一份簽署報告。

​

1. 一份 ai agent audit trail 背後的四份記錄

歸因來自四條獨立的串流，每一條都關聯到同一個執行與工作階段，所以你可以 在它們之間樞轉： 連結組織是代理執行與工作階段 id。來自同一次對話的一個防護欄匹配 與一個防火牆事件攜帶相同的執行譜系，所以「這個執行遮罩了一個電子郵件、 接著試了一次我們拒絕的擷取、然後被核准做一次寫入」讀起來像一個故事， 而不是三份斷開的日誌。

​

2. 防護欄 Matches——什麼被審查了（Member）

每次一條防護欄規則觸發，閘道就寫一個匹配。這個動態住在 Guardrails 頁面（Matches 分頁），任何工作區成員都可讀。 每個匹配記錄規則型別、所採取的動作（block / mask / flag / annotate / spotlight）、介面（input / output）、一個細節 字串，以及觸發它的請求的執行譜系。把它列出、按防護欄或規則型別分組、 按動作篩選、鑽進一個匹配，或把該動態匯出成 CSV。 一條吵雜的規則也是軌跡的一部分。用 POST /api/guardrail/match/:id/mark-fp（Admin）把一個匹配標記為誤報，這樣你的 訊號保持乾淨，而你的報告不會多計。

​

3. 防火牆 Events 與 Runs——代理做了什麼（Developer+）

當 Matches 涵蓋文字時，防火牆 Events 涵蓋動作。每一次工具呼叫 評估都被記錄下來，帶有它的裁決、介面、工具名稱，以及——關鍵地——它所屬的 代理執行與工作階段。對 Events、Runs/sessions 彙整，以及逐執行追蹤的 讀取需要 Developer+；較輕的 Discovered-tools 與異常動態對每個 Member 開放。 Runs & sessions 檢視是鑑識的主力：它把事件按代理執行彙整成一個裁決 細分、該執行觸及的不同工具與模型，以及首次／最近一次出現的時間戳——一個 螢幕上「這個代理實際上做了什麼」的答案。 在靜態裁決之外，異常動態會標記偏離每個工作區習得的週小時基線 （一個 14 天滾動平均）的偏差——速率與成本飆升、retry_loop 與 novel_path 轉移——所以一個被允許但異常的模式仍會在記錄中浮現。

​

4. 審批決策——誰說了好（稽核動作）

當一條規則解析為 pending_approval 時，被保留的呼叫成為一次頻道外審查 （參見防火牆的 HITL 流程）。 那個決策是軌跡的一部分：核准或拒絕會寫一筆工作區稽核列—— firewall_approval_approve 或 firewall_approval_reject——指名那位行為者。 決策是先寫者勝出且具冪等性，而如果底層規則在保留之後變更過，豐富化資訊 會記下情境已經改變。 所以一個被保留然後被核准的工具呼叫從頭到尾完全可歸因：防火牆事件顯示 那次保留、稽核列顯示誰放行了它，而兩者都關聯到同一個執行。

​

5. 政策變更稽核——誰改了規則

一份代理行為軌跡只有在你也能證明當時的政策是什麼——以及誰改了它——時才 可信。 防護欄保留一份完整的版本歷史。每一次建立、更新與刪除都會在與變更 相同的交易中寫一筆版本控制的歷史列。在一個防護欄上開啟 History 以 看見每個版本連同作者與時間戳、比對（diff）任兩個，並回復（revert） 到一個較舊的（回復被記錄為一個新版本——歷史永不被改動）。 防火牆政策、規則與設定變更各自會在變更提交之後寫一筆工作區稽核列 ——firewall_policy_update、firewall_rule_create、 firewall_settings_update 等等——而自主等級變更 （firewall_autonomy_applied / firewall_autonomy_undone）會捕捉驅動 一鍵還原的變更前狀態快照。密鑰與規則 blob 永不被記錄。

​

6. 一個實作範例：追蹤一次可疑執行

假設一次執行因一個非預期的外送呼叫被標記。從主控台，以一個 Developer+ 工作階段： 一次執行、四份關聯記錄，無需 log-grep 考古。關於外洩防禦本身，參見 資料外洩與 危險的工具呼叫。

​

7. 簽署的合規報告——一份稽核員能驗證的軌跡

為了外部證明，Compliance 介面把這份軌跡變成一個單一成品。瀏覽框架目錄、 包與就緒度對每個 Member 開放且免費；安裝一個包、產生一份報告、 上線，以及設定資料駐留是付費方案上的工作區 Admin 動作（伺服器把關）。 一份合規報告經 Ed25519 簽署，帶有一個 SHA256 內容雜湊，並 可公開驗證——接收者無需一個 OrcaRouter 帳戶就能檢查它： 報告匯出為 CSV / JSON / PDF。框架包括 soc2、hipaa、gdpr、 iso_27001、iso_42001、nist_ai_rmf、pci_dss、EU AI Act （eu_ai_act），以及 OWASP Top 10 for LLM Applications（owasp_llm） 等等——安裝一個包會物化對應的防護欄與防火牆政策，這樣你報告的控制就是 實際強制執行的控制。

​

8. 保留與被遺忘權

一份鑑識記錄是有界的，而不是永久的。請求日誌預設保留 30 天，並被 伺服器夾制到 180 天的硬上限。當一位使用者自行刪除時，會套用一個 30 天寬限視窗，之後他們的 PII 會被清洗，而級聯會清除他們的防護欄 matches、請求日誌與防火牆事件——滿足被遺忘權／DSAR 義務，同時保持彙整的 稽核歷史完好。

​

9. 下一步去哪裡