2026 DeepSeek Harness Seatbelt 沙箱：Mac 開發者須知

DeepSeek Harness Seatbelt 沙箱目前應被視為「程式執行約束」，而不是完整安全隔離。建議先在低風險倉庫驗證實際允許與拒絕行為，再決定是否擴大權限，或把工作移到獨立的雲端 Mac 環境。官方架構已列出 Seatbelt 後端，但不能只憑套件名稱、目錄或設定檔推斷特定版本一定預設啟用。(github.com)

這篇文章適合三類讀者：準備讓 DeepSeek Harness 在 Mac 上執行命令的開發者；需要評估 Agent 操作系統隔離邊界的安全工程師；正在制定遠端 Mac 試用範圍與採購計畫的技術負責人。

最後更新於 2026 年 8 月 18 日；資料核實自 DeepSeek Harness 官方 sandbox 套件、官方架構文件，以及平台安全文件，並以隔離測試倉庫作為發布後驗證依據。

先分清兩層：工作區選擇不是 Seatbelt 約束

DeepSeek Harness 官方套件把 sandbox 定義為 process-sandbox capability family，負責為程式執行套用每個工作階段的約束政策。官方套件目錄同時列出 sandbox/、sandbox-local/ 與 sandbox-policy/，代表「能力介面、平台實作、持久政策」是不同層次。(github.com)

這對 Mac 開發者有一個直接影響：工作區路徑只是政策輸入，不是完整安全結論。

• 工作區設定回答「Agent 應在哪個專案內工作」。
• Seatbelt 回答「被包裝的子程式能做哪些檔案操作」。
• 命令審批回答「這次具體操作是否應由人員放行」。
• 網路政策回答「連線是否允許，以及允許連往哪裡」。
• 憑據管理回答「API 密鑰、設定檔和環境變數能否被讀取或外洩」。

任何一層沒有驗證，整體邊界都不能宣稱完整。Apple 對 macOS App Sandbox 的說明也採取相同原則：沙箱是透過權限與資源限制降低受害範圍，不是保證程式本身不會出錯。(developer.apple.com)

深度檢查官方實作狀態

截至本文核實日，官方原始碼把 macOS 指向 Seatbelt，並說明本地提供者會選擇平台 runner；不支援或無法使用的 runner 應以 SANDBOX_UNAVAILABLE 失敗，而不是靜默地改成無約束執行。官方文件亦指出，Seatbelt 依賴 macOS 仍提供的 sandbox-exec，但該命令列工具已被 Apple 標記為 deprecated。(github.com)

因此，發布包驗收不能只看「有沒有 sandbox 套件」。應記錄：

• 實際 DeepSeek Harness 版本與提交版本。
• macOS 版本與 CPU 平台。
• 實際選中的 runner。
• sandbox 是否回報完整執行。
• 被允許的工作區路徑。
• 被拒絕的工作區外路徑。
• runner 無法使用時，程式是否確實停止。

這些紀錄比設定檔裡的一個 seatbelt 字串更有證明力。

檔案讀寫邊界：允許路徑與拒絕路徑要分開驗收

官方 sandbox-local 說明，Seatbelt 的檔案政策採取 allow-default，再加入寫入拒絕與寫入允許清單。文件列出 read-only 與 workspace-write 的不同路徑範圍，並特別提到路徑會先 canonicalize；例如 /tmp 與 /private/tmp 會被視為同一個實際位置。(github.com)

這意味著「不能寫出工作區」不能只用一個正常檔案測試。至少要涵蓋以下情境：

• 工作區內建立檔案。
• 工作區外修改檔案。
• 使用 .. 走出工作區。
• 透過符號連結指向工作區外。
• 寫入暫存目錄。
• 讀取家目錄中的設定檔。
• 讀取另一個專案的原始碼。
• 將輸出導向工作區外的檔案。

驗收結果要保存成功與拒絕的命令輸出。不要只截取 UI 顯示的「已拒絕」。安全工程師需要知道拒絕發生在模型工具層、命令列工具層，還是 macOS 系統政策層。

Seatbelt 沙箱能否阻止 Agent 存取其他目錄？

可以限制，但不能把「工作區選擇」直接等同於「其他目錄必然不可讀寫」。

如果實際 runner 已啟用，且政策確實對子程式生效，工作區外的寫入應該被拒絕；讀取則要按當前模式、檔案權限與政策逐項測試。官方文件明確把 sandbox 描述為 process execution 的約束能力，並沒有宣稱所有檔案工具、網路工具或外掛都自動經過同一個核心邊界。(github.com)

對開發者而言，最危險的誤區是：檔案編輯工具拒絕了某個路徑，就以為 Agent 的所有能力都無法接觸該路徑。實際上，檔案工具、Shell、MCP 與外掛可能是不同的能力提供者。可參考 AI Agent 工作區隔離 的驗收思路，把每個工具面分開記錄。

子程式與建置工具：進程隔離不等於命令安全

DeepSeek Harness 的 sandbox 家族主要處理子程式執行。官方實作說明，受約束的 Shell 會把政策套用到程式執行流程；而官方 Agent Note 也將 Bash 子程式與隨附的 hook 命令列為主要約束對象。(github.com)

風險在於，一條命令可能啟動更多子程式：

• npm、pnpm、cargo 或 xcodebuild 會呼叫其他工具。
• 建置腳本可能讀取環境變數。
• 測試框架可能啟動本地服務。
• Git hook 可能執行未預期的 Shell。
• MCP 服務可能在另一個進程中處理檔案或網路請求。
• 子程式可能繼承目前的工作目錄、環境變數與可用檔案描述元。

Seatbelt 可以限制「實際套用政策的進程能力」，但不會理解 install、deploy、reset 或 publish 的業務後果。它不知道一個合法的建置命令是否會覆寫產物、刪除快取，或把內容上傳到外部服務。

使用沙箱後還需要命令審批嗎？

仍然需要。沙箱與審批解決的是兩個不同問題。

• 沙箱限制命令「能做到什麼」。
• 審批決定命令「是否值得現在做」。

官方 Agent Note 的設計是：命令先在受限政策下執行；若確實被拒絕，Agent 才能針對同一操作請求一次更寬權限的使用者批准，再重試一次。這種設計並不代表所有命令都可以自動放行。(github.com)

對高風險命令，建議保留人工批准：

• 刪除或遷移大量檔案。
• 修改 Git 遠端設定。
• 安裝第三方套件。
• 執行資料庫 migration。
• 開啟外部網路。
• 使用部署、發布或憑據相關命令。
• 啟動不熟悉的 MCP 或外掛。

若團隊為了減少拒絕而直接切換到 danger-full-access，實際上是把防線從系統約束退回到操作者信任。這不是沙箱失效，而是政策被擴大後，原本的風險邊界已經改變。

網路與外部工具：三種連線邊界不能混為一談

macOS 的本地進程限制、DeepSeek Harness 的網路政策，以及 MCP 或外掛自身的行為，是三個不同控制面。

官方 Seatbelt 說明目前集中在檔案寫入與本地 runner 選擇。它沒有提供足夠依據讓開發者宣稱「Seatbelt 預設阻斷所有外部連線」。Apple 的安全文件也把檔案、網路與其他資源視為不同權限面，不能從其中一項推導另一項的結果。

第一輪測試應使用無敏感資料的目標：

• 連線到一個明確允許的測試端點。
• 連線到一個明確拒絕的測試端點。
• 測試 DNS 解析與實際 HTTPS 連線是否一致。
• 測試 curl、套件管理器與 MCP 是否遵守同一策略。
• 測試外掛是否自行建立不經 Harness UI 的連線。
• 記錄命令退出狀態、錯誤訊息與系統日誌。

不要因為某個 curl 命令失敗，就宣稱所有外部工具都被阻斷。也不要因為 MCP 能取得資料，就宣稱 Seatbelt 沒有作用。兩者可能位於不同進程、不同政策或不同連線路徑。

API 密鑰：沙箱不會自動消除憑據暴露

DeepSeek Harness 的官方套件分類中，credentials 是獨立能力家族，代表憑據引用與進程沙箱不是同一項控制。(github.com)

即使 Seatbelt 正常啟用，以下風險仍需獨立處理：

• API 密鑰存在環境變數，可能被診斷命令列出。
• .env、Shell 設定檔或 CI 設定可能位於工作區外。
• 建置失敗輸出可能把密鑰片段寫入日誌。
• Agent 可能把命令輸出當成上下文，再傳送到模型端。
• MCP 或第三方工具可能自行保存請求內容。
• 遠端 Mac 的管理者、備份或監控系統可能接觸設定檔。

驗收材料必須使用假的密鑰與脫敏網域。測試輸出只保留前綴、雜湊或遮罩後的識別值。真實密鑰不應出現在截圖、終端輸出、Issue、錄影或文章範例中。

若測試曾經把真實密鑰送入命令輸出，不能只刪除日誌。應立即撤銷、輪換，並檢查可能接收過該輸出的服務。

遠端 Mac：降低混用風險，但不會自動完成安全配置

獨立的雲端 Mac 可以把 DeepSeek Harness 與個人工作區、瀏覽器登入狀態和私人檔案分開。這能降低混用風險，但不會自動配置安全邊界。

遠端環境至少要分開驗收：

• 遠端連線入口是否只暴露必要服務。
• 系統帳戶是否使用獨立低權限帳戶。
• 工作區是否為測試倉庫，而非整個家目錄。
• Seatbelt runner 是否確實可用。
• MCP、外掛與背景任務是否列有清單。
• API 密鑰是否採用短期、低權限與可輪換憑據。
• 工作完成後是否能刪除工作區、日誌與暫存檔。
• 失敗時是否能關閉危險工具或直接回退環境。

若只是低敏感度展示，先採共享環境也可以，但應限制工作區內容與憑據範圍。若涉及私有原始碼、客戶資料或部署權限，應選獨立環境。若連檔案、程式、網路和憑據四項都無法取得證據，則應暫緩執行，而不是用「只是試用」降低風險判斷。

需要遠端連線時，可先參考 Mac 遠端執行的交付驗收方向，把連線入口、帳戶、工作區和工具策略分項列入交付條件。這比只驗證能否登入螢幕更接近真正的 Agent 安全需求。

同時，若需要了解雲端 Mac 的環境選項，可先查看同一服務的基本環境說明，再按照專案敏感度決定共享、獨立或暫緩執行。頁面資訊只能協助確認環境選項，不能取代 Seatbelt、憑據與網路政策的實測。

第一輪發布驗證：按順序留下可回溯證據

發布後不宜直接把正式倉庫交給 Agent。可採用以下流程：

第一步：鎖定版本與政策。
記錄 DeepSeek Harness 提交版本、安裝來源、macOS 版本、工作區絕對路徑、sandbox 模式、審批政策與外掛清單。

第二步：先確認 runner。
確認實際採用 Seatbelt。若 runner 不可用，測試應停止並回報失敗。不要接受自動退回無約束模式。

第三步：建立低風險測試倉庫。
放入無敏感原始碼、假的設定檔、假的 API 密鑰與可辨識的測試檔案。測試倉庫不可與個人主目錄混用。

第四步：測試檔案邊界。
分別測試工作區內讀寫、工作區外讀寫、符號連結、.. 路徑、暫存路徑與另一個專案路徑。每次只改變一個變數。

第五步：測試進程邊界。
讓 Agent 執行會啟動子程式的建置與測試命令。記錄子程式名稱、父子關係、退出狀態和被拒絕的操作。確認 hook 和腳本沒有繞過原本的工作區限制。

第六步：測試網路與 MCP。
使用無敏感資料的允許與拒絕端點。分開測試 Shell、套件管理器和 MCP。不要將一個工具的結果套用到其他工具。

第七步：測試憑據流向。
使用假的密鑰檢查環境變數、設定檔、終端輸出、工作階段記錄與外掛日誌。確認輸出不會直接暴露完整值。

第八步：準備回退動作。
驗證失敗時，能否關閉危險 Shell、停用外掛、撤銷密鑰、刪除測試工作區，或把任務移到獨立遠端 Mac。沒有回退動作的測試，只能算觀察，不能算安全驗收。

完整執行時，可把這份流程延伸到 DeepSeek Harness 的安全驗收與回退清單。若需要持續執行，再補做雲端 Mac 交付驗收，確認交付環境與實際測試環境沒有差異。

本地 Mac、共享雲端 Mac、獨立雲端 Mac 怎樣選

這個選擇不是「本地一定安全」或「雲端一定隔離」。如果目前方案把個人工作區、瀏覽器登入狀態和 Agent 混在同一台 Mac，問題在於混用、殘留與權限不可見；如果改用未驗收的雲端主機，問題則可能轉移到遠端入口、系統帳戶、插件和背景程式。SFTPMAC 的雲端 Mac 方案較適合臨時算力、測試環境或需要與日常工作區分開的任務，但仍應先完成上述驗收，而不是把租用本身當成安全保證。

Seatbelt 後端的價值，在於為 macOS 上的進程執行提供一個可驗證的系統級約束點。它不能取代工作區權限、命令審批、網路政策、憑據輪換或遠端環境管理。對目前的 DeepSeek Harness 試用，最穩妥的做法是：先用低風險倉庫取得檔案、進程、網路與憑據證據；證據不完整，就維持小範圍試用或回退到獨立環境。