在 AI Agent 所生成的程式碼被允許對真實系統或資料執行之前，沙箱隔離審查應驗證執行邊界、檔案系統曝露程度、程序與資源控制、網路與 DNS 策略、套件擷取行為、機密處理、日誌、產出物擷取、重設語意、人工核准點以及事件應對假設。
為什麼 AI Agent 隔離審查至關重要
傳統的沙箱審查通常始於一個問題：這個系統能否在不暴露主機的情況下執行不受信任的程式碼？AI Agent 的審查也需要這個問題，但它們還需要一份更廣泛的檢查清單，因為 Agent 所做的遠不止執行單一腳本。它們可能複製儲存庫、安裝套件、瀏覽網站、寫入檔案、呼叫 API、開啟 GUI 會話、重試失敗的命令，並將模型輸出轉化為 shell 操作。
這就改變了風險模型。一個編碼 Agent 可以像一個擁有終端機存取權的初級工程師。一個資料分析 Agent 可以像一個上傳檔案、擷取套件並匯出圖表的筆記型電腦使用者。一個瀏覽器 Agent 可以像一個擁有 Cookie、下載檔案、螢幕截圖和表單填寫操作的使用者。一個強化學習或評估 Agent 可以重複執行相同的任務上千次，這使得微小的外洩、資源或日誌缺口在規模上變得重要。
在將沙箱連接到敏感儲存庫、客戶資料、內部 API、特權憑證或生產部署系統之前，請使用下面的檢查清單來審查邊界。
執行邊界安全性
從將 Agent 工作負載與主機及其他租戶分隔開來的邊界開始。審查應該足夠明確，以便安全工程師能夠描述如果 Agent 執行惡意程式碼時會發生什麼失敗。
檢查：
- 使用了哪種隔離層：容器、微虛擬機、完整虛擬機、gVisor 風格的系統呼叫中介、Kubernetes 沙箱化，還是其他模型？
- 每個沙箱是否擁有自己的核心邊界，還是與主機共享核心？
- CPU、記憶體、檔案系統、程序表、網路堆疊和裝置存取是否與其他工作負載分離？
- 沙箱能否存取容器執行時期 socket、主機程序命名空間、主機路徑、雲端中繼服務或特權裝置？
- 瀏覽器會話、GUI 桌面、VNC 串流和程式碼直譯器是如何放置在相同的邊界內？
- 文件化的主機逃逸假設是什麼：是容器隔離、風險降低，還是更強的保證？
避免接受一個通用的「安全沙箱」陳述作為完整答案。詢問具體的隔離機制、邊界內包含什麼、邊界外有什麼，以及哪些假設仍需要補償控制。
檔案系統與掛載安全性
Agent 檔案系統需要單獨審查，因為 Agent 通常會建立、編輯和洩露檔案作為正常工作的一部分。危險的部分不僅是讀/寫存取權限；還有任務之間的意外遺留以及使用者無意分享的專案檔案隱式存取。
檢查：
- 預設檔案系統是空的、基於模板的，還是預先載入了專案檔案？
- 哪些路徑可由 Agent 寫入，哪些是唯讀的？
- 主機目錄、儲存庫掛載、SSH 金鑰、套件快取、瀏覽器設定檔或雲端設定檔是否被掛載到沙箱中？
- Agent 能否透過符號連結或 bind 掛載進入非預期的路徑？
- 檔案存取範圍是按沙箱、使用者、專案還是組織劃分的？
- 上傳的檔案是會被刪除、保留、快照，還是可供後續會話使用？
- 產生的檔案和差異在離開沙箱之前是否可被審查？
對於編碼 Agent，最安全的模式通常是一個狹窄的專案工作區、明確的產出物匯出，以及不對開發者家目錄或共享憑證儲存庫進行環境存取。
程序與資源控制
Agent 可能會意外產生 fork 炸彈、掛起建置、填滿磁碟、執行背景伺服器，或不斷重試昂貴的命令。資源控制將這些失敗轉變為有邊界的失敗。
檢查：
- 是否強制執行了 CPU、記憶體、磁碟、檔案描述符、程序數量和執行時間限制？
- 命令和會話是否有最大牆壁時鐘時間？
- 背景程序在命令完成後是否會繼續存在？
- 當沙箱停止或重設時，子程序是否會被終止？
- Agent 能否開啟監聽端口，如果可以，這些端口是否僅透過明確的預覽機制暴露？
- 大量的 stdout/stderr 日誌是否會被截斷、串流傳輸或儲存？
- 配額失敗對呼叫方可見，而不是默默地重試？
對於生產級的 Agent 工作流程，限制應作為 API 契約的一部分，而不僅僅是計費概念。安全團隊應知道當 Agent 達到限制時會發生什麼，以及失敗是否會留下部分狀態。
網路與外洩控制
網路策略是許多沙箱審查變得過於模糊的地方。有些 Agent 工作負載需要網際網路存取；其他工作負載預設不應有網際網路存取。正確的答案取決於沙箱是在執行測試、瀏覽公開頁面、擷取套件、呼叫內部 API，還是處理敏感資料。
檢查：
- 預設是否啟用對外網際網路存取？
- 是否可以按沙箱、按模板或按專案停用網路存取？
- 是否有針對網域、IP 範圍、端口或協議的外洩允許清單？
- 雲端中繼端點的存取是否被封鎖？
- 沙箱能否到達私有 VPC、內部服務、資料庫或部署系統？
- 瀏覽器流量、CLI 流量、套件管理器流量和直接 Socket 連線是否受同一策略管轄？
- 對外請求是否記錄了時間戳、目的地、程序或命令上下文以及回應狀態？
將 Agent 外洩視為建置系統外洩。如果 Agent 可以安裝套件、上傳產出物、呼叫 Webhook 或瀏覽任意網站，審查應涵蓋惡意程式碼和提示注入驅動的行為。
DNS 與套件存取風險
DNS 和套件管理器很容易被忽略，因為它們感覺像是基礎設施管道。對於 Agent，它們是執行表面的一部分。一個生成的腳本可以將資料編碼在 DNS 查詢中、擷取一個拼寫錯誤的套件，或從一個從未審查過的 URL 拉取腳本。
檢查：
- DNS 流量是否遵循與 HTTP 和 HTTPS 相同的外洩策略？
- DNS 查詢是否被記錄、過濾或強制通過受控制的解析器？
- 套件管理器預設能否到達公共註冊表？
- 套件註冊表是否被允許清單、代理、快取或鎖定？
- 安裝的套件名稱、版本、URL、雜湊值和鎖定檔變更是否被擷取？
- Agent 能否執行安裝腳本、postinstall 鉤子或任意套件建置步驟？
- 在將新依賴項持久化到模板或生產工作流程中之前，是否有審查關卡？
如果需要套件存取，最好使用鎖定版本、鎖定檔、註冊表允許清單，以及讓審查者能夠重建已下載和執行內容的日誌。
機密處理
機密通常是使沙箱邊界變得無關緊要的最快方式。如果 Agent 看到一個廣泛的令牌，它可以在不逃逸主機的情況下洩露資料。
檢查：
- 機密是否僅在任務明確需要時才被注入？
- 機密是否按沙箱、任務、儲存庫、環境和生命週期進行範圍限定？
- 機密是否可以從環境變數、檔案、shell 歷史、程序列表、日誌、螢幕截圖或瀏覽器儲存中讀取？
- 日誌和產出物在儲存或匯出之前是否被編輯？
- 是否使用短期令牌而不是長期憑證？
- Agent 能否從主機存取使用者級別的 SSH 金鑰、Git 憑證、雲端憑證、瀏覽器 Cookie 或 API 金鑰？
- 機密存取在稽核日誌中是否可見？
一個實用規則：如果人類不會將憑證貼到不受信任的建置作業中，就不要在沒有更狹窄的範圍和更強的日誌記錄下將其交給自主 Agent。
日誌與稽核軌跡
安全團隊需要的不僅僅是成功或失敗。他們需要知道運行了什麼程式碼、哪些檔案發生了變化、發生了哪些網路呼叫以及產生了哪些輸出。
檢查：
- 命令調用是否記錄了引數、工作目錄、退出代碼、開始時間和持續時間？
- 檔案讀取、寫入、刪除、上傳、下載和權限更改是否被記錄？
- 套件安裝和外部擷取是否被記錄？
- 瀏覽器操作、螢幕截圖、下載和表單提交是否在相關情況下被擷取？
- API 呼叫、工具調用以及模型到工具的轉換是否與同一會話關聯？
- 日誌是否對沙箱內部具有防篡改能力？
- 保留期限是多少，誰可以存取日誌？
對於受監管或企業級的工作流程，稽核軌跡應支援除錯和事件後重建。部分終端機會話記錄通常是不夠的。
產出物擷取與審查
Agent 會建立有用的輸出：差異、測試結果、報告、螢幕截圖、生成的檔案、預覽 URL 和資料集。產出物處理應使這些輸出可審查，而不會暴露比所需更多的狀態。
檢查：
- 哪些產出物會自動匯出，哪些需要明確選擇？
- 審查者能否在生成檔案被提交、上傳或發送到另一個服務之前檢查它們？
- 產出物是否會掃描機密、惡意軟體、不安全的檔案類型或意外大小？
- 瀏覽器下載是否與原始碼差異和測試輸出分開儲存？
- 產出物能否連結回產生它們的確切命令、Agent 步驟和沙箱會話？
- 產出物在沙箱刪除後是否保留，能否被清除？
目標是保留有用的證據，同時避免通過日誌、螢幕截圖、存檔或生成的捆綁包形成第二個資料洩漏通道。
生命週期與重設控制
Agent 會話可以是短暫的、長時間執行的、暫停的、恢復的、快照的，或從模板複製的。每種生命週期模式都會改變邊界。
檢查：
- 每個沙箱是全新建立、從狀態恢復還是從模板複製？
- 哪些資料在暫停、恢復、快照、模板建立和刪除後仍然存在？
- 臨時檔案、套件快取、shell 歷史、瀏覽器 Cookie 和本地資料庫在重設時是否被清除？
- 被入侵的會話是否會污染可重複使用的模板？
- 是否有最大會話生命週期？
- 已停止的沙箱是否真的終止了，還是背景任務可以繼續？
- 同一個任務能否從乾淨的環境中重現？
可重設性對於評估和強化學習工作負載也很重要。如果每個試驗從略有不同的狀態開始，安全發現和模型行為將更難信任。
人工核准控制
人工核准不僅僅是一個 UX 功能。它是一個用於跨越信任邊界操作的控管層。
檢查：
- 哪些操作可以自主執行，哪些需要核准？
- 核准提示是否足夠具體，以顯示命令、檔案、目的地、憑證範圍和預期效果？
- 策略是否可以要求對套件安裝、外部網路存取、儲存庫寫入、部署命令或機密存取進行核准？
- 核准是否記錄了使用者、時間戳、操作和產生的命令？
- 核准是否可以限時和限任務，而不是授予廣泛的未來權限？
- 是否有緊急存取路徑，並且是否被稽核？
將人工核准用於不可逆或高影響的操作：刪除檔案、寫入生產分支、呼叫部署 API、存取客戶資料以及更改沙箱模板。
事件應對假設
沒有沙箱審查是完整的，除非考慮到當邊界失敗或工作流程行為異常時會發生什麼。這對於 Agent 系統尤其重要，因為風險行為可能是由模型輸出、提示注入、依賴項妥協或普通軟體錯誤引起的。
檢查：
- 當沙箱被懷疑洩露資料或執行惡意程式碼時，誰負責分級處理？
- 沙箱能否按專案或組織被終止、隔離或封鎖？
- 能否快速停用網路外洩？
- 日誌和產出物是否為調查而保留？
- 受影響的模板、套件快取和快照是否被作廢？
- 憑證是否自動輪換，還是通過文件化的操作手冊？
- 沙箱容器隔離問題與 Agent 策略問題之間是否有明確區別？
審查應以書面威脅模型和簡短的操作手冊結束。即使最終決定是「僅批准用於非敏感工作負載」，這個邊界仍然有用。
Novita Agent Sandbox 如何適用
Novita Agent Sandbox 專為 AI 生成的程式碼、瀏覽器工作流程、電腦使用、評估、強化學習環境和長時間運行的任務而設計。產品頁面描述了隔離的沙箱、亞秒級啟動、持久會話、基於 VNC 的即時會話查看、按使用量計費、模板和隔離的檔案系統支援。Novita Agent Sandbox 快速入門 展示了基於 SDK 的沙箱建立、命令執行、檔案列表和沙箱關閉。
這些功能可以支援這份檢查清單中的許多工作流程，但評估標準和產品聲明應保持分開。當您的團隊審查 Novita Agent Sandbox 或任何其他 Agent 執行時期時，請將您計劃使用的即時配置對照上述控制項進行映射：邊界、檔案、程序限制、網路、DNS、套件擷取、機密、日誌、產出物、生命週期、核准和事件應對。
對於已經使用 Novita AI 模型 API 的工程團隊，將模型推理與沙箱執行配對可以減少 Agent 工作負載的平台擴散。對於安全敏感的生產使用，仍然需要在將沙箱連接到私有儲存庫、敏感資料集、內部服務或部署憑證之前，進行特定工作負載的審查。
結論
只有在審查能夠清楚回答三個問題之後，才能批准一個 AI Agent 沙箱：什麼被隔離了，什麼仍然可以離開邊界，以及如果出現問題會留下什麼證據。如果這些答案含糊不清，請將沙箱限制在非敏感工作負載，直到缺失的控制項被記錄和測試。
常見問題
安全團隊在 AI Agent 沙箱審查中應首先驗證什麼？
從執行邊界、檔案系統暴露程度和網路預設值開始。這三個控制項決定了在您進入核准和產出物匯出等工作流程特定細節之前，惡意程式碼能否到達主機、敏感檔案或外部目的地。
僅容器沙箱對於自主編碼 Agent 足夠嗎？
這取決於工作負載及其可以存取的資料。對於低敏感度任務，如果具有緊密的掛載、嚴格的外洩策略、短暫的憑證和強大的日誌記錄，容器可能是可以接受的，但安全團隊應根據文件化的控制項而不是僅憑「容器」這個詞來做出決定。
為什麼 DNS 和套件存取應與一般外洩分開審查？
因為 Agent 通常會安裝依賴項並解析外部主機作為正常操作的一部分。如果沒有記錄、過濾或限制，DNS 查詢和套件擷取可能成為資料外洩路徑和供應鏈風險。
推薦文章：
