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