AI 執行程式碼沙盒的安全性取決於其隔離邊界 — 而隔離邊界僅是答案的一部分。更值得追問的是：沙盒實際隔離了什麼？哪些東西仍然可能逃脫？大多數沙盒能有效阻止某些行為（如程序層級的程式碼執行、對主機任意檔案系統寫入），但預設情況下會保留其他開放路徑（如對外網路、套件安裝、環境變數中的機密）。理解這些缺口，才能評估沙盒是否符合你的風險模型。關於 AI Agent 沙盒 的背景知識，以及隔離、出站、快照、微 VM 等核心概念如何搭配運作，請先參閱定義指南，再深入安全細節。
「安全」對程式碼執行沙盒的意義
程式碼執行沙盒的安全性並非二元屬性；它是一系列控制措施，每項措施應對特定類別的風險。當有人問「這個沙盒安全嗎？」時，通常同時在問幾個不同的問題：
- 主機隔離：沙盒內執行的程式碼能否逃逸到主機系統？
- 租戶隔離：一個使用者的程式碼能否影響另一個使用者的工作階段？
- 出站控制：沙盒內的程式碼能否連接到網際網路、內部服務或中繼資料端點？
- 機密範圍：憑證的可存取範圍是否超過實際需要？
- 供應鏈風險：套件安裝是否可能引入意料之外或惡意程式碼？
- 可稽核性：事後能否重建 agent 實際做了什麼？
一個沙盒可能在主機隔離方面很強，但在出站控制上很弱；或在出站控制上很強，但在機密處理上很弱。評估「安全性高低」需要逐項檢查每個維度，而不是接受「容器化」或「基於微 VM」這類單一標籤作為全部答案。
隔離層比較
AI 程式碼執行沙盒主要使用三種隔離模型。每種模型提供不同的邊界。
程序隔離
程序隔離使用 OS 層級的原語 — Linux 命名空間、cgroups、seccomp 過濾器、AppArmor 或 SELinux 設定檔 — 來限制程序可存取的範圍。沙盒以主機 OS 上的程序形式運行，與主機共用核心。
它能阻止的：存取更廣泛的檔案系統、沙盒外的其他程序，以及 seccomp 政策明確封鎖的系統呼叫。
它無法阻止的：透過共用核心漏洞提升權限的核心漏洞利用。若發生 seccomp 繞過或核心漏洞，即可突破主機邊界。
適合的情境：短期、低風險、相對可信的程式碼，且啟動速度與可攜性比嚴格的 VM 邊界更重要。不建議用於執行來自外部使用者、由 agent 隨機產生的程式碼。
容器隔離（Docker/命名空間）
容器隔離在程序隔離的基礎上擴充了更結構化的映像模型、網路命名空間與磁碟掛載。多數基於 Docker 的沙盒實作會在容器內執行程式碼，搭配最小映像與受限的 seccomp 設定檔。
它能阻止的：直接存取主機檔案系統、大多數對相鄰容器的網路存取（若正確設定）、輕易存取主機程序。
它無法阻止的：核心層級的漏洞仍然適用 — 容器與主機共用核心。錯誤設定的磁碟掛載、過於寬鬆的 seccomp 設定檔、--privileged 模式、暴露的 Docker socket 等，都可能破壞原本預期的邊界。
適合的情境：許多正式部署確實有效使用容器執行 AI 程式碼，前提是 seccomp 設定檔嚴謹、映像最小、出站受限且未授予特權存取。其風險模型與微 VM 不同，但可透過仔細設定來管理。
微 VM 隔離（Firecracker/gVisor）
微 VM 隔離讓每個沙盒執行在輕量級虛擬機中，擁有自己的來賓核心，並透過 KVM 虛擬機器監視器邊界與主機隔離。Firecracker 是最常見的實作；gVisor（搭配其使用者空間核心）則提供不同的取捨。
它能阻止的：來賓核心的漏洞不會擴散到主機核心或其他來賓。主機的攻擊面僅限於 VMM（虛擬機器監視器），而 VMM 設計成最小化。
它無法阻止的：VMM 本身的漏洞（罕見但非不可能）。網路、套件與機密控制仍位於 VM 邊界之外 — 微 VM 隔離不處理這些。
適合的情境：執行來自外部使用者的不可信或 agent 生成的程式碼；多租戶環境中爆裂半徑很重要；可能執行任意 shell 命令或套件安裝腳本的工作負載。
| 隔離模型 | 主機核心共用 | 租戶隔離 | 啟動額外負擔 | 主機逃逸風險 |
|---|---|---|---|---|
| 程序 | 是 | 弱 | 最低 | 最高 |
| 容器 | 是 | 中等 | 低 | 中（依設定而定） |
| 微 VM | 否 | 強 | 中等 | 低 |
每種邊界仍可能逃逸的東西
隔離模型應對的是執行時期的程式碼執行。它不會自動處理透過其他路徑進出沙盒的內容。
對外網路：三種隔離模型都將對外網路存取留給政策設定。預設開放的出站流量表示沙盒內的程式碼可以連接到公共網際網路、雲端中繼資料端點（AWS 和 GCP 的 169.254.169.254）、同一網路上的內部服務，以及任意外部 API。無論隔離模型為何，這都是資料外洩路徑、機密擷取路徑以及命令與控制路徑。
套件安裝：apt install、pip install 或 npm install 會從外部註冊表下載並執行程式碼。如果沙盒允許套件安裝且出站開放，則套件名稱衝突、打字錯誤攻擊或依賴混淆攻擊，可能引入具有沙盒全部權限的惡意程式碼。隔離邊界能限制爆裂半徑，但無法阻止安裝本身。
共用狀態：在多租戶部署中，共用的快取、共用套件註冊表、共用範本映像或共用檔案系統掛載，會在租戶之間建立繞過隔離邊界的通道。
環境變數中的機密：Agent 程序可見的環境變數，可由 agent 執行的任何程式碼讀取。如果資料庫憑證或 API 金鑰放在環境變數中，則沙盒及其執行的任何程式碼或安裝的套件都可存取。
出站與網路控制
出站是多數沙盒最大的缺口。開放對外網際網路存取很常見，因為這樣很方便 — agent 需要安裝套件、呼叫 API、擷取資源。但這也帶來風險：
雲端中繼資料端點：在託管雲端基礎設施上，169.254.169.254（及其 IPv6 版本）提供實例中繼資料，包括 IAM 憑證。出站開放的沙盒內的程式碼可以存取此端點並擷取底層主機的憑證。
基於 DNS 的外洩：即使 HTTP 被封鎖，對外 DNS 查詢也可透過在領域查詢中編碼資料來外洩資訊。DNS 封鎖需要在解析器層級進行過濾，而不僅僅是封鎖流向外部伺服器的 TCP/UDP 53。
內部服務：如果沙盒運行在私有網路區段，開放的出站流量可能允許存取內部資料庫、管理後台和不應從 agent 程式碼到達的 API。
應評估的控制項：
| 控制項 | 阻止什麼 | 應驗證什麼 |
|---|---|---|
| 預設拒絕出站 | 對未列出目的地的對外連線 | 是否也封鎖了 DNS 以及 TCP/UDP？ |
| 基於允許清單的出站 | 對非批准領域的連線 | 允許清單是否可由客戶設定？ |
| 中繼資料端點封鎖 | 透過 169.254.169.254 擷取雲端憑證 |
IPv6 中繼資料是否也封鎖？ |
| 出站代理 | 記錄與檢查所有對外流量 | 代理日誌是否可存取？ |
| DNS 過濾 | 基於 DNS 的外洩與內部名稱解析 | 沙盒內部使用哪個解析器？ |
沒有普遍正確的出站政策。某些 agent 工作負載確實需要廣泛的網際網路存取才能發揮作用。關鍵在於政策是經過審慎設計且可稽核的，而不是因從未設定而預設開放。
機密處理
AI agent 沙盒中的機密遵循與任何軟體系統相同的原則，但多了一項限制：agent 可能執行程式碼，在不經開發者意圖下讀取、記錄或傳輸環境。
範圍限定：僅掛載沙盒當前任務實際需要的憑證。執行編碼任務的沙盒不需要生產資料庫憑證。評估模型輸出的沙盒不需要帳務服務的 API 金鑰。
生命週期：短期憑證遠比長期憑證安全。如果憑證在沙盒內洩漏，短 TTL 能限制暴露窗口。許多雲端 IAM 系統支援在數分鐘或數小時內過期的短期權杖。
注入方式：環境變數是最常見的注入方式，也是任何程序內程式碼最容易存取的方式。可以透過檔案系統掛載（掛載在 agent 不需要遍歷的路徑）、或僅在需要時動態擷取的機密，會比全域環境變數集合更受限。
遮罩處理：機密應從標準輸出、標準錯誤、工具回應 payload、模型可見上下文以及稽核日誌中遮罩。如果 agent 輸出其環境、呼叫 env 或將權杖傳遞給失敗的 API 呼叫，則憑證可能洩漏到日誌中，隨後被儲存或被操作者看到。
資源限制與阻斷服務風險
沒有資源限制的沙盒容易受到耗盡 CPU、記憶體、磁碟或網路頻寬的 agent 工作負載影響 — 可能來自失控程式碼、無限迴圈、已安裝套件中的記憶體洩漏，或蓄意破壞相鄰工作負載。
應驗證的資源控制項：
- CPU 限制：每個工作階段的調節或硬限制可防止一個工作階段耗盡主機容量。
- 記憶體限制：OOM 終止政策應終止沙盒工作階段，而非主機程序。
- 磁碟配額：每個工作階段的寫入限制可防止一個工作階段填滿共用儲存。
- 執行逾時：超過實際時間限制的工作階段應被乾淨終止，而非持續運行。
- 網路速率限制：出站頻寬限制可在出站政策允許目標時，仍限制外洩規模。
- 並行程序限制：積極 fork 或產生背景程序的 agent 可能耗盡程序表插槽。
資源限制違規也值得記錄。一個工作階段在應為輕量的任務上持續觸發 CPU 調節或 OOM 終止，是值得調查的訊號。
稽核可見性
隔離控制能在出問題時減少爆裂半徑。稽核日誌則能幫助你發現出問題，並重構事發經過。
針對 AI agent 沙盒，有用的稽核涵蓋範圍包括：
- 程序執行：每個運行的命令，含完整引數列表、UID 與父程序。沒有引數列表，日誌中的
curl和python便無意義。 - 檔案系統存取：對敏感路徑的讀取與寫入。對大多數威脅模型而言，寫入與刪除比讀取更重要。
- 對外網路：目標、協定、DNS 查詢與傳輸位元組數。DNS 查詢記錄常被忽略但很重要。
- 套件安裝：套件管理器、套件名稱、版本、來源註冊表與雜凑值。
- 工作階段生命週期：建立、暫停、恢復、終止與清理事件，附帶原因代碼。
- 資源限制事件：OOM 終止、CPU 調節、逾時終止。
收集機制與涵蓋範圍同樣重要。在沙盒程序內部產生的日誌可能被具有足夠權限的 agent 壓制或修改。核心層級（透過 auditd、eBPF 或虛擬機器監視器儀控）的收集是在應用程式層之下產生，agent 無權寫入。
應向任何沙盒供應商或專案提出的問題
評估託管沙盒服務或開源沙盒框架時，請使用此核對清單。關於主要供應商如何回答這些問題的並排比較，請參閱 2026 年最佳 AI Agent 沙盒 或 E2B 與 Daytona 評估指南。
隔離
- 每個 agent 工作階段是否擁有自己的隔離環境，還是工作階段會群組在共用執行環境上？
- 使用哪種隔離模型：程序、容器還是微 VM？
- 來賓核心是否與主機共用？
網路與出站
- 出站是預設開放還是預設拒絕？
- 出站政策能否按租戶或按工作階段設定？
- 雲端中繼資料端點（
169.254.169.254）是否被封鎖？ - 沙盒內部如何處理 DNS？
套件安裝
- 套件安裝是否預設允許？
- 能否將安裝限制在已批准的註冊表？
- 安裝事件是否記錄來源與雜凑值？
機密
- 憑證如何注入沙盒？
- 憑證能否範圍限定到需要它的特定工具或任務？
- 機密是否從日誌和模型可見輸出中遮罩？
資源限制
- 是否強制執行 CPU、記憶體、磁碟與逾時限制？
- 達到限制時會發生什麼 — 調節、終止還是發出警示？
稽核日誌
- 日誌是在核心/虛擬機器監視器層級產生，還是在沙盒程序內部產生？
- 預設記錄哪些事件類別？
- 日誌能否匯出到外部 SIEM 或日誌聚合系統？
- 日誌保留政策是什麼？
租賃
- 不同租戶的工作負載是否彼此隔離？
- 是否存在共用的快取、映像或掛載點，從而建立跨租戶通道？
Novita Agent Sandbox 的定位
Novita Agent Sandbox 專為需要隔離執行環境（程式碼、檔案、程序及較長工作階段）的 agent 工作負載而設計。目標團隊是建構程式碼 agent、評估管線、資料分析 agent 以及基於瀏覽器的 agent 工作流程的團隊。
該沙盒支援工作階段生命週期控制，包括暫停、恢復與閒置自動暫停。它透過 API 提供資源指標與工作階段層級的執行日誌。對於已使用 Novita 模型 API 的團隊，它可作為 agent 架構中的執行層 — 模型規劃並呼叫工具，而沙盒在隔離環境中處理執行時期的運算。
在評估 Novita Agent Sandbox 用於安全敏感場景時，請在做出架構決策前，先查閱產品文件 以驗證當前的隔離模型、出站政策預設值、日誌涵蓋範圍與機密處理。安全需求因工作負載而異 — 適合內部評估管線的措施，可能不足以應付處理使用者提供程式碼的多租戶產品。
與任何沙盒一樣，安全態勢取決於平台的預設值以及你應用程式層級的控制：憑證如何範圍限定、agent 被允許請求什麼、哪些工具呼叫需要人為核准，以及如何監控稽核日誌。
限制與任何沙盒都無法消除的風險
沒有沙盒能消除所有風險。理解邊界之外還遺留了什麼，與理解邊界提供了什麼同樣重要。
應用層的信任決策：沙盒控制執行時期的執行。它不決定 agent 被允許要求什麼。如果你的應用程式允許 agent 請求憑證、執行任意 shell 命令或呼叫任何 API，沙盒能減少爆裂半徑，但無法阻止那些行為。
提示注入：處理不可信內容（網頁、使用者上傳的檔案、外部 API 回應）的 agent，可能被該內容操縱而採取不應採取的行動。這是應用程式設計問題，而非沙盒問題。沙盒可以限制那些行動落在何處，但決策邏輯存在於你的應用程式中。
零日漏洞：所有隔離模型都有已知與未知的漏洞。微 VM 隔離在當前生產使用中提供了最強的邊界，但 VMM 漏洞確實存在。縱深防禦（結合多重控制而非依賴單一邊界）是比任何單一隔離模型更穩健的姿態。
透過模型輸出的社交工程：Agent 可能產出說服人類操作者採取不安全行動的輸出。沙盒不會稽核人類決策。
合規與法規風險：隔離控制處理技術風險。法規要求（GDPR、HIPAA、SOC 2、ISO 27001）涵蓋資料處理、保留、文件與稽核需求，其範圍超越沙盒在基礎設施層級所能提供的。
總結來說，程式碼執行沙盒的安全性最好被視為一系列需要評估與設定的控制措施，而非透過選擇某個產品就能獲得的屬性。上述評估問題適用於每個沙盒決策 — 包括如果你自行建置而非購買時，你自己的基礎設施。
常見問題
沙盒化的 AI 程式碼執行環境與直接在伺服器上執行程式碼相比，安全性如何？
設定良好的沙盒能顯著減少執行不可信程式碼時的爆裂半徑，相比直接在伺服器上執行。它限制了檔案系統存取、程序範圍與網路存取。然而，差異取決於設定。一個出站開放的容器搭配廣泛的環境變數注入，可能比一個設有網路控制的強化伺服器更不安全。隔離模型是起點，而非保證。
微 VM 隔離是否代表沙盒完全安全？
否。微 VM 隔離（Firecracker、KVM 基礎）提供了一個共用核心容器所沒有的強主機邊界。但它不控制出站、機密、套件安裝或稽核涵蓋範圍。一個出站開放且無日誌收集的微 VM 即使隔離層很強，也並非「完全安全」。
AI 生成的程式碼能逃脫沙盒嗎？
取決於隔離模型與設定。逃脫容器需要利用核心漏洞或設定錯誤；逃脫微 VM 需要利用 VMM 漏洞。兩者雖可能但罕見。更實際的風險是透過允許的網路路徑進行資料外洩、從環境中讀取機密、或透過不受限制的套件管理器安裝惡意套件。
多數 AI 程式碼沙盒最大的安全風險是什麼？
開放對外出站是最常被低估的風險。許多沙盒預設允許不受限制的對外網際網路存取，因為這對需要安裝套件和呼叫 API 的 agent 很方便。這會創造資料外洩路徑、透過雲端中繼資料端點竊取憑證的路徑，以及命令與控制通訊的路徑，無論隔離邊界有多強。
應該使用託管沙盒還是自行建置？
託管沙盒處理微 VM 或容器生命週期、主機容量與映像管理的操作複雜性。自行建置則能更全面地控制政策堆疊。無論哪種方式，相同的評估問題都適用：出站政策、機密處理、日誌涵蓋範圍、資源限制與稽核匯出。建置或購買的決策應與安全評估分開。
Agent 沙盒安全與傳統程式碼執行安全有何不同？
傳統程式碼執行安全假設你大致知道會執行什麼程式碼。AI agent 改變了這一點：單一提示可能導致工作階段安裝套件、寫入檔案、執行 shell 命令、呼叫外部 API 並產生子程序，而無需對每個步驟都取得開發者明確核准。這使得稽核涵蓋範圍更重要（你無法預測每個動作）、出站控制更重要（agent 可能到達你未預期的目標）、機密範圍限定更重要（agent 可存取環境中的所有內容）。
在生產環境中進行 AI agent 隔離的最佳實務是什麼？
生產 agent 部署的實用隔離核對清單：對不可信或使用者提供的程式碼使用微 VM 級別的隔離（Firecracker 或同等方案），而非僅用容器；為每個任務或每個使用者工作階段分配一個隔離環境 — 切勿在不同工作負載之間共用沙盒；出站預設拒絕，並為必要目標建立明確的允許清單；僅注入目前任務所需的憑證，並使用短期權杖；在核心或虛擬機器監視器層級收集稽核日誌，而非在沙盒程序內部；對每個工作階段強制執行 CPU、記憶體、磁碟與實際時間限制；積極清理工作階段 — 任務完成後立即銷毀臨時沙盒。在所有這些控制上實施縱深防禦，能提供比任何單一強邊界更有意義的安全性。
安全團隊在審查用於企業部署的 AI agent 沙盒時應評估哪些事項？
企業安全審查應涵蓋六個領域：（1）隔離 ** — 微 VM 還是容器？每個工作階段在檔案系統、程序與網路層級是否完全隔離？（2） 出站 ** — 預設開放還是預設拒絕？出站政策是否可由客戶設定？雲端中繼資料端點（169.254.169.254）是否被封鎖？（3）** 機密 ** — 憑證如何注入？是否以短期權杖按任務範圍限定？工作階段拆卸時是否清理？（4）** 稽核 ** — 日誌是否在沙盒程序之下（核心/虛擬機器監視器層級）產生？日誌能否匯出到 SIEM？（5）** 資料駐留 ** — 是否提供 BYOC 或 VPC 部署，讓工作負載留在你的雲端帳戶內？（6）** 合規狀態** — 供應商持有哪些認證？共同責任模型為何？對於有法規要求的團隊，請在正式部署前（而非之後）完成此審查。
AI agent 沙盒中的核心隔離如何運作？
核心隔離表示 agent 的程式碼運行在擁有自己核心的環境中，並透過硬體虛擬化邊界（KVM）與主機核心分離。在基於 Firecracker 的沙盒中，每個工作階段在微 VM 內啟動一個最小來賓核心。沙盒內的程序與來賓核心互動；主機核心從內部無法看見或抵達。來賓核心中被利用的漏洞不會自動傳播到主機，因為 KVM 邊界位於兩者之間。這是勝過容器基礎隔離的關鍵安全優勢 — 容器基礎隔離中，所有容器共用主機核心，一個核心漏洞會同時影響所有容器。
