2026 DeepSeek Harness Mac 沙箱安全嗎：Seatbelt 驗收清單

2026 DeepSeek Harness Mac 沙箱安全嗎，獲勝者取決於程式可信度：受控程式可在 Seatbelt 通過唯讀、工作區寫入、故障停止與權限批准測試後留在本機；高風險倉庫、不可信指令或敏感憑據，應改放專用遠端 Mac 或更高等級的隔離環境。Seatbelt 主要約束檔案系統效果，不能當成完整的主機、網路或程式隔離。

這篇文章適合三類讀者：個人開發者想確認 Agent 會否改寫工作區以外的檔案；安全與平台工程師需要把官方沙箱能力轉成可執行的上線項目；團隊負責人則要在共用辦公室 Mac、專用遠端 Mac 和隔離環境之間作出長期選擇。

最後更新於 2026 年 8 月 21 日；版本與行為資料核實自官方 Releases 頁面、官方沙箱說明及相關策略文件。

2026 DeepSeek Harness Mac 沙箱安全：先看四個上線門檻

DeepSeek Harness 目前仍是 developer preview，官方提醒可能出現破壞相容性的變更；官方 Releases 頁面目前可見的版本是 v0.1.0-rc.8，發布日期為 2026 年 8 月 19 日。版本狀態與預覽提醒必須在部署紀錄中保留，不能把預發布版當作穩定介面。

Mac 沙箱至少要同時滿足以下條件：

• 受限模式真的生效：read-only 和 workspace-write 的策略要在實際呼叫中生效，而不是只在設定檔中顯示。
• 越界寫入被拒絕：工作區外的檔案、未授權的暫存位置，以及經路徑解析後落到外部的目標，都要有可記錄的拒絕結果。
• 執行器故障時停止執行：sandbox-exec 不可用、不可執行或無法接受策略時，Harness 應回傳 SANDBOX_UNAVAILABLE，不能改用非隔離模式。
• 擴大權限需要明確批准：Agent 提出更寬的 sandbox_permissions 時，必須說明理由；拒絕、取消或批准服務無法使用時，命令不得執行。

低風險、由團隊完全掌握的程式，可按這四項驗收後在本機運行。若是陌生倉庫、會自動安裝依賴的 Agent 任務，或需要讀取 API 憑據的長時間工作，未能證明邊界前不應上線。

第一個判斷：本機、專用遠端 Mac，還是更強隔離

以下表格是部署前的決策工具。它不是效能排名，而是把程式可信度、使用者範圍和憑據風險放在同一個判斷框架中。

運行方案	適合的程式與任務	必須先通過的條件	主要缺點
個人本機 Mac	自己維護的程式、短時間測試、低敏感度工作	四項上線門檻全部通過，工作區與憑據分離	主機仍承擔網路、程式與帳戶風險
共用辦公室 Mac	只適合低敏感度、非持續運行任務	每位使用者的工作區、權限與記錄必須分開	共用帳戶、殘留檔案和人工重置容易失控
專用遠端 Mac	團隊 Agent、持續運行、需獨立環境	限制可存取目錄，建立重置與審計流程	需要管理遠端連線、帳戶和環境生命週期
更高等級隔離環境	不可信倉庫、敏感憑據、無法證明沙箱邊界	另行驗證主機、網路和程式隔離	部署與維運成本較高

如果目前只有共用 Mac，卻要求 Agent 持續在線、接觸團隊憑據並自動修改多個倉庫，問題不只是 Seatbelt 設定。共用使用者權限、背景程式、殘留 Token 和難以重置的工作區，會把單一沙箱的價值抵消一部分。

Seatbelt 的 read-only 與 workspace-write 驗收方式

官方沙箱文件將本地後端建立在 Seatbelt 與 sandbox-exec 上。read-only 的重點是讓工作區可讀但不可寫；workspace-write 則允許 Agent 在指定工作區內寫入，同時限制其他位置。danger-full-access 會放寬這些約束，不應用來掩蓋頻繁拒絕。官方本地沙箱 README與沙箱策略解析文件是驗收時應固定引用的依據。

驗收不應只看 UI 顯示的模式名稱。應在可控測試倉庫中，為每次測試保存命令、模式、目標路徑、解析後路徑、退出結果和 Harness 記錄。

四組寫入測試

1. 工作區內寫入
   在 workspace-write 模式下，要求 Agent 建立或修改工作區內的測試檔案。確認檔案確實出現，並記錄實際工作區根目錄。切換 read-only 後重做同一操作，預期是寫入被拒絕。

2. 工作區外寫入
   指定工作區旁邊的測試目錄作為目標。read-only 與 workspace-write 都應分別留下清晰的拒絕結果，不能因為命令本身返回錯誤，就推斷策略已生效。

3. 暫存目錄寫入
   要求 Agent 在作業系統暫存位置建立檔案。暫存目錄是否可寫，必須以目前版本的官方策略定義和實際測試為準，不可把「暫存」一詞直接當成安全例外。測試應記錄解析後的真實位置。

4. 路徑解析與繞行
   測試相對路徑、符號連結、父目錄跳轉及會先建立再重新命名的操作。驗收對象是檔案系統最後解析出的路徑，而不是 Agent 顯示的表面字串。Apple 對沙箱設計的說明也指出，檔案存取控制需要配合實際容器與權限範圍理解，Apple 沙箱設計問答可作為背景依據。

通過標準很明確：read-only 不應成功寫入；workspace-write 只應成功寫入獲准工作區；所有越界測試都要得到可分類的拒絕或錯誤。若某一組測試結果不穩定，應暫停上線，而不是直接改成 danger-full-access。

sandbox-exec 不可用時，會不會繞過沙箱？

這是 Mac 部署中最容易被忽略的故障測試。sandbox-exec 已被 Apple 標示為 deprecated，但目前事實邊界是：官方文件仍描述它隨 macOS 提供；未來是否移除不能寫成已確認事件。Harness 的本地沙箱設計則要求執行器無法使用時採取 fail-closed 行為。官方 Shell 子系統說明應與沙箱文件一併核對。

第二步：把三種失敗分開記錄

• 普通命令失敗：命令本身不存在、參數錯誤或程式返回非零結果。這不代表沙箱拒絕。
• 檔案存取被拒絕：命令啟動了，但 Seatbelt 阻止了目標檔案操作。這才是檔案邊界測試的預期結果之一。
• runnerFailed 或 SANDBOX_UNAVAILABLE：沙箱執行器或策略準備失敗。此時最重要的驗收項是命令沒有轉為非隔離執行。

測試方法可以很小：先在正常環境執行一個無害的檔案讀取，再在受控條件下讓沙箱執行器不可執行或策略無法載入，觀察 Harness 是否停止並回傳不可用狀態。不可為了「讓工作繼續」而加上未經審批的回退路徑。

「有報錯」不是安全證明。只有錯誤類型、命令未執行，以及記錄能對上官方 fail-closed 約定，才算通過。

權限升級：一次批准能否污染下一次呼叫？

Agent 在正常工作中可能提出更寬的 sandbox_permissions。這不應被視為一般設定，而應當作一次高風險例外請求處理。批准理由要具體，例如需要存取哪個目錄、執行哪個命令、完成哪項工作；「工具需要更多權限」不具備足夠審計價值。

第三步：驗證拒絕、取消與批准服務故障

至少要做四個結果測試：

• 審批者拒絕：命令不執行，Agent 收到明確拒絕。
• 審批者取消：命令不執行，不應自動降級為寬鬆模式。
• 批准服務不可用：Harness 應停止該次需要升權的呼叫。
• 審批者批准：只允許該次明確授權的範圍，後續呼叫重新要求批准。

尤其要確認一次批准不會變成整個工作階段的永久權限。若 Agent 能在後續呼叫直接沿用 danger-full-access，驗收應判定不合格。這個模式只能是例外處置，不是解決「每次都被拒絕」的預設方法。

自託管 DeepSeek V4：端點和 API Key 如何避免被工作區劫持？

Seatbelt 約束檔案效果，不等於模型請求、網路流量和密鑰管理已經安全。Harness 採用 MIT 授權，也不代表模型呼叫、自託管推理或運行環境免費；這些是不同層次的成本和風險。接入自託管 DeepSeek V4 或其他相容 API 端點時，應把 Harness 主機與推理端點畫成兩個獨立元件，再按官方 Provider 配置指南核對目前欄位和行為。

四項憑據驗收

1. Base URL
   端點必須來自受信任的環境變數、受保護的密鑰服務或主機層設定。不要讓工作區內可編輯的設定檔成為唯一來源。

2. Provider ID
   將 Provider 識別值列入部署清單，並在啟動記錄中確認實際選用的端點。不能只看預設名稱，因為自訂 Provider 可能指向不同推理服務。

3. 憑據來源
   API Key 不應寫進 Git 倉庫、Agent 可修改的設定檔、命令列歷史或除錯輸出。工作區若可被 Agent 寫入，就不應同時承載受信任憑據。

4. 日誌留存
   記錄請求時間、Provider ID、結果類型和錯誤類別；避免直接記錄完整 Token。對端點變更、認證失敗和模型回退保留可追蹤事件。

最關鍵的反劫持測試是：在工作區放入一份看似合理但指向錯誤端點的可編輯配置，再啟動一次模型請求，確認受信任的 Base URL 和憑據來源不會被它覆蓋。若結果取決於目前版本未清楚說明的優先順序，應視為未驗收，而不是自行猜測配置規則。

優點與限制：Seatbelt 適合哪一種 Mac Agent 任務？

Seatbelt 的優點是邊界相對具體。檔案讀寫可以按模式測試，執行器故障也有 fail-closed 驗收方向。對個人維護的程式、短期測試和低敏感度工作，這已能降低 Agent 直接改寫不相關檔案的風險。

但它的限制同樣要寫在上線決策中：

• 它不是完整的主機隔離，Mac 帳戶和其他背景程式仍在同一主機上。
• 它不是網路出口控制，模型端點、外部服務和資料外傳仍需獨立管理。
• 它不是密鑰保管方案，Seatbelt 通過不表示 API Key 不會出現在日誌或錯誤輸出。
• 它依賴目前的本地沙箱後端；sandbox-exec 的 deprecated 狀態意味著平台團隊要持續追蹤版本變化。
• developer preview 可能破壞相容性，升級後必須重做關鍵驗收，而不是只看啟動成功。

若團隊正在整理 Mac Agent 的最小權限規則，可先參考 ProxyMac 的支援與使用說明，但商業環境仍應以實際版本、主機政策和測試記錄為準。

第四步：用五項指標決定是否遷到獨立遠端 Mac

可把每項指標標成「低、中、高」風險，並保存理由。這不是把主觀分數偽裝成安全保證，而是讓團隊在部署會議中說清楚回退條件。

• 程式可信度：自有程式可先走本機驗收；陌生倉庫或不可信程式直接提高隔離等級。
• 共享使用者數量：單一使用者較容易清理；多人共用同一 Mac 時，應改用專用帳戶或專用遠端主機。
• 持續運行時間：短期互動測試和持續在線 Agent 不同。後者需要環境重置、日誌輪替和故障回復。
• 憑據敏感度：只要會接觸生產端點、付款系統或內部資料，憑據就不應放在 Agent 可修改的工作區。
• 故障恢復要求：若沙箱失效、端點中斷或工作區污染後不能快速重建，應先遷到可重置的獨立 Mac。

判斷結果可以簡化為三段：低風險個人任務在四項沙箱測試全數通過後留在本機；共享團隊任務使用專用遠端 Mac，限制目錄和憑據；無法證明邊界、必須處理不可信倉庫，或需要更強主機與網路隔離時，暫停 Harness 上線。

上線前驗收記錄應留下什麼

每次版本更新、macOS 更新或沙箱後端變更，都應重新建立一份記錄。最低欄位包括：

• Harness 版本與發布狀態；
• 沙箱模式與實際解析後的工作區路徑；
• 四組檔案測試的命令、結果和拒絕原因；
• 執行器不可用時的錯誤類型，以及命令是否確實沒有執行；
• 權限請求的 justification、批准結果和後續是否重新要求批准；
• Base URL、Provider ID、憑據來源與日誌保留規則；
• 測試主機、工作區清理方式和失敗後的回退方案。

截至本文資料核實日，官方仍把 Harness 定位為 developer preview。出現 v0.1 正式版、沙箱後端替換、模式語義變化，或 macOS 不再提供 sandbox-exec 的新資訊時，這份清單都要在 24 小時內重新核對，而不是沿用舊結論。

如果現有方案是共用本機，長期運行的缺點通常不是單一命令失敗，而是帳戶權限混用、工作區難以重置，以及端點憑據容易與開發檔案放在同一層。若改用一般雲端主機，又可能失去 Mac 本地工具鏈、需要自行處理遠端連線與環境重建。當任務需要專用主機、持續在線和可重置環境時，按需租用 ProxyMac 的遠端 Mac 會比把高風險 Agent 長期留在共用 Mac 更容易完成隔離驗收；若只是長期穩定的重負載，或必須直接接觸實體介面，自購 Mac 仍可能更合適。想先比較不同地區方案，可查看 ProxyMac 的香港 Mac 方案資訊，再把本文的驗收結果放進採購決策，而不是先以價格或啟動成功取代安全判斷。