沙盒隔離模型
AI 代理沙盒中的「隔離」是什麼意思？
隔離代表代理的程式碼、檔案、程序與網路存取都被限制在一個有邊界的環境中，無法影響主機系統或其他租戶。實務上，隔離是一個光譜：程序層級隔離使用 OS 原語（namespaces、cgroups、seccomp）來限制系統呼叫與資源存取；容器隔離則額外加上檔案系統與網路命名空間邊界；微型虛擬機隔離則將工作負載包裹在輕量級虛擬機中，擁有自己的客體核心。每往上一層，邊界強度都會增加，但代價是啟動延遲與操作複雜度較高。詳細評估框架請參閱 Firecracker 用於 AI 代理沙盒。
Docker 是否足以執行代理產生的程式碼？
容器提供可重複的映像檔與良好的資源控制，但同一主機上的所有容器共用同一個主機核心。核心漏洞或繞過 seccomp 過濾器的系統呼叫可能影響其他工作負載。對於低風險、短時任務且執行可信或接近可信的程式碼時，在正確強化（無特權模式、最小能力、不掛載 Docker socket、盡可能使用唯讀根檔案系統）的情況下，容器通常足夠。但對於可能安裝套件、產生子程序或呼叫任意 shell 指令的不可信 AI 產生程式碼，則值得評估更強的邊界。實際選擇取決於您的威脅模型。各隔離層級的驗證檢查清單請參閱 AI 產生程式碼沙盒：生產應用程式的要求。
容器隔離與微型虛擬機隔離有何不同？
關鍵差異在於核心邊界。容器共用主機核心；微型虛擬機則在輕量級虛擬機內各自執行客體核心，並以硬體虛擬化（KVM）為後盾。使用 Firecracker 等技術的微型虛擬機沙盒能提供 VM 型邊界，卻沒有傳統 VM 的完整開銷：啟動延遲設計快速，裝置模型最小化以減少攻擊面，且客體與主機核心天生隔離。實務上，核心漏洞在客體中不會自動影響主機或其他客體，而在共用核心的容器模型中則可能發生。關於微型虛擬機邊界在哪些方面有幫助、哪些方面無法解決全部問題，請參閱 Firecracker 用於 AI 代理沙盒。
每個沙盒是對應一個代理、一個用戶，還是一個任務？
這取決於平台與應用程式設計。多租戶應用程式最安全的模式是每個代理執行或每個任務使用一個獨立的沙盒環境——也就是每個用戶的工作階段擁有自己的程序樹、檔案系統、網路命名空間與憑證範圍。跨用戶或跨不相關任務共用沙盒是生產代理應用程式中狀態外洩最常見的來源。評估平台時，請確認並行工作階段在檔案系統、程序與網路層級都受到隔離，而不僅是 API 路由層級。各工作階段隔離的檢查清單請參閱 AI 產生程式碼沙盒：生產應用程式的要求。
沙盒出口流量與網路政策
AI 代理能否從沙盒發出對外網路呼叫？
這取決於沙盒的出口政策。預設情況下，許多沙盒允許對外連線，這對網路研究、API 呼叫與套件安裝很方便。但對於執行不可信程式碼的生產工作負載，預設開放出口是風險：受損或行為異常的代理可能外洩資料、存取內部中繼服務，或從任意 URL 拉取未預期的程式碼。更強大的生產姿態是預設拒絕出口，並設定明確的允許目的地清單。無論您選擇哪種政策，都應明確記錄並留下稽核記錄。如何評估網路控制請參閱 Firecracker 用於 AI 代理沙盒。
沙盒中的 DNS 如何控制？
DNS 是出口政策中常見的缺口：HTTP 目的地的允許清單並不會自動限制 DNS 解析。能夠解析任意網域名稱的代理可以推斷網路拓撲、探測內部名稱，或在 HTTP 被封鎖時將 DNS 用作側通道。為了有一致的出口政策，DNS 解析應一併處理——要嘛指向一個尊重允許清單的內部解析器，要嘛限制解析範圍僅限於已核准的網域。請向您的沙盒提供者確認 DNS 如何與整體出口政策搭配。
在網路受限的工作階段中，如何控制套件擷取？
套件安裝屬於網路操作。如果出口限制為僅允許清單，則該清單必須包含代理合法需要的套件註冊表，否則沙盒應在信任網路內提供拉取快取。拉取快取的額外好處是作為檢查點：您可以查看擷取了哪些套件、捕捉到非預期的相依性，並減少重複的出口流量。有些團隊在重視可重複性勝過靈活性的工作負載中使用預先烘焙的沙盒模板，這能完全消除執行階段的套件擷取。關於管理執行階段安裝的更多資訊，請參閱套件安裝一節。
檔案存取與主機檔案系統
沙盒中的代理擁有什麼檔案存取權限？
沙盒中的代理只能存取明確掛載到其工作空間的檔案。對於程式碼代理，可能包括一個檢出的儲存庫和一個用於產生成品的目錄。對於資料分析代理，可能是一個上傳的 CSV 檔案和一個輸出資料夾。代理不應能存取主機檔案系統、其他租戶的工作空間、應用程式伺服器的機密，或其掛載路徑之外的系統目錄。最佳實踐是將來源材料以唯讀方式掛載，並提供一個單獨的可讀寫輸出目錄給產生的成品。關於如何為每個工具設定檔案系統掛載範圍，請參閱 MCP 伺服器沙盒：具備檔案系統、機密與網路控制的隔離 MCP 伺服器。
從沙盒內部能否存取主機檔案系統？
不應該。正確設定的沙盒（容器或微型虛擬機）會將代理的視野限制在自己的客體檔案系統內。從沙盒內部存取主機檔案系統是一種設定失敗，而非預期行為。破壞此邊界的常見錯誤包括掛載寬泛的目錄（如開發者的家目錄或 /）、在容器中使用特權模式，或將 Docker socket 掛載進沙盒。在評估平台或自行建置時，請確認掛載了什麼、根檔案系統的權限為何，以及符號連結逃脫或壓縮檔解壓縮技巧是否能到達預期工作空間以外的路徑。
工作階段結束後，檔案會如何處理？
對於臨時工作階段，工作目錄與所有產生的檔案在工作階段終止時會被銷毀。這是程式碼補全、評估執行以及任何重視可重複性勝於連續性之任務的正確預設值。對於持久性工作空間（長時間執行的程式碼代理、疊代開發工作階段），檔案可以在同一工作階段內跨執行呼叫存活，如果平台支援工作空間持久化或快照，也可能在工作階段結束後保留。需要回答的關鍵問題是：保留的工作空間歸誰所有、何時清除、以及一個用戶的工作空間是否會洩漏給另一個用戶？持久化模型的檢查清單請參閱 AI 產生程式碼沙盒：生產應用程式的要求。
工作階段狀態與持久化
沙盒工作階段是有狀態的還是臨時的？
兩種模式都存在，並服務於不同的工作負載。臨時工作階段為每個任務從乾淨的基準環境啟動——沒有累積的套件、檔案或歷史。它們更容易推理，適合評估執行或一次性程式碼執行。有狀態工作階段會跨多次執行呼叫保留檔案、已安裝套件、shell 歷史與環境狀態，這是多步驟程式碼代理、互動式資料分析與長時間工作流程所必需的。大多數生產平台都支援兩種模式。取捨在於有狀態工作階段需要明確的清除政策與更仔細的租戶隔離。
在受管理的沙盒中，狀態能持續多久？
工作階段持續時間因平台與方案而異。有些提供者設定預設工作階段逾時（通常 60 分鐘到 24 小時），逾時後工作階段會終止，除非狀態已持久化到快照或外部儲存，否則遺失。長時間執行的代理工作流程——可能需要在 LLM 呼叫之間暫停數分鐘或數小時的工作階段——需要一個支援工作階段暫停與恢復或自動暫停的平台，以便在保留狀態的同時避免為閒置時間計費。請確認最大工作階段長度以及逾時時飛行中狀態的處理方式。Novita Agent Sandbox 支援長達 24 小時的工作階段，並記錄了用於管理閒置時間的暫停/自動恢復功能。功能比較請參閱 Novita Sandbox：具備無縫相容性的 E2B Pro 成本效益替代方案。
工作階段可以暫停並恢復嗎？
有些平台支援暫停與恢復，即工作階段被暫停到磁碟，之後可以從相同狀態重新啟動。這對於在步驟之間等待 LLM 回應的代理、對昂貴工作負載進行速率限制，以及跨多次用戶互動的工作階段很有用。需要確認的關鍵事項有：暫停的工作階段可以保持暫停多長時間、暫停期間的網路連線如何處理，以及工作階段啟動時注入的憑證在恢復後是否仍然有效，還是需要重新整理。
沙盒狀態可以快照並重複使用嗎？
模板與快照是相關但不同的概念。模板是預先建置的基準環境——執行環境、工具、已核准的套件——新工作階段從它啟動。快照則捕捉正在執行的工作階段的當前狀態，並用作未來工作階段的起點。模板可以減少每個工作階段的啟動開銷，並確保所有代理從一致、受控的基準環境開始。快照則適用於保留部分工作或熱啟動疊代任務。兩者都需要治理：誰可以建立、誰可以讀取、屬於哪個租戶，以及如何進行版本管理。
套件安裝與執行階段相依性
代理可以在執行階段安裝套件嗎？
大多數沙盒環境預設允許執行階段套件安裝（pip install、npm install、apt-get 等），因為許多代理工作負載需要它們。問題不在於是否允許安裝，而在於每個安裝是否受到治理。不受治理的套件安裝是沙盒中風險最高的操作之一：它們在執行階段將外部程式碼拉入執行環境，可能包含執行任意命令的安裝後腳本，並可能引入供應鏈風險。
哪些政策可以治理執行階段的套件安裝？
生產環境的套件政策通常包括註冊表允許清單（僅從核准的套件註冊表或鏡像擷取）、拉取快取（在執行前檢查進入的內容）、安裝日誌記錄（記錄每個安裝的套件名稱、版本、來源與結果），以及可選的離線模式（將相依性預先烘焙到模板中，並禁止針對評估管線進行執行階段安裝，因為評估管線重視可重複性）。正確的政策取決於工作負載：協助開發者除錯的程式碼代理可能需要靈活的套件存取；而自動化評估管線則應從凍結的環境執行。實際實作範例請參閱 使用沙盒 Python 與受控套件存取建立 AI 資料分析師。
機密與憑證處理
沙盒中如何處理機密與憑證？
機密應狹義注入——僅注入特定任務所需的憑證，且僅限於該工作階段的持續時間。常見的反模式是將包含所有 API 金鑰的寬泛環境檔案掛載到每個工作階段中；這意味著任何一個工作階段一旦受損，都能存取該檔案中的所有憑證。應優先使用短效令牌，並將其範圍限定在該任務內，同時優先使用注入機制（環境變數或掛載的檔案）而非硬編碼。對於最敏感的憑證，執行階段的機密 API 僅對明確授權的程序提供值，這比讓所有程序都能存取的平面環境變數提供更強的隔離。
模型可以看到注入沙盒的環境變數嗎？
可以，如果環境變數被注入到模型程式碼執行的程序中的話。環境變數預設對同一工作階段中的所有程序可見。模型無法直接從其上下文視窗讀取它們，但從沙盒內部執行的產生程式碼可以透過 os.environ、process.env 等方式讀取。這就是狹義範圍重要性所在：只注入任務所需的憑證，並優先使用短效令牌，以便外洩的憑證只有有限的可用時間視窗。遮蔽是應用程式的責任：不要在預設情況下記錄完整的 stdout，因為機密可能出現在錯誤訊息或 print 陳述式中。
工作階段結束後，機密會如何處理？
環境變數與掛載的機密檔案應在工作階段拆卸時一併清除。如果平台跨工作階段保留狀態（快照、持久化磁碟區），請確認寫入檔案系統或由憑證提供者快取的憑證也已清除或輪換。在可恢復的快照中殘留過期憑證是一種風險——工作階段拆卸後，快照不應保留僅對原始工作階段持續時間有效的令牌。
稽核日誌與可觀察性
沙盒中記錄了哪些事件？
有用的沙盒稽核記錄包括工作階段建立與拆卸（工作階段 ID、租戶、模板版本、資源分配、持續時間）、執行事件（運行了什麼程式碼或命令類別、開始/結束時間、退出狀態）、套件安裝（名稱、版本、來源、結果）、對外網路接觸（網域、IP、連接埠）、從特定路徑讀取或寫入的檔案，以及清除結果。目標是在事後能夠重建代理行為，而不讓稽核日誌變成第二個機密儲存庫。原始客戶檔案、完整命令輸出與完整提示通常不屬於稽核日誌，除非您的保留與存取控制專門針對此類資料設計。
誰可以存取稽核日誌？
稽核日誌的存取控制應僅限於操作者，並在相關情況下限於租戶。在多租戶平台中，一個租戶的稽核記錄不應被其他租戶看見。對於合規敏感的部署，稽核軌跡需要具備防篡改性、保留所需期間，並可供授權的審查人員（安全團隊、合規官員）按需存取。請向您的沙盒提供者詢問：預設的日誌保留期限為何、日誌是否能匯出到您自己的 SIEM 或儲存、以及保護日誌資料的存取控制為何。
合規與安全審查
在生產環境中使用沙盒之前需要進行哪些合規審查？
具體需求取決於您的產業與管轄區域，但任何生產代理系統的標準問題包括：哪些資料進入了沙盒（這些資料是否受 GDPR、HIPAA、SOC 2 或其他框架管轄）、沙盒託管在哪裡且是否符合資料駐留要求、隔離模型為何且是否能向稽核人員證明、如何管理與輪換憑證、以及稽核軌跡的樣貌為何。大多數安全審查還會詢問產生的程式碼是否能觸及生產資料庫、內部管理介面或預期範圍之外的客戶資料。這些是架構層面的控制，而不僅僅是廠商認證。
安全團隊在評估 AI 代理沙盒時應該問哪些問題？
實際的評估檢查清單供安全審查使用：
- 隔離： 邊界是什麼——程序、容器還是微型虛擬機？每個代理工作階段在檔案系統、程序與網路層級是否都受到隔離？
- 出口： 預設出口政策為何？對外目的地可否設為允許清單？DNS 如何控制？
- 機密： 憑證如何注入？是否限於該任務？工作階段拆卸時是否清除？
- 稽核： 記錄了哪些事件？誰可以存取日誌？保留期限為何？
- 資料駐留： 沙盒託管在哪裡？部署是否可以限定在特定的雲端區域或帳戶？
- 合規姿態： 提供者是否持有相關認證（SOC 2、ISO 27001）？其共同責任模型為何？
- 網路觸及： 沙盒能否觸及內部中繼服務、私有 API 或其他租戶的資源？如何防止橫向移動？
將這些問題視為評估問題，而不是任何單一供應商自動滿足的要求。廠商文件中的安全與合規聲明應對照當前產品文件進行驗證，而非照單全收。對於有法規或合約要求的團隊，請讓您的安全團隊在生產環境部署之前完成審查，而非之後。
何時適合使用 BYOC（自帶雲端）或 VPC 部署？
資料駐留要求、網路安全政策或禁止資料離開特定雲端帳戶的法規限制，是團隊選擇 BYOC 或 VPC 部署而非共用受管理服務的主要原因。在您自己的 AWS 或 GCP VPC 內執行沙盒，意味著執行環境位於您的網路邊界內、受您的雲端帳戶存取控制約束，且沙盒的出口可由您現有的網路政策管理。取捨在於營運責任：您需要負責基礎設施管理、修補與擴展。Novita Agent Sandbox 將 BYOC 部署到 AWS 或 GCP 帳戶的功能記錄為針對有此類需求團隊的功能。請在 Novita Agent Sandbox 文件中確認當前的可用性與設定選項。
沙盒定價與成本驅動因素
沙盒成本由哪些因素驅動？
沙盒成本通常是運算時間（vCPU 與記憶體按每秒或每分鐘計費）、工作階段開銷（某些平台按工作階段收取啟動費用）、超出免費配額的持久化儲存，以及對外資料傳輸（出口）的組合。每個因素的相對權重取決於您的工作負載：短時程式碼直譯器主要是運算成本；下載大型檔案的瀏覽器自動化代理可能產生大量出口費用；持久化的程式碼工作空間則會累積儲存成本。閒置時間的處理是主要差異點——支援自動暫停的平台會在沙盒等待 LLM 回應時停止計費，這對於互動式工作流程可以顯著降低成本。各定價軸的詳細分析請參閱 AI 代理沙盒定價模型：按工作階段、運算、儲存與出口。
工作階段時間、運算與出口在成本中如何互動？
對於大多數工作負載，運算時間占主導地位。一個 10 分鐘的程式碼工作階段使用 1 個 vCPU 的費用，在典型費率下，通常高於 1 GB 的出口費用。但針對特定工作負載，互動關係就很重要：下載大型訓練資料集的資料代理會產生遠高於運算成本的出口費用。而一個在 LLM 回合之間保持工作階段開啟的瀏覽器代理，若未啟用自動暫停，則會累積閒置運算成本。實際做法是在承諾使用某個平台之前，根據實際的工作負載型態估算每個面向。Novita Agent Sandbox 根據實際 vCPU 與記憶體使用量按秒計費，沒有每次工作階段的啟動費用；截至 2026 年年中，1 個 vCPU 的定價為 $0.0000098/秒。（來源：Novita AI 定價頁面，已在已發布文件中驗證。在預算規劃之前請務必確認當前費率。）
自架設 vs. 受管理的 AI 代理沙盒
團隊何時應該自架設而非使用受管理沙盒？
自架設（自行執行沙盒基礎設施，通常基於 Firecracker 或類似的微型虛擬機層）在下列情況下是合理的：資料駐留或網路政策要求禁止使用第三方受管理服務、工作負載量大到受管理服務成本超過自行營運基礎設施的成本、或團隊已有平台工程能力並希望完全控制隔離模型、映像治理與網路政策。自架設比表面上看起來更困難：管理核心、根檔案系統、映像、快照、速率限制器、指標、清除與多租戶隔離都需要實際工作。營運範圍的詳細說明請參閱 Firecracker 用於 AI 代理沙盒。
何時使用受管理沙盒比較合理？
對於大多數建立程式碼代理、資料分析工具、瀏覽器自動化工作流程或評估管線的團隊來說，受管理沙盒是通往生產環境的更快途徑。平台負責基礎設施佈建、安全強化、映像更新、擴展與生命週期管理。團隊則專注於代理架構，而非沙盒內部。成本比較不僅僅是雲端運算費率：還需考量建置與維護隔離層的工程時間、為其編寫合規文件的工作，以及發生意外事件時的應變時間。對於沒有專屬平台工程能力的團隊，受管理服務通常能更快達到生產環境，並維持較低的總體擁有成本。用於比較受管理與自架設總成本的框架請參閱 AI 代理沙盒定價模型。
團隊在評估受管理沙盒提供者時應該問哪些問題？
除了標題定價之外的實際評估問題：
- 每個工作階段的隔離模型為何（微型虛擬機、容器、程序）？
- 預設與可設定的出口政策為何？
- 有哪些套件安裝治理選項？
- 機密如何注入與清除？
- 可以取得哪些稽核日誌資料，以及如何存取？
- 在您所需層級的工作階段長度與並行限制為何？
- 提供者是否支援 BYOC 或 VPC 部署？
- 暫停/恢復的行為為何，以及它如何影響計費？
- 啟動延遲在規模上如何表現（熱池、快照、冷啟動）？
