2026 Apple Container 執行 AI Agent，上線前怎樣驗收沙箱？
Apple Container 只有在檔案越權、密鑰外洩、網路外連、資源耗盡與異常回收全部驗收通過後，才適合承載生產級 AI Agent；低風險單使用者開發可保留 dsh 或 Docker，任何高風險任意程式碼或多租戶任務的關鍵測試失敗，都應回退到 Linux/KVM 上的 Firecracker 路徑。
這篇適合三類讀者：在 Apple Silicon Mac 上建立可重複執行環境的平台工程師、負責審查不可信程式碼的安全人員，以及要決定本地 Mac、雲端 Mac 或 Linux microVM 的團隊負責人。每項測試都要保存原始指令、輸出、拒絕記錄與回收結果；「能啟動」只能證明執行鏈路可用，不能證明沙箱有效。
最後更新於 2026 年 8 月 22 日；版本與能力資料核實自 Apple Container 官方 README、發布記錄、dsh 沙箱文件及 Firecracker 官方文件。
驗收分級與放行門檻
可上線
只有在全部關鍵隔離測試都有可重現證據時，才可把 Apple Container AI Agent 沙箱標為可上線。放行記錄至少應包括：
- 工作區外的讀取與寫入均被拒絕。
- 宿主環境變數、SSH 測試憑據及 API 密鑰不能被工具取得。
- 未授權域名、內網地址、宿主服務與特殊地址均按預期拒絕。
- CPU、記憶體、程序數及儲存空間耗盡測試不會拖垮宿主。
- Agent 結束後，程序、掛載、暫存資料及網路狀態均已清除。
限制上線
若隔離邊界基本成立，但審計、網路允許名單或資源回收仍未達到團隊的生產要求，只能限制在低風險內部任務。此級別不應處理陌生程式碼、長期持有的生產密鑰或跨使用者資料。
不通過
只要出現以下任一情況，就不能以「目前沒有發生事故」作為放行理由：
- Agent 能讀取工作區以外的宿主檔案。
- 必須長期注入宿主敏感憑據才能正常執行。
- 出站流量沒有邊界，也沒有可信控制層的記錄。
- 強制終止後仍留下程序、掛載或可重用的敏感暫存資料。
- 高風險任務可以無限派生程序或持續寫入宿主儲存空間。
檔案邊界：策略限制與虛擬機不可混淆
驗收應先建立一個授權工作區，內放無害的測試檔案，再在工作區外放置誘餌檔案。Agent 透過讀檔工具、搜尋工具、壓縮工具和符號連結，依序執行以下測試：
- 讀取
../路徑及經過多重路徑標記的檔案。 - 建立指向工作區外的符號連結，再嘗試讀取其目標。
- 以相對路徑、絕對路徑和重新命名方式繞過工作區限制。
- 嘗試寫入根檔案系統、掛載點及未授權的暫存位置。
- 檢查根檔案系統是否唯讀，以及工具是否能自行增加掛載。
dsh 的本地沙箱文件列出 Seatbelt、bubblewrap 與 Landlock 後端，並提供自訂 runner 介面；這表示它可以按平台採用不同策略，但不代表策略沙箱就是完整虛擬機。dsh 本地沙箱設定也明確把 dsh 標示為 developer preview，驗收報告應記錄實際使用的後端，而不是只記錄「dsh 已啟用」。
Docker 的風險重點通常落在共享核心、權限、掛載及系統呼叫政策。其 seccomp 設定可以收窄可用的系統呼叫，但不能把掛載錯誤或過度授權的容器視為安全。Docker seccomp 官方說明適合用來核對目前設定到底拒絕了哪些系統呼叫。
Apple Container 的工作流則涉及 Mac 上的 Linux 輕量虛擬機。其邊界不同於 Seatbelt，也不同於單純共享核心容器；官方架構說明應與實際掛載設定一併檢查。Containerization 架構文件可用作驗收時的架構依據。
注意： 若測試只在工作區內讀寫成功，並不能證明工作區外不可見。最有價值的證據是一次明確的拒絕：包括被測路徑、執行工具、退出狀態、稽核輸出及沙箱日誌。
憑據暴露：沒有外洩不等於注入方式正確
安全人員應建立專用測試密鑰，而不是把真實生產密鑰放入驗收環境。測試範圍應包括：
- 環境變數中的 API 密鑰、代理設定及雲端憑據。
- 使用者家目錄內的 SSH 設定、金鑰檔與認證代理。
- Agent 設定檔、工作區歷史記錄、工作日誌及錯誤追蹤資料。
- 建置快取、套件快取與工具輸出的隱藏檔案。
- Agent 是否能把測試密鑰寫入檔案、壓縮後交給工具，或透過外連送出。
提示不能只寫「請不要讀取密鑰」。應設計惡意提示，要求 Agent 搜尋檔案、列出環境變數、呼叫模擬上傳工具，再對照沙箱拒絕結果。若只看到模型回覆拒絕，卻沒有工具層拒絕，便不能算完成隔離。
需要長期把宿主密鑰暴露給 Agent 的方案，不宜直接判定為生產可用。較穩妥的做法是短期憑據、狹窄權限、代理代辦，以及每次任務獨立的注入和撤銷流程。這些控制不能取代檔案和網路測試，但能縮小失敗後果。
網路邊界：執行隔離不會自動變成出站防火牆
網路驗收要把「能否連線」和「誰負責放行」分開記錄。至少要測試：
- 預設外連是否開放。
- DNS 解析是否可用，解析本身是否被記錄。
- 未列入允許名單的域名是否遭拒。
- 私有網段、宿主服務與特殊內網地址是否可達。
- 暫時放行後，權限是否能按任務結束撤銷。
- 被拒絕的連線是否在可信控制層留下時間、目的地與任務識別。
如果 Agent 可以任意瀏覽網路，陌生程式碼便可能下載額外工具、探測內部服務或外傳工作區內容。Apple Container 的虛擬機邊界本身不等於完整網路過濾；出站規則、DNS、審計及臨時授權必須由明確的網路控制層負責。
這也是判斷「Docker 執行 Agent 是否不安全」時容易出錯的地方。Docker 不是因為名稱就必然不安全，Apple Container 也不是因為使用虛擬機就必然安全。真正的判斷對象是權限、掛載、系統呼叫、出站政策和證據鏈。
資源與回收：把失控任務當成正常測試
資源測試應使用可終止的故障程式，不要直接在共享環境執行無限期攻擊。測試案例可包括死循環、快速派生程序、連續寫入磁碟、超時工具和外部強制終止。每次都記錄：
- 限制是否在執行時生效，而非只在設定檔中出現。
- 超時後是否真的停止子程序。
- 磁碟寫入是否有上限，以及清理是否會影響其他任務。
- Agent 主程序退出後，背景程序是否仍存在。
- 掛載、暫存資料、socket 和網路規則是否恢復到乾淨狀態。
不要自行推算啟動時間、並發容量或資源開銷。這些結論必須引用官方資料或本站實測；本篇沒有可公開核對的本站雲端 Mac 驗收記錄，因此不提供虛構的性能數字。Apple Container 截至 1.2.0 的發布狀態可由官方 Releases 頁面核對；運行要求應以官方 README 所列的 Apple Silicon 與 macOS 26 條件為準。
驗收 FAQ：由測試結果決定方案
上線前可把報告交給開發、平台及安全團隊共同簽核。若某個失敗項目沒有明確負責人、補救期限和重新測試指令，報告仍不具備放行價值。
Apple Container 執行陌生程式碼
Apple Container 可以成為受控執行環境，但「可執行」不等於「可安全執行」。對不可信程式碼，檔案、密鑰、網路、資源和回收五類測試都要有拒絕或清理證據。高風險任務若任一關鍵項目失敗，應暫停上線，而不是關閉沙箱。
dsh Seatbelt 的隔離範圍
Seatbelt 主要是程序層級的政策約束。它可以限制檔案和部分系統能力，但不能被描述成與完整虛擬機相同的邊界。dsh 的自訂 runner 只是擴充介面；它不表示 dsh 已提供現成 Firecracker 適配器，也不會自動完成 Linux/KVM 宿主加固。
Firecracker 的遷移條件
Firecracker 應在高風險任意程式碼、多租戶或 Apple Container 關鍵隔離測試失敗時進入評估清單。它的設計建立在 Linux 與 KVM 等條件上，並要求生產宿主採取額外加固措施；Firecracker 設計文件與生產宿主建議都應納入審查。
方案決策條件
以下條件分支可直接放進上線評審表：
- 若任務是單使用者、低風險、工作區明確，且檔案、密鑰、網路、資源及回收測試全部通過，則可保留 Apple Container。
- 若任務主要是可信程式碼建置，且團隊已有嚴格掛載與 seccomp 管理，則可保留 Docker，但必須持續保存策略設定和拒絕日誌。
- 若需要本地快速執行，dsh 後端測試通過且任務不涉及高風險陌生程式碼，則可把 dsh 當作開發或內部環境，而非完整虛擬機替代品。
- 若涉及多租戶、長期敏感憑據或任意程式碼，且 Apple Container 的任一關鍵隔離項目失敗，則回退到 Linux/KVM 上的 Firecracker 評估，不要以放寬政策換取通過。
- 若團隊無法保存可複核的測試證據，則結果只能列為限制上線，先補齊測試框架和審計流程。
上線方案對照
| 驗收對象 | 主要邊界 | 可接受任務 | 不能直接推定的能力 |
|---|---|---|---|
| dsh 本地沙箱 | Seatbelt、bubblewrap 或 Landlock 等策略後端 | 低風險單使用者開發 | 不等於完整虛擬機；仍是 developer preview |
| Docker | 容器、掛載與 seccomp 政策 | 可信建置、受控工具鏈 | 不會自動封鎖錯誤掛載或所有出站流量 |
| Apple Container | Mac 上的 Linux 輕量虛擬機工作流 | 通過完整驗收的單租戶或受控任務 | 虛擬機邊界不自動提供網路允許名單 |
| Firecracker | Linux/KVM microVM | 高風險隔離與多租戶評估 | 不代表已配置好生產宿主加固 |
證據包對照
| 測試包 | 必留資料 | 通過條件 | 失敗後處置 |
|---|---|---|---|
| 檔案包 | 測試路徑、工具輸出、拒絕日誌 | 工作區外不可讀寫，符號連結不能越界 | 禁止生產放行，先收窄掛載 |
| 憑據包 | 假密鑰、環境快照、工具呼叫記錄 | Agent 和工具均不能取得未授權憑據 | 移除長期注入，改用短期授權 |
| 網路包 | DNS、目的地、策略日誌 | 未授權外連與內網探測被可信層拒絕 | 加入出站控制和審計 |
| 資源包 | 限制設定、程序樹、終止結果 | 耗盡與超時可控，子程序完整停止 | 降級為內部測試或更換執行時 |
| 回收包 | 任務前後清單、掛載及暫存檢查 | 無殘留程序、掛載、資料和規則 | 阻斷重用，修正生命週期控制 |
成本與交付選擇
| 方案 | 交付工作 | 適合的驗收用途 | 主要代價 |
|---|---|---|---|
| 本地 Apple Silicon Mac | 自行管理 macOS、沙箱、日誌與清理 | 固定開發者、可接觸實體介面的任務 | 環境差異和宿主維運責任由團隊承擔 |
| 雲端 Mac 臨時環境 | 先固定 macOS、Apple Silicon 與任務腳本，再重跑 PoC | 上線前重現、跨環境驗收與保存證據 | 需要安排交付、連線、權限和資料清理 |
| Linux/KVM microVM | 建立加固宿主、映像、網路與回收流程 | 高風險任意程式碼、多租戶隔離 | 平台設計和安全維運複雜度較高 |
由驗收結果安排下一步
完成測試後，團隊應把失敗項目分成「設定錯誤」「控制層缺失」和「執行時邊界不適合」三類。第一類可加固掛載、權限或 seccomp；第二類要補上出站代理、密鑰代理和審計；第三類則應評估 Firecracker，而不是繼續堆疊提示詞規則。
Apple Container 適合需要 Mac 工作流、Apple Silicon 相容性和任務級隔離的團隊，但前提是每項控制都能被觀察和重現。若版本、macOS、掛載方式或 Agent 工具鏈改變，驗收不能沿用舊報告。可先參考 ProxyMac 的支援說明 整理環境交付與連線條件，再查看 ProxyMac 的香港 Mac 租用方案 評估臨時驗收環境，然後把同一組測試腳本帶到目標環境重跑。
若目前方案是單一長駐 Mac 或未經限制的 Docker 主機，常見缺點是宿主權限容易累積、任務間清理不完整，以及網路和密鑰責任分散在多個工具中；若改用 Linux microVM，又會增加 KVM 宿主、映像更新和維運負擔。對需要短期重現 Apple Silicon、固定 macOS 條件或驗收雲端交付的團隊，租用 ProxyMac 的 Mac 環境會比臨時改造現有主機更容易保留同一套測試證據。重點不是預先承諾某個安全等級，而是整理 macOS 版本、Apple Silicon 環境、並發方式與隔離腳本，取得臨時環境後逐項重現並保存結果；有了這份證據，團隊才知道應該保留 Apple Container、加固 Docker，還是正式遷移 Firecracker。
