2026 Apple Container AI Agent 沙箱：如何隔離程式碼執行？

Apple Container 可以在 Apple Silicon 與 macOS 26 上，為每個 AI Agent 提供獨立的輕量虛擬機邊界；但 Apple Container AI Agent 沙箱不能單獨構成完整安全方案。本週應先用可刪除的測試倉庫完成一次最小部署，再補上網路白名單、短期密鑰、工作區寫入限制與銷毀驗收；若目標是 Linux 多租戶調度，則應改走 Firecracker 等 microVM 路徑。

這篇適合三類讀者：在個人 Mac 試跑編碼 Agent、擔心誤刪檔案或讀取 SSH 憑證的開發者；準備把本地工作流搬到遠端 Mac 的平台工程師；以及正在制定程式碼執行、網路存取與密鑰管理基線的安全負責人。

先記住一個邊界： Apple Container 的隔離範圍不會自動替我們決定哪些網路可以連線、哪些密鑰可以讀取，也不會替團隊處理審批、日誌、並發與異常終止。

Apple Container AI Agent 沙箱先解決哪一層風險

Apple 官方專案將 container 定位為在 Mac 上建立及執行 Linux 容器的工具，但每個容器會在輕量 Linux 虛擬機中執行，並使用 OCI 映像檔格式。官方目前要求 Apple Silicon Mac，且支援環境是 macOS 26；舊版 macOS 不在維護者通常會處理的範圍內。Apple Container 官方 README

這代表它比一般共享核心容器更接近「每個工作負載有獨立 Guest 邊界」的模型，適合隔離會安裝套件、執行 Shell、修改專案檔案的 AI Agent。不過風險至少還有四層：

1. 主機檔案風險：若直接掛載家目錄、.ssh、雲端憑證或生產倉庫，Agent 仍可能接觸到被授權的內容。
2. 網路出口風險：虛擬機隔離不等於限制外連；依賴安裝、模型 API、程式碼託管服務與任意第三方網址應分開管理。
3. 密鑰風險：環境變數、映像檔層、Shell 歷史與共享目錄都可能留下明文憑證。
4. 生命週期風險：停止 Agent 不代表卷、映像檔、暫存檔、日誌與工作區修改已經消失。

OpenAI 公開的程式碼執行安全方向，也把隔離測試、限制工具與網路、沙箱化執行視為重要控制，而不是只依賴模型本身的行為約束。OpenAI 關於隔離測試與沙箱執行的說明

部署前檢查：先鎖定版本、映像檔與回退方式

截至 2026 年 8 月 17 日，Apple Container 官方發佈頁顯示最新穩定版本為 1.2.2，該版本於 2026 年 8 月 8 日發佈。版本會快速變動，因此正式環境不應只記錄「已安裝」，而要記下安裝套件、版本、映像檔摘要與回退方法。Apple Container 發佈記錄

部署前可用以下表格做第一輪決策：

Apple 官方文件提供的基本啟動流程包括安裝簽署套件、啟動系統服務，以及以 container run --rm alpine echo hello 執行一次性容器；升級或降級前則需要先停止現有服務。Apple Container 安裝與回退說明

第一輪不要把 Agent 接到真實專案。準備一個能被刪除的測試倉庫，內含一個簡單測試、假密鑰字串、禁止存取的哨兵檔案，以及預期會失敗的網路請求，讓後續驗收有明確結果。

第一步：用最小映像檔建立一次性沙箱

先把 Agent 任務拆成「輸入、執行、結果」三部分。輸入可以是唯讀程式碼副本，執行區是獨立可寫目錄，結果則匯出到另一個指定位置。不要把這三者合併成整個主機目錄的讀寫掛載。

示意流程如下，實際選項需以當日官方文件與安裝版本為準：

container system start

container run --rm \
  --name agent-test \
  --mount type=bind,source="$PWD/test-workspace",target=/workspace \
  your-agent-image:approved \
  sh -lc 'cd /workspace && ./run-agent-task.sh'

這個步驟至少要驗證五件事：

• Agent 能否讀取測試副本，而非主機其他目錄。
• Agent 能否安裝完成任務所需的依賴。
• Agent 能否執行測試並輸出修改結果。
• 容器退出後，工作區、暫存檔與日誌各自留在哪裡。
• 加上 --rm 或手動刪除後，是否仍有孤兒卷、孤兒網路或未預期程序。

「能寫程式」只是成功條件之一；若每次任務結束後無法確認哪些資料被留下，這個沙箱還不能進入團隊工作流。

macOS 26 上的一次性沙箱，應把權限拆成三個邊界

本地 Apple Container 沙箱能否阻止 AI Agent 存取 Mac 主機檔案，答案是「只在未授予掛載與外部權限的前提下，能顯著縮小可見範圍；不能把已掛載的主機資料變回不可讀」。因此，以下三類路徑應分開處理：

• 唯讀輸入：只放任務所需的程式碼、規格與測試資料。
• 可寫工作副本：只允許 Agent 修改暫存分支或複製後的工作區。
• 結果匯出目錄：只接收 Patch、測試報告與必要日誌。

禁止直接掛載：

$HOME
$HOME/.ssh
$HOME/.aws
$HOME/.config
真實生產倉庫

密鑰則採取「按任務注入、短期有效、最小權限」三項原則。模型 API 金鑰不應寫入 Dockerfile、OCI 映像檔、共用 .env、版本控制或永久工作區；程式碼託管令牌只給單一倉庫、單一操作範圍，任務完成後立即撤銷或輪替。

網路規則也不要只分成「開」與「關」。至少拆成：

Apple Container 的虛擬機邊界、網路規則、密鑰注入和人工確認是不同控制面，不能因為第一項成立，就推論其他三項也已經安全。

從本地試跑遷移到遠端 Mac：先複製策略，再複製映像檔

遠端 Mac 的重點不是「把本地指令再執行一次」，而是讓以下資料可以由版本控制或部署腳本重建：

1. OCI 映像檔名稱與摘要。
2. container run 的啟動參數。
3. 工作區掛載規則。
4. 網路允許清單。
5. 密鑰注入介面與過期時間。
6. 任務逾時、停止、刪除與日誌保存規則。

我們建議先用同一個測試倉庫在本地及遠端 Mac 各執行一次，再比較啟動、清理與異常恢復，不要先搬真實專案。遠端環境還需要補上帳戶權限、連線逾時、並發任務隔離、日誌留存及主機層級的異常終止。這些不是 Apple Container 自動提供的團隊調度功能。

若需要遠端 Mac，應先完成 JexMac 的遠端 Mac 使用說明，確認連線方式、登入權限與工作區交付流程，再把同一份映像檔和策略帶上去。對於短期驗證，可先參考 JexMac 的方案與週期資訊，但不要把租用週期直接當成安全邊界；隔離仍須由部署腳本和驗收清單負責。

何時應由 Apple Container 改用 Firecracker

Firecracker 與 Apple Container 不應被當作同一個產品在不同作業系統上的名稱。Firecracker 是以 Linux KVM 建立 microVM 的虛擬機監控器，官方文件要求主機具備 KVM 核心模組與 /dev/kvm 讀寫權限，並支援 x86_64 與 aarch64 Linux。Firecracker 官方入門文件

需要改走 Firecracker，通常是出現以下條件之一：

• 任務來自互不信任的多個團隊或客戶。
• 需要 Linux 主機上的高密度並發與集中調度。
• 需要更完整的 vCPU、記憶體、磁碟和網路速率限制。
• 需要將 Agent 執行節點與 Mac 開發環境完全分離。
• 已經有 KVM、映像檔管理、日誌和節點編排能力。

Firecracker 官方設計文件把硬體虛擬化、資源限制與多租戶工作負載隔離列為核心方向，但正式環境仍要配置 jailer、seccomp、核心更新與主機防護，不能只下載二進位檔就視為完成安全部署。Firecracker 設計與生產主機建議

另一方面，公開的 agentkernel 文件把 macOS 26+ Apple Silicon 對應到 Apple Containers，把 Linux KVM 對應到 Firecracker；這可作為後端支援的社群項目參考，但不代表 Apple 對第三方編排工具作出官方承諾。agentkernel 後端支援表

第一週驗收：不要只測試 Agent 能否完成任務

正式上線前，至少安排以下破壞性測試，並為每項測試保留命令、時間、輸出與主機狀態：

驗收結果可以用三段式評分：

• A： 主機檔案、密鑰與未授權網路均被隔離，任務可追蹤並能完整銷毀。
• B： 虛擬機邊界正常，但網路、密鑰或日誌仍需外部策略層補強。
• C： Agent 可接觸主機敏感路徑，或失敗後無法清理；不得進入正式環境。

目前方案若是直接在開發者主機上執行，常見缺點是權限過大、環境狀態不可重建，以及多個 Agent 共用家目錄和憑證；若改用一般共享核心容器，還要額外面對核心共享、掛載錯誤與容器逃逸風險。對需要臨時算力、測試環境或遠端執行節點的團隊，先以 JexMac 租用隔離的 Mac 環境完成同一映像檔、同一權限策略和同一破壞性測試，通常比立即購置固定硬體更容易驗證成本與運維責任。完成小規模試跑後，再決定是否擴展成持續執行節點，或把高風險、多租戶任務遷移到 Firecracker。

需要建立遠端試跑環境時，可由 JexMac 的訂購流程開始；若任務需要長期穩定重負載、特殊實體介面或完全掌控主機硬體，自購 Mac 或專用 Linux microVM 仍可能更合適。