AI Agent 沙箱的稽核日誌必須擷取命令與程序執行、檔案讀取與寫入、對外網路呼叫與出口目的地、套件安裝事件、工具呼叫、工作階段層級的模型輸入與輸出摘要、資源限制觸發，以及工作階段生命週期事件。若缺少這些涵蓋範圍，安全團隊將無法重建代理程式的行為、追蹤入侵事件，或滿足事件後檢討的要求。任何類別中的缺口都會留下難以或無法事後彌補的盲點。
為什麼 AI Agent 沙箱需要不同的稽核日誌
傳統伺服器稽核日誌假設每個動作都是由人類或確定性的應用程式程序觸發。AI Agent 打破了這個假設。單一提示可能導致一個工作階段在數秒內安裝套件、寫入檔案、執行 Shell 命令、呼叫外部 API 以及產生子程序——且這些步驟都無需人類批准。
這改變了稽核日誌需要回答的問題。對於傳統伺服器，問題通常是「經授權的使用者是否修改了這個檔案？」；對於 Agent 沙箱，問題則是：
- 模型決定執行什麼，以及依什麼順序？
- 哪些 Shell 命令被執行，以及由哪個程序執行？
- Agent 是否存取了它不應該觸碰的檔案？
- 哪些資料透過網路離開沙箱，又去了哪裡？
- 套件安裝是否引入了非預期的程式碼？
- 當 Agent 觸發資源限制或終止時，它在做什麼？
一個能夠回答這些問題的日誌系統，可以提供安全團隊所需的復原能力。無法回答的日誌系統，則只能讓事件應對人員瞎猜。
命令與程序執行日誌
程序執行是最高優先級的類別。Agent 執行的每個命令——無論是直接執行還是透過 Shell 子程序——都應產生一條日誌記錄，包含：程序名稱與完整引數列表、父程序與 PID、使用者與有效 UID、工作目錄、具有亞秒級精度的時間戳，以及退出碼。
缺少引數列表中，像 python、curl 或 bash 這類命令在事後追蹤中幾乎毫無意義。缺少 UID，就無法判斷 Agent 是否以提升的權限執行。缺少父程序 PID 鏈，就無法還原巢狀子程序或了解命令是如何被呼叫的。
像是 auditd 搭配適當的系統呼叫規則（execve、execveat）的 Linux 稽核子系統，可以在 microVM 內部客體的核心層級擷取這些資訊。基於容器的沙箱可以改用 eBPF 追蹤或 seccomp 日誌，不過每種方法都有不同的涵蓋範圍與效能權衡。從安全團隊的角度來看，關鍵要求是日誌必須在應用程式層級以下產生——一個控制自身日誌記錄的 Agent 程序，無法被信任會準確回報自己的行為。
檔案系統存取事件
檔案系統稽核應記錄讀取、寫入、刪除、重新命名及掛載操作。對於每個事件，日誌應包含：操作類型、完整路徑、負責的程序與 PID、UID，以及時間戳。
實際上，在忙碌的沙箱中記錄每次檔案讀取可能會產生大量資料。安全團隊通常會將範圍縮小至敏感路徑——例如 /etc、/root、Agent 的工作目錄、憑證檔案位置，以及已掛載的機密。對於大多數威脅模型而言，寫入和刪除的優先級高於讀取，但憑證或設定檔案的讀取無論如何都值得記錄。
檔案系統事件對於識別資料外洩嘗試（大量讀取後接對外網路呼叫）、非預期的設定變更（寫入 Agent 不該觸碰的檔案）以及清理行為（在工作階段結束時執行刪除，可能表示試圖隱藏活動）特別有用。
對外網路呼叫與出口日誌
出口日誌是 Agent 沙箱部署中最常被指定不足的領域之一。許多沙箱會記錄曾嘗試建立網路連線；但很少有沙箱記錄連線去往何處、使用了什麼協定，以及是否成功。
完整的出口日誌記錄應包含：目標 IP 位址與埠號、解析後的網域名稱（DNS 查詢與回應）、協定（TCP、UDP、HTTP 等）、各方向傳輸的位元組數、開啟連線的程序、UID，以及時間戳。
DNS 查詢日誌本身也很重要。Agent 查詢非預期的網域——即使連線後續被阻擋——是一個值得捕捉的訊號。DNS over HTTPS 可以繞過查詢日誌，除非沙箱在能夠攔截它的層級執行網路政策。
提供白名單型出口控制的沙箱應記錄允許與阻擋的連線嘗試。大量針對非預期目的地的被阻擋嘗試，本身就是一個有意義的安全訊號。
套件安裝事件
套件安裝是高度有價值的稽核目標，因為它們會以持續整個工作階段並可能影響後續操作的方式改變執行環境。每次安裝事件應擷取：呼叫的套件管理器（pip、npm、apt、cargo 等）、套件名稱、請求的版本、解析後的版本、來源 URL 或註冊表、套件雜湊值或校驗和、程序與 UID，以及時間戳。
來源 URL 很重要。從私有註冊表、直接 URL 或異常鏡像安裝的套件，與從預設公開註冊表安裝的套件具有不同的風險概況。雜湊值對於事後驗證很重要——如果某個套件後來被發現是惡意的，您需要知道在給定工作階段中是否安裝了那個確切版本。
完全阻擋套件安裝的沙箱可以消除這個風險類別，但也會嚴重限制 Agent 能做的事情。大多數生產部署需要一條中間路徑：記錄所有內容，允許從核准的來源清單安裝，並標記或阻擋來自未知來源的安裝。
工具呼叫與結果
AI Agent 通常透過工具呼叫機制運作，其中模型請求一個具名動作——執行程式碼、讀取檔案、呼叫 API、搜尋網路——然後編排層執行它。這些工具呼叫位於作業系統層級之上，是應用程式層級的事件，但它們很重要，因為它們代表了模型的意圖，而不僅僅是系統層級的結果。
工具呼叫日誌應擷取：工具名稱、輸入參數摘要（如果包含機密或使用者個人識別資訊，則不應記錄完整內容）、結果狀態摘要（成功、錯誤、逾時）、工作階段 ID，以及時間戳。
記錄每個工具呼叫的完整輸入和輸出對除錯很有用，但會帶來隱私和機密外洩風險。一個實用的方法是：無條件記錄工具名稱和狀態，以可設定的詳細程度記錄輸入/輸出摘要，並提供一種方法，在調查期間透過適當的存取控制來檢索特定工作階段的完整詳細資料。
目標是提供足夠的信號來重建 Agent 的動作序列，而不會創建一個自身成為高價值目標的日誌儲存庫。
工作階段生命週期事件
工作階段生命週期事件是所有其他日誌記錄的基礎。出現在每種事件類型中的工作階段 ID，使得跨類別連接日誌成為可能，並回答「這次執行發生了什麼事？」。
要記錄的生命週期事件：
| 事件 | 關鍵欄位 |
|---|---|
| 建立工作階段 | 工作階段 ID、使用者/租戶 ID、範本或映像檔名稱、資源設定、時間戳 |
| 開始工作階段 | 工作階段 ID、主機識別碼、分配的資源限制、時間戳 |
| 暫停工作階段 | 工作階段 ID、原因（API 呼叫、逾時、自動暫停）、時間戳 |
| 恢復工作階段 | 工作階段 ID、恢復的操作者、時間戳 |
| 終止工作階段 | 工作階段 ID、終止原因（正常、逾時、OOM、API 呼叫、政策違規）、退出狀態、時間戳 |
| 清理工作階段 | 工作階段 ID、清理時的檔案系統狀態（保留、刪除、快照已儲存）、時間戳 |
終止原因在事件發生後特別有用。因政策違規、OOM 終止或非預期的訊號而終止的工作階段（而非正常結束）值得更仔細地檢查。被暫停和恢復的工作階段值得檢查狀態連續性——在暫停和恢復之間，環境是否發生了任何變化？
資源限制事件
資源限制事件捕捉工作階段達到設定上限且系統採取行動的時刻。這些事件可能表示正常的高負載行為，或更令人擔憂的情況——失控的程序、非預期的計算爆發，或蓄意耗盡資源的嘗試。
資源限制事件的日誌記錄應包括：限制類型（CPU 節流、記憶體 OOM、磁碟配額、網路速率限制、逾時）、事件發生時的測量值、設定的限制、採取的行動（節流、終止、警告）、受影響的程序或工作階段，以及時間戳。
OOM 終止尤其值得檢查，因為它們可能表示 Agent 嘗試進行非預期的大規模計算、套件載入了異常大的資料，或存在記憶體洩漏。對於只應執行輕量級 LLM 呼叫的工作階段，如果出現 CPU 節流事件，可能表示沙箱內部還有其他程式正在執行。
結構化與非結構化日誌格式
非結構化日誌——像是 2026-06-29 10:04:00 INFO: process python started 這樣的自由文字行——雖可讀，但難以查詢、彙總或與 SIEM 或警示管線整合。對於稽核目的，它們需要解析，而當日誌格式變更時解析就會中斷。
結構化日誌——通常是 JSON 或像是 CEF 或 OCSF 這類常見的綱要格式——允許每個欄位直接被索引、查詢和觸發警示。一個結構化的 execve 事件，包含 {"ts": "2026-06-29T10:04:00.123Z", "event": "process.exec", "session_id": "...", "pid": 1234, "ppid": 1, "uid": 0, "cmd": "curl", "args": ["-s", "https://..."], "exit_code": 0}，可以透過其任何欄位立即查詢。
對於評估沙箱提供者的安全團隊來說，關鍵問題是：
- 日誌是結構化還是非結構化？
- 使用什麼綱要或格式，是否有文件說明？
- 日誌是否能即時串流到外部 SIEM 或日誌彙總系統？
- 事件發生到在日誌串流中可取得之間有多少延遲？
即時或近即時串流對於偵測使用案例非常重要。只有在工作階段結束數小時後才能取得的日誌，對於事件重建很有用，但無法用於即時警示。
日誌完整性與防篡改證據
Agent 可以修改的稽核日誌就不是稽核日誌。這是防篡改的要求：日誌的產生和儲存方式必須使 Agent 程序無法更改、刪除或抑制自己的記錄。
在實作層級，這通常意味著：
- 核心層級日誌產生（稽核子系統、eBPF），而非沙箱內部的應用程式層級記錄
- 將日誌傳送到沙箱程序無法觸及的外部目的地
- 一次寫入或僅附加的日誌儲存，沙箱網路無法存取任何刪除 API
- 日誌記錄在產生時簽署或加入校驗和，以便事後可偵測篡改或截斷
對於受管沙箱提供者來說，相關問題是 Agent 程序是否有任何途徑可以修改日誌傳遞。如果日誌被寫入沙箱內部的檔案然後傳送，那麼具有足夠權限的 Agent 程序可能能夠干擾傳送。如果日誌是在 hypervisor 或主機層級產生並帶外傳送，Agent 則無法存取。
日誌資料的監管鏈——對於合規或法律審查特別重要——要求日誌收集路徑、儲存存取控制，以及對原始事件應用的任何轉換本身都應有文件記錄且可供稽核。
AI Agent 沙箱的稽核日誌保留政策
AI Agent 沙箱稽核日誌的保留需求取決於監管環境、工作負載的風險概況，以及安全團隊需要支援的事件應對時間表。
安全團隊評估的實用起點：
| 使用案例 | 建議最低保留期限 |
|---|---|
| 進行中的事件調查 | 至少 90 天的熱儲存（可查詢） |
| 事後鑑識 | 在冷儲存中保留 12–24 個月 |
| 合規審查（SOC 2、ISO 27001） | 依適用的框架要求 |
| 法律保留 | 直到明確釋放為止 |
對於 AI Agent 工作負載，90 天的熱儲存是一個有意義的基準，因為自主代理程式中的入侵模式可能不會立即被發現——三週前在工作階段中外洩資料的 Agent，可能要到注意到下游異常時才被識別。
資料量是一個實際的成本因素。一個每天執行數千個工作階段且完整記錄 execve 和網路日誌的沙箱，可能會產生大量資料。分層儲存——熱儲存用於近期資料、溫儲存用於中期、冷儲存用於歸檔——是一種常見做法。壓縮和欄位層級過濾（僅以完整保真度記錄高優先級事件類型）也值得考慮，但取捨在於經過過濾的日誌可能會遺漏非預期的事件類型。
呈現日誌以供事件應對
收集日誌是必要但不充分的。放在無人查詢的儲存空間中的日誌無法提供保護。對於安全團隊來說，操作上的要求是能夠快速回答特定問題：
- 工作階段 X 在時間 T1 到 T2 之間做了什麼？
- 哪些工作階段存取了路徑 P？
- 哪些工作階段對網域 D 建立了對外連線？
- 哪些工作階段安裝了套件 V？
- 哪些工作階段因原因 R 而終止？
這需要一個查詢介面——無論是 SIEM 整合、日誌分析平台，還是提供者提供的 API——其中工作階段 ID、事件類型、時間範圍、路徑、網域和其他關鍵欄位都已建立索引並可搜尋。
第二層是針對特定模式發出警示。AI Agent 沙箱的高優先級訊號包括：執行已知危險命令（curl | bash、wget -O - | sh、base64 -d | sh）、對非預期或新註冊網域的對外連線、從非註冊表 URL 安裝套件、對憑證檔案路徑的寫入事件、因政策違規或 OOM 終止而結束的工作階段，以及在 Agent 不應以 root 身分執行時發生在 UID 0 下的任何事件。
針對 Agent 沙箱行為模式校準的預建偵測規則，可以縮短針對新活動發出首次警示的時間。評估沙箱提供者的安全團隊應詢問提供者是否提供偵測規則、日誌綱要文件以及範例 SIEM 整合，還是將該層的建置完全留給客戶。
應該向沙箱提供者提問的問題
在評估 AI Agent 沙箱的稽核日誌涵蓋範圍時，以下是值得向提供者提出的具體問題：
- 預設記錄哪些事件類別，哪些需要設定？
- 日誌是在核心/虛擬機監控器層級產生，還是在沙箱程序內部產生？
- 使用什麼結構化日誌格式，綱要是否公開文件？
- 日誌能否即時串流到外部目的地？
- 資料保留政策是什麼，是否可以延長？
- 沙箱程序是否有任何途徑修改或抑制自己的日誌記錄？
- 日誌記錄是否已簽署或以其他方式防篡改？
- 是否有可用的查詢 API 或 SIEM 整合？
- 是否有針對常見沙箱威脅模式的預建偵測規則或警示範本？
沒有任何沙箱部署在預設情況下就具備完整的日誌功能。提供者收集的內容與安全團隊重建事件所需的內容之間存在差距是常見的。在部署前識別這些差距（而不是在事件發生後）是這類評估的實際價值所在。
Novita Agent Sandbox 可透過其 API 提供工作階段生命週期事件、執行日誌和資源指標。評估 Novita Agent Sandbox 的安全團隊應在做出架構決策之前，先查閱產品文件以確認目前的日誌涵蓋範圍、匯出選項和保留設定。
結論
AI Agent 沙箱的稽核日誌不是你可以在事件發生後才追加的功能。那些重要的事件類別——程序執行、檔案系統存取、出口流量、套件安裝、工具呼叫、工作階段生命週期和資源限制——必須在工作負載上線前就納入範圍，且日誌收集路徑必須位於 Agent 無法觸及的地方。
安全團隊的實用檢查清單很直接：確認你的沙箱提供者預設捕捉哪些事件類別；確認日誌是在核心或 hypervisor 層級產生（而非在 Agent 程序內部）；確認有結構化輸出可用於 SIEM 整合；以及在你需要它們進行調查之前就建立保留政策。
這些領域中的任何缺口，都會削弱你回答「這個 Agent 做了什麼？」的能力——而對於大規模運作的自主代理程式來說，這個問題終究需要答案。
常見問題
** AI Agent 沙箱稽核日誌應記錄哪些事件？**
至少應記錄：命令與程序執行（含完整引數列表）、檔案系統讀取/寫入/刪除、對外網路連線與 DNS 查詢、附帶來源 URL 與雜湊值的套件安裝事件、工具呼叫與結果狀態、工作階段生命週期事件（建立、暫停、恢復、終止、清理）以及資源限制事件（CPU 節流、OOM 終止、逾時）。缺少任何這些類別都會留下事後無法重建的盲點。
** 為什麼不能依賴沙箱內部的應用程式層級日誌？**
控制自身日誌記錄的 Agent 程序可以隱藏或修改關於自身行為的記錄——無論是故意還是透過錯誤。核心層級收集（透過 auditd、eBPF 或 hypervisor 儀器）會在應用程式層級以下產生日誌記錄，而 Agent 對那裡沒有寫入權限。這就是防篡改要求：日誌必須在 Agent 無法觸及的位置產生。
** AI Agent 沙箱稽核日誌應保留多久？**
實用基準：至少 90 天的熱查詢儲存用於進行中的調查，12–24 個月的冷儲存用於事後鑑識。像 SOC 2 和 ISO 27001 這類合規框架有其自身要求，可能會覆蓋這些基準。對於法律保留，應持續保留直到法律顧問明確釋放。
** 結構化與非結構化稽核日誌有何不同？**
非結構化日誌是需要解析才能查詢的自由文字行。結構化日誌使用一致的綱要（JSON、CEF、OCSF），其中每個欄位都可直接索引和查詢。對於安全運營，結構化日誌更容易與 SIEM 平台整合、編寫偵測規則以及在事件應對中查詢。
** AI Agent 能否篡改自己的稽核日誌？**
取決於日誌的產生和儲存位置。如果日誌寫入沙箱內部的檔案然後對外傳送，具有權限的 Agent 程序可能干擾傳送管線。如果日誌是在 hypervisor 或主機層級產生，並直接寫入沙箱網路無法觸及的外部目的地，則 Agent 無法修改它們。務必驗證日誌收集架構，而不僅僅是日誌格式。
** 在沙箱提供者的稽核日誌文件中應注意什麼？**
確認：哪些事件類別預設記錄，哪些需要設定；日誌是在核心/hypervisor 層級產生還是在沙箱程序內部產生；使用什麼結構化格式和綱要；是否支援即時串流到外部系統；預設保留政策是什麼，是否可以延長；以及是否有預建的偵測規則或 SIEM 整合。
