Sandbox
3 秒看懂
Sandbox（沙盒）是一種隔離執行環境，讓程式碼、模型或 AI 代理在受控區域內執行，即使發生錯誤或惡意行為也不會影響外部系統。在 AI 產業鏈中，沙盒承擔安全測試、工具呼叫驗證、多代理協作隔離、模型行為模擬等關鍵角色，是“放心讓 AI 執行動作”的基礎設施。
- 一句話定義：一個與生產系統隔離的受限空間，用於安全地執行、測試或觀測不可信的程式碼 / 模型。
- 核心價值：防滲透、防資料洩漏、防誤操作擴散，為自主 Agent 提供“行動圍欄”。
- 產業鏈位置：橫跨 DevSecOps、AI 安全測試、強化學習環境模擬、大型模型工具呼叫安全層。
- 關鍵特徵：資源限制、系統呼叫過濾、網路隔離、無狀態 / 快照恢復、可觀測性注入。
3 分鐘產業解釋
在 AI 工程化過程中，沙盒環境已從傳統的“軟體測試區”進化為AI 活動隔離平面。典型場景包括：
- 大型模型工具執行：LLM 呼叫外部 API 或執行程式碼時，沙盒限制其所能讀取的檔案、訪問的網路、可呼叫的系統函式，防止提示注入導致的越權。
- AI 安全紅隊：在隔離環境中對模型進行對抗攻擊、資料投毒模擬，評估風險而不汙染生產資料。
- 多智慧代理訓練與模擬：每個 Agent 在獨立沙盒中行動，環境可重置、可回滾，適合博弈論、市場模擬。
- 邊緣部署的微隔離：在使用者裝置上執行私有模型時，通過沙盒保證模型不會讀取使用者隱私資料。
產業趨勢上，傳統容器（Docker/runc）、微虛擬機器（Firecracker）、WebAssembly 沙盒、瀏覽器孤立 iframe 等不同“粒度和開銷”的隔離技術正在被組合進 MLOps 流水線。關鍵需求是：啟動快（毫秒級）、資源開銷低、安全邊界清晰、能整合到 CI/CD / 模型推論鏈。
技術原理
沙盒藉助作業系統核心提供的隔離機制組合實現受限執行。以下以 Linux 為例解剖核心機制，並給出一個簡化呼叫流程。
核心隔離機制及關鍵引數
| 機制 | 原理 | 關鍵控制引數 / 能力 | AI 場景典型用途 |
|---|---|---|---|
| 名稱空間 (Namespaces) | 限制程序可見的資源集合（PID, net, mnt, ipc, uts, user, cgroup） | clone() flags: CLONE_NEWPID, CLONE_NEWNET 等 | 隔離 Agent 程序組，阻斷其訪問宿主網路或檔案系統 |
| 控制組 (cgroups v2) | 限制、記賬、隔離資源（CPU, 記憶體, I/O, PIDs） | cpu.max, memory.max, io.max | 防止執行中的模型推論 / 訓練耗盡宿主機記憶體 |
| seccomp (安全計算模式) | 過濾允許的系統呼叫 | seccomp-bpf 規則集，可指定 ENOSYS、kill 等動作 | 阻斷 execve、ptrace、mount 等危險呼叫 |
| capabilities (權能) | 細分超級使用者權限，可剝離 | CAP_SYS_ADMIN, CAP_NET_RAW 等點陣圖 | 讓沙盒內 root 也無實際特權 |
| 檔案系統隔離 | pivot_root/chroot 或掛載名稱空間 + 只讀繫結 | 根檔案系統rshared / 只讀掛載，tmpfs 臨時可寫 | 防止模型讀出 /etc 敏感檔案或改寫系統庫 |
| Landlock / AppArmor / SELinux | 非特權路徑訪問控制 | Landlock 規則集：對檔案層級進行讀寫限制 | 補充沙盒內路徑級訪問控制 |
典型執行路徑（AI 工具呼叫沙盒示例）
使用者提示 --> LLM 生成 Python 程式碼串
--> 安全策略引擎解析（是否需要沙盒？）
--> 沙盒編排器：
1. 建立新網路名稱空間（無外網）
2. 建立新掛載名稱空間，掛載只讀程式碼依賴，掛載 tmpfs 為工作目錄
3. 應用 seccomp 白名單：只允許 write/read/close/fstat 等基本系統呼叫
4. 應用記憶體限制 cgroup.memory.max = 256MB
5. 通過 gVisor/runsc 或直接容器啟動執行程式碼
6. 捕獲標準輸出/錯誤，超時（如 5 秒）後 SIGKILL
--> 結果脫敏後返回 LLM具體實現引數取決於所用的沙盒引擎，當前 AI 開源生態中常見用 Docker API、gVisor（使用者態核心）、Firecracker 或 Wasm 虛擬機器。各引擎在啟動延遲（毫秒級~百毫秒）、隔離強度、資源開銷上差異顯著，但均依託上述核心原語組合。
技術演進簡史
- 2000s 初期：chroot/jail（FreeBSD jail）為基礎，純程序環境隔離，多用於託管服務。
- 2008–2013：LXC 結合 cgroups 和名稱空間，但缺少統一映象和標準，安全邊界模糊。
- 2013–2015：Docker 簡化容器建置與分發，沙盒重心從“隔離”偏向“一致性”，但預設配置下 root 使用者仍有一定攻擊面。
- 2015–2020：Kubernetes 生態提出 Pod 安全策略、安全上下文。Google 開源 gVisor，通過使用者態核心攔截系統呼叫減少攻擊面；AWS 釋出 Firecracker 微虛擬機器，每函式例項 <125ms 啟動，無程序殘留。
- 2020–2024：WebAssembly 沙盒進入 AI 推論場景，提供接近原生執行速度的輕量隔離；eBPF 可觀測性提升，可動態注入並監控沙盒行為。同時大型模型自主執行需求推動沙盒成為 LLM Agent 架構標配。
- 當前：多租戶 AI 推論服務普遍要求每個推論會話的沙盒化；機密計算（TEE 如 Intel TDX、AMD SEV）開始與沙盒融合，提供硬體級隔離。
關鍵引數
評估沙盒方案的核心維度：
- 啟動延遲：沙盒從觸發到可執行程式碼的時間。AI 工具呼叫場景通常要求 P99 < 200ms，邊緣場景需更低。Firecracker 官方資料顯示可低至 5–125ms；WebAssembly 沙盒可達 <5ms（估算，公開資料未見統一基準）。
- 資源開銷率：沙盒額外佔用的記憶體 / CPU 相比原生執行的比例。微虛擬機器方案通常額外記憶體佔用約 5–50MB（AWS Firecracker VMM 程序記憶體等），Wasm 方案可低於 1MB（估算，來源：Wasmtime 社群討論，但公開資料未見權威基準）。
- 逃逸漏洞數：近 5 年（2019–2024）CVE 統計中，Docker runc 累計報告高危逃逸漏洞約 3–5 個（來源：NIST NVD）；gVisor 使用者態核心因介面受限，公開逃逸漏洞數極少（公開資料未見大規模統計）；Firecracker 依賴 KVM 隔離，相關逃逸漏洞多歸入 KVM 層面。
- 系統呼叫覆蓋率：seccomp 或自定義核心能夠精確審計 / 阻斷的系統呼叫比例。Linux x86_64 總系統呼叫數約 330–350，典型的 Agent 沙盒白名單可能僅允許 50–80 個常用呼叫。
- 整合複雜度：與 CI/CD、模型服務架構的對接成本。Docker API 生態最成熟，Wasm 方案需重構部分工具鏈。
- 性能干擾度：沙盒內 AI 推論的吞吐 / 延遲相比原生執行的變化。採用 gVisor 的測試中，網路 / 計算密集型任務效能損耗約 5%–15%（來源：gVisor 官方效能文件，版本 2023.07），但 AI 推論專項的綜合基準公開資料未見統一報告。
技術路線
當前主流沙盒技術路線可按隔離層級從輕到重分為四種，以下是定性對比和適用場景：
| 指標 / 技術路線 | Docker/runc (名稱空間) | gVisor (使用者態核心) | Firecracker (KVM微VM) | Wasm 沙盒 (Wasmtime) |
|---|---|---|---|---|
| 隔離層級 | 核心名稱空間 / cgroups | 使用者態系統呼叫攔截 | 硬體虛擬化 (KVM) | 語言級虛擬機器 |
| 安全邊界 | 較寬 (共享核心) | 窄 (獨立核心實現) | 極窄 (獨立核心) | 窄 (無直接系統呼叫) |
| 啟動速度 | ~100-500ms | ~500ms (Sentry加速) | ~5-125ms [Firecracker資料] | ~<5ms [估算] |
| 每例項記憶體開銷 | 較低 (~10-50MB) | 中等 (~30-100MB) | 約 5MB+ [VMM程序] | 極低 (<1MB) [估算] |
| AI適用場景 | 訓練容器化、內部安全要求一般的任務 | 推論閘道器、多租戶隔離 | SaaS 按次函式推論 | 邊緣端推論、瀏覽器內推論 |
| 原生GPU支援 | 可通過平台外掛 | 有限，需特殊穿透 | 有限 | 暫無通用方案 |
| 代表產品/服務 | Docker, Kubernetes Pods | Google Cloud Run (部分) | AWS Lambda, Fly Machines | WasmEdge, 部分CDN邊緣函式 |
四種路線並非互斥，雲端廠商通常組合使用。例如，Google Cloud Run 部分採用 gVisor，AWS Lambda 依賴 Firecracker 並提供容器映象支援，Kubernetes 叢集則可能同時執行普通容器、Kata Containers（基於虛擬機器的 Pod 沙盒）和 gVisor 沙盒類執行時。Wasm 正從邊緣向雲端端延伸，試圖統一輕量沙盒和 AI 推論負載。
上游
沙盒技術的上游包括提供底層隔離能力的關鍵元件和標準：
- 作業系統核心：Linux 核心的名稱空間、cgroups、seccomp、OverlayFS、eBPF 等子系統。上游社群（kernel.org）的迭代直接影響隔離能力邊界。
- 硬體輔助虛擬化：Intel VT-x / AMD-V / ARM VHE 提供虛擬機器擴充套件；TEE 技術如 Intel SGX/TDX、AMD SEV、ARM CCA 引入加密隔離，成為機密沙盒的上游依賴。
- 執行時規範與標準：OCI（開放容器標準）定義容器映象、執行時和分發，這是 Docker、Kubernetes 等容器沙盒互通的基礎。WASI（WebAssembly 系統介面）正在定義 Wasm 沙盒訪問作業系統的標準方式。
- 策略引擎：Open Policy Agent (OPA)、Kyverno 等提供“策略即程式碼”，可動態注入沙盒的權限配置。AI 場景中，常將 OPA 整合至工具呼叫閘道器，決定 Agent 是否能呼叫特定 API。
- 映象與供應鏈安全：Sigstore、Cosign、SBOM 工具等確保進入沙盒執行的基礎映象未被篡改，屬上游安全供給環節。
下游
沙盒的下游應用場景和整合方覆蓋從基礎軟體到應用層的多個層次：
- MLOps 平台：Kubeflow、MLflow、Airflow 在流水線中排程訓練 / 推論任務，沙盒確保不同租戶的任務隔離，防止資料洩露和資源爭搶。
- LLM 工具鏈與 Agent 架構：LangChain、AutoGPT、CrewAI 等架構的工具執行模組已整合 Python 沙盒（如 RestrictedPython、Docker 執行器）或提供沙盒外掛介面，將模型生成的程式碼放到受限環境中執行。
- AI 安全評估：Garak、AugLy、Adversarial Robustness Toolbox 等工具集依賴沙盒執行對抗測試，評估模型韌性。
- 機密 AI 推論服務：面向金融、醫療的 SaaS 推論服務，利用 TEE 與沙盒結合，實現“資料可用不可見”的推論。
- 多智慧代理模擬環境：用於市場模擬、博弈論研究的 Agent 平台，每個 Agent 在一個可重置、可回滾的沙盒內執行，保證實驗的可重複性和安全性。
- DevSecOps 流程：CI/CD 管道中對模型、程式碼進行自動化測試的沙盒環境，確保建置階段的模型行為受控。
受益公司
以下企業在“AI + 沙盒”技術棧中，因提供關鍵基礎設施或服務而處於受益位置（僅為產業客觀描述，不構成任何投資建議）：
- AWS：Firecracker 奠定函式服務毫秒級隔離，並推出 Nitro Enclaves 連線機密計算，支援 AI 推論多租戶和可信執行。AWS Lambda 是目前規模最大的按需沙盒服務之一。
- Google Cloud：gVisor 是其容器安全隔離的核心開源專案，Cloud Run 採用該技術提供多租戶沙盒；同時通過 Kata Containers、Confidential VMs 等加強下層隔離。2024 年推出增強版沙盒用於 AI 工作負載。
- Microsoft Azure：通過 Hyper-V 隔離和 Windows Sandbox 提供桌面 / 伺服器沙盒，Azure Container Instances 和機密推論服務整合 TEE 與容器沙盒。2023 年釋出面向 Azure AI 的沙盒執行元件。
- Docker Inc.：提供容器沙盒基礎工具，近年推出 Docker Scout 用於映象安全分析，並向開發者提供 Wasm 支援預覽。
- Red Hat / SUSE：企業級容器安全工具（如 OpenShift 的安全上下文約束 SCC、SELinux 策略增強），為 AI 平台建置加固的 Kubernetes 多租戶沙盒。
- Fermyon / Cosmonic：基於 Wasm 的微服務與 AI 推論沙盒，主打邊緣輕量，目標場景是 AI Agent 在 IoT 和邊緣伺服器上的安全執行。
- 模型廠商（Anthropic, OpenAI 等）：其基礎設施必然建置沙盒來執行“Computer Use”、程式碼直譯器等特性；部分技術細節未公開，但間接拉動沙盒需求和技術迭代。
市場規模
由於“AI 沙盒”作為獨立品類尚處早期，目前缺乏單一權威機構釋出的市場規模統計。可參考關聯市場資料以建立量級概念（均來自公開研究報告，請注意口徑差異）：
- 全球容器安全市場：據 MarketsandMarkets 2023 年 6 月報告，2023 年全球容器安全市場規模約 12.1 億美元，預計 2028 年達 38.4 億美元，年複合增長率約 26.0%。該口徑包含容器執行時安全、映象掃描、策略管理等，AI 沙盒為其中一項增量場景。
- 雲端原生安全總體：IDC 2023 年報告估算，2023 年全球雲端原生安全支出約 45 億美元，2027 年有望突破 100 億美元。AI 工作負載保護被列為細分增長極，沙盒是其控制面環節。
- 機密計算市場：Gartner 2023 年 Hype Cycle 顯示機密計算位於“期望膨脹期”，Grand View Research 估計 2023 年市場約 37 億美元，2030 年可達 540 億美元（CAGR 45%+），沙盒與 TEE 的融合將受益於該趨勢。
- 精確的“AI 執行沙盒”市場資料公開資料未見。定性判斷，2024 年起受 Agent 架構廣泛整合影響，需求側增速可能高於容器安全整體，到 2028 年 AI 沙盒相關營收可能達到容器安全市場的 15%–25%（僅為初步推演，來源：綜合分析，無獨立報告）。
玩家對比
對比當前市場主要沙盒技術棧及對其在 AI 場景的定位（資料截至 2025 年 2 月，基於公開文件和產品頁面）：
| 玩家 / 方案 | 核心隔離方式 | 定位與差異化 | 代表客戶/應用場景 | 開源/商業 | 典型整合 |
|---|---|---|---|---|---|
| AWS Firecracker | KVM 微虛擬機器，自帶精簡 kernel | 毫秒級啟動，面向 FaaS 的多租戶強隔離 | AWS Lambda、自建 Serverless AI 推論 | 開源 (Apache 2.0) | 通過 Kata Containers 或自定義編排 |
| Google gVisor | 使用者態核心（Sentry），攔截系統呼叫 | 兼顧隔離性與相容性，比普通容器安全，比 VM 輕 | Google Cloud Run、App Engine、內部多租戶 AI | 開源 (Apache 2.0) | Docker/containerd 執行時外掛 runsc |
| Kata Containers | 輕量虛機（QEMU/Cloud Hypervisor + 精簡核心） | 每個 Pod 獨立核心，安全性與 VM 等同，可繫結 GPU | Kubernetes 多租戶 AI 推論叢集 | 開源 (Apache 2.0) | CRI-compatible，與 Kubernetes 原生整合 |
| Docker runc/containerd | Linux 名稱空間 + cgroups | 最廣泛、最成熟的容器方案，安全預設較寬 | 內部訓練、開發測試、非多租戶推論 | 開源 (Apache 2.0) | 幾乎所有 CI/CD 和 MLOps 平台 |
| WasmEdge/Wasmtime | WebAssembly 虛擬機器，無系統呼叫直接訪問 | 極低資源開銷、極快啟動，適合邊緣與瀏覽器內推論 | 邊緣 AI 推論、資料預處理沙盒、外掛沙盒 | 開源 (Apache 2.0) | 與 Dapr、NGINX Unit、雲端函式定製整合 |
| 模型廠商自研（未公開細節） | 推測：容器 + seccomp + 網路隔離 + 檔案系統快照 | 與服務深度整合，針對特定危險場景定製 | OpenAI Code Interpreter、Anthropic Computer Use | 未開源 | 內部 Agent 架構 |
各玩傢俱體效能表現依賴硬體和配置，公開測試基準不統一，上述為基於官方文件及社群討論的定性對比。
風險
- 技術同質化與開源替代：基礎沙盒技術（如 runc、gVisor、Firecracker）高度開源，商業發行版或託管服務的差異化難度大，可能侵蝕獲利空間。
- 效能損耗無法消除：無論哪種隔離技術，都會帶來程度不同的效能開銷（CPU 吞吐下降、記憶體額外佔用、啟動延遲）。對於即時或高吞吐 AI 推論場景，若損耗無法控制在 5% 以內，可能阻礙使用者採用。
- 安全邊界仍存未知漏洞：共享核心或虛擬化層面的逃逸漏洞仍會週期性出現。2024 年 CVE-2024-21626（影響 runc）再次表明容器逃逸攻擊面未完全根除。任何新增隔離層本身也可能成為攻擊目標。
- AI 場景策略複雜度飆升：Agent 呼叫多步驟工具，需要動態配置細粒度權限，策略管理變得極其複雜。錯誤配置可能導致要麼權限過寬失守，要麼過於嚴苛影響任務完成度。
- 合規標準缺失：目前尚無專門針對“AI 執行沙盒”的國際認證標準或明確法規，企業在審計中較難自證其安全水平，可能面臨法規落地的不確定性。
- 硬體依賴與供應鏈安全：機密計算沙盒依賴特定 CPU 代際（Intel Ice Lake 以上、AMD Milan 以上等），硬體供應受限或供應鏈風險會影響部署規模。
誤讀糾偏
誤讀 1：“容器就是沙盒，絕對安全”
容器（尤其是僅用名稱空間隔離的）共享宿主機核心，若核心存在漏洞，容器內程序可能逃逸。標準 Docker 預設不啟用無 root、無特權模式、只讀根檔案系統和嚴格的 seccomp 配置，安全等級有限。真正的安全沙盒需組合多項機制並停用多餘 syscall。
誤讀 2：“AI 沙盒只需限制程式碼執行”
大型模型輸出可能包含隱性的惡意指令（提示注入）去呼叫工具，如果沙盒僅限制程式碼，而不限制工具（如允許隨意查詢資料庫），攻擊面依然存在。因此沙盒需覆蓋程式碼 + 資料訪問 + 網路呼叫的三維限制，並與策略引擎聯動。
誤讀 3：“啟動越快越好，安全可以妥協”
部分輕量沙盒（如簡單的 Wasm 沙盒）啟動極快、開銷極低，但其安全隔離邊界窄，預設不允許訪問作業系統資源。如果因為啟動快而放棄必要的安全機制（如精細的系統呼叫過濾、硬體隔離），可能留下隱患。正確的做法是根據風險評估匹配隔離強度，而非一刀切追求極致速度。
最新事件
- 2024 年 10 月：Anthropic 為 Claude 公開“Computer Use”功能，允許模型在受控螢幕環境中操作滑鼠鍵盤，其底層依賴自定義沙盒環境提供隔離與回滾，詳細技術細節未揭露。（來源：Anthropic 官方部落格）
- 2024 年 7–9 月：Google Cloud 宣佈對 Cloud Run 沙盒進行強化，引入基於 gVisor 的增強安全配置檔案，支援 GPU 的沙盒執行，面向 AI 推論工作負載。（來源：Google Cloud 官方功能釋出日誌）
- 2024 年 8 月：Docker 在 DockerCon 2024 上展示 Wasm 與容器混合執行場景，演示 AI 推論邊緣側的 WasmEdge 沙盒整合。（來源：DockerCon 2024 主題演講）
- 2024 年 5 月：OpenAI 對 ChatGPT 程式碼直譯器執行環境進行升級，強化沙盒隔離，增加了網路訪問黑名單和記憶體限制，官方未釋出詳細架構公告。（來源：OpenAI 更新日誌摘要）
- 2024 年全年：Kubernetes 社群推進 Pod 級別沙盒標準化，KEP-4263（Pod-Level Sandboxing）進入 alpha，推動 Kata Containers、gVisor 等作為“沙盒執行時”統一配置介面。（來源：Kubernetes SIG-Node 會議記錄）
- 2025 年 1 月：CNCF 宣佈 WasmEdge 成為沙盒級專案，進一步推動 WebAssembly 在雲端原生與 AI 推論中的採用。（來源：CNCF 新聞）
追蹤指標
為了持續追蹤沙盒技術在 AI 領域的進展和影響，建議關注以下指標：
- 逃逸漏洞 CVE 數量：NIST NVD 中每年新增的與容器逃逸、gVisor/Firecracker 相關的 CVE 數量，反映隔離邊界的可靠度。
- 沙盒啟動時間（P99）：主流雲端服務商（AWS Lambda、Google Cloud Run）公佈的沙盒冷啟動和熱啟動延遲資料，以及社群基準測試（如 SeBS 基準）的變化趨勢。
- AI Agent 架構整合度：LangChain、AutoGPT、CrewAI 等架構預設沙盒提供商的更新情況，外掛數量與社群活躍度。
- 機密沙盒部署案例：金融、醫療行業採用 TEE + 沙盒的公開可行案例數及規模。
- 效能損耗基準：MLPerf 推論基準中，虛擬機器 / 容器沙盒相比裸金屬的吞吐損失比例，以及 Wasm 沙盒的場景化效能資料。
- 標準與規範進展：OCI、WASI、SPIFFE 等組織釋出的與沙盒互操作、身份、策略相關的規範更新。
- 投融資事件：沙盒相關初創公司（Wasm、機密計算、Agent 安全）的融資輪次與金額，反映資本熱度。
信源
- Firecracker 設計文件，AWS 開源專案，https://github.com/firecracker-microvm/firecracker
- gVisor 架構指南，https://gvisor.dev/docs/
- OCI Runtime Specification，opencontainers/runtime-spec，GitHub
- Kata Containers 官方文件，https://katacontainers.io/
- WasmEdge 專案，https://wasmedge.org/
- MarketsandMarkets, “Container Security Market – Global Forecast to 2028”, June 2023
- IDC, “Worldwide Cloud-Native Application Protection Platform Forecast, 2023–2027”, 2023
- Grand View Research, “Confidential Computing Market Size, Share & Trends Report, 2023–2030”
- Kubernetes Enhancement Proposal KEP-4263 (Pod-Level Sandboxing), https://github.com/kubernetes/enhancements
- NIST National Vulnerability Database, https://nvd.nist.gov
- Anthropic, “Computer Use for Claude”, Oct 2024, https://www.anthropic.com
- Google Cloud, “Cloud Run sandbox enhancements for AI workloads”, 2024 Feature Releases
- DockerCon 2024 Keynote, “Docker and WebAssembly: The Next Frontier”, Aug 2024
- OpenAI, ChatGPT Release Notes, May 2024 Update
- CNCF, “WasmEdge accepted as a CNCF Sandbox project”, Jan 2025
本頁所有技術引數除明確標註外均為基於業界公開實現的定性歸納，精確數字如未獲得統一測試基準或官方公佈，均標註[估算]或[公開資料未見]，請謹慎參考。市場資料均註明來源、年份及口徑，不構成任何投資建議。