程式碼代理已經可以替你修改檔案、執行 Shell 命令，但你無法確認它是否會碰到工作目錄以外的資料。
最快解法：本週先把團隊基線定為逐項審批；只讀分析使用 plan，完成目錄隔離、憑據保護與回滾驗收後，才在限定工作區啟用 auto，yolo 不作日常模式。
這篇指南適合誰
這篇內容適合需要制定 DAO-Code 使用基線的技術負責人，也適合保護程式碼庫、API Key 和建置憑據的安全工程師。
如果你要批量交付 DAO-Code 開發環境，本文的重點是驗收條件，不是背誦模式指令。
模式邊界
DAO-Code 官方 README 與安全策略目前列出 plan、default、acceptEdits、auto、bypassPermissions 等執行方式，並說明分層規則、敏感目標確認、審計日誌及可選系統沙箱。這些是專案方公布的安全設計，不等於第三方安全認證，也不能證明所有插件、Hooks 或 MCP 服務都安全。
| 模式 | 適合工作 | 人工控制 | 團隊風險判斷 |
|---|---|---|---|
| plan | 只讀分析、陌生程式碼庫、變更規劃 | 不允許直接修改 | 最適合作為初次接觸基線 |
| default | 日常開發、程式碼審查後修正 | 編輯與命令逐項確認 | 團隊預設選項 |
| acceptEdits | 已信任工作區的連續編輯 | 編輯確認減少，命令仍需檢查 | 只適合邊界清楚的任務 |
| auto | 已隔離且完成驗收的測試工作 | 大幅減少逐項確認 | 只在限定目錄使用 |
| bypassPermissions | 高度自動化測試 | 幾乎放棄權限攔截 | 不應用於正式團隊工作 |
因此，「自動」不等於「安全」，「手動確認」也不等於完整防護。你仍然要檢查規則是否真的覆蓋檔案、Shell、外部連線和子程序。可先閱讀DAO-Code 官方 README 的模式說明，再以官方安全策略核對目前版本的實作。
操作範圍與目錄規則
團隊最容易忽略的不是讀取，而是「代理可以寫到哪裡」。一個任務可能同時涉及：
- 讀取專案檔案、環境設定與測試輸出。
- 編輯工作目錄內的程式碼。
- 執行套件安裝、建置、測試或 Git 命令。
- 透過子程序讀取工作目錄以外的檔案。
- 由 MCP 工具或外部輸入觸發網路請求。
先把規則分成 allow、ask、deny 三層，而不是只設定一個「允許自動執行」開關。敏感路徑應明確列入 deny 或強制 ask，包括 SSH 設定、雲端憑據、環境檔、部署金鑰、正式建置目錄及家目錄中的其他專案。
尤其要做一次越權寫入測試。建立一個可刪除的測試檔案，讓任務嘗試寫入工作目錄上層、另一個專案目錄和敏感路徑。你要觀察實際結果，而不是只看設定檔是否看起來正確。若 deny 在 auto 模式下失效，模式上限應立即退回 default 或 plan。
注意：macOS Seatbelt、系統沙箱和 DAO-Code 自己的權限規則不是同一層控制。你需要確認目前部署是否真的啟用了 Seatbelt，以及沙箱涵蓋的是主程式、子程序，還是只有特定工具。Apple 對 macOS App Sandbox 的說明可作為系統層權限檢查參考，但不能代替 DAO-Code 的實際驗收。
憑據、網路與日誌
API Key、SSH 設定、雲端存取權杖和專案密鑰，往往不是直接出現在提示文字中，而是透過環境變數、Shell 輸出、錯誤訊息或記憶功能間接暴露。你至少要檢查以下位置：
- DAO-Code 的提示、記憶和工作階段紀錄。
- Shell 命令與失敗輸出的日誌。
- 子程序繼承的環境變數。
- MCP 工具收到的參數與回傳內容。
- 審計檔案、暫存檔及錯誤追蹤系統。
官方安全策略若提供敏感目標強制確認、秘密掃描、SSRF 防護或系統鑰匙串選項，應逐項確認目前版本是否啟用，以及規則是否能覆蓋你們使用的工具。功能存在不等於已完成安全審計。OWASP 的 AI Agent 安全建議也提醒，代理的工具權限、外部輸入和秘密管理需要分開控制。
| 驗收項目 | 通過條件 | 未通過時的回退 |
|---|---|---|
| API Key | 不進提示、命令輸出、記憶或審計明文 | 改用短期憑據，停用 auto |
| SSH 設定 | 讀取與修改均需確認，或完全拒絕 | 移出工作環境 |
| MCP 連線 | 網域、方法和輸入參數有明確白名單 | 只用 plan 或停用工具 |
| SSRF 防護 | 內部位址與不必要外連被攔截 | 禁止網路工具 |
| 日誌脫敏 | Token、金鑰和個人資料不以明文留下 | 收緊日誌權限並清理舊紀錄 |
審計日誌也可能成為新的秘密洩露面。日誌應記錄誰批准、何時執行、執行了哪項操作及結果，但不應保存完整憑據。可參考 OWASP 日誌安全詞彙與建議，建立脫敏、保存、查閱和刪除規則。
失敗恢復與責任追蹤
自動模式真正的成本，通常在錯誤修改發生後才出現。你需要確認三層恢復能力：
- 代理層：shadow-git 是否在操作前建立檢查點？恢復命令是否能撤銷測試變更？
- 專案層：專案自身的版本控制是否乾淨？恢復是否會改動正式 Git 歷史？
- 環境層：工作區能否重新建立？若依賴、容器或暫存檔被改壞，是否能直接重置？
shadow-git 檢查點只能當作輔助，不應取代團隊版本控制、分支保護或審查流程。你應在可刪除副本中故意製造錯誤修改，再執行恢復，確認新增檔案、刪除檔案、重新命名和未追蹤檔案是否都能處理。若恢復會污染正式 Git 歷史，auto 就不適合作為該工作區的預設。
審計記錄要能回答四件事：誰批准、哪個代理執行、碰了哪些檔案或命令、結果是否成功。模式由 default 改成 auto，也應留下變更理由、審批者和有效期限。這種做法與 NIST DevSecOps 參考模型所強調的可追蹤流程方向一致。
團隊模式決策清單
依照以下條件選擇，不要先按「最快」決定：
- 若是陌生程式碼庫、外部提交或只讀研究，選 plan；否則進入下一項。
- 若工作需要修改一般程式碼，但尚未完成越權、秘密和恢復測試，選 default；不要直接開 auto。
- 若工作區只包含可銷毀測試資料，allow、ask、deny 已通過越權測試，且 shadow-git 和環境重置都驗收成功，才可在限定目錄選 auto。
- 若任務涉及正式憑據、不可逆命令、部署、資料刪除或未審查 MCP，回退到逐項確認；即使效率較低也不要放寬。
- 若必須使用 bypassPermissions 或 yolo，只有在不含憑據、不可連到正式服務、可隨時銷毀的隔離環境中考慮。
- 若平台無法提供獨立工作區、重置流程或可查閱審計，團隊模式上限維持 plan 或 default。
這個分支的重點，是把「效率」和「控制權」分開衡量。完成一次驗收，不代表日後永遠安全；DAO-Code、MCP 機制、Hooks、沙箱參數或安全策略變更後，都要重新測試。
常見疑問
請把 FAQ 當作上線前的快速複核，而不是安全保證。若答案涉及你們的正式憑據或不可逆操作，應由安全工程師在隔離環境中重做測試。
團隊如果目前是在本機直接共享工作區，先不要急著提高自動化權限。你可以先透過Hashvps 的支援中心確認遠端環境交付與使用問題，再把工作區、日誌和恢復流程寫成團隊標準。
從本機工作區轉向隔離環境
本機直接啟用 DAO-Code 的缺點很具體：工作區可能與個人 SSH 設定共存；記憶體、硬碟和容器資源會與其他開發工作爭用；多人共用同一台 Mac 時，審計責任和環境重置也不清楚。若你需要的是短期測試、批量驗收或可快速銷毀的團隊工作區，雲端 Mac 租賃通常比改造每台本機更容易維持一致性。
Hashvps 的遠端 Mac 方案可作為評估方向，但你仍應先確認隔離方式、重新交付流程、權限邊界和日誌責任；不要因為環境在雲端，就把 auto 視為免驗收。需要比較可用方案時，可查看Hashvps 方案詳情，並把越權、憑據保護與恢復測試列為交付前條件。對長期固定重負載、需要實體介面或必須完全掌控硬體的團隊，自購 Mac 仍可能更合適；但對臨時算力、隔離測試和可重置工作區，租賃 Hashvps 的遠端 Mac 往往更容易先把安全基線跑通。
為團隊自動化流程準備一台隔離的雲端 Mac
使用 Hashvps 原生 macOS 雲端 Mac，將 DAO-Code 與團隊程式碼庫放在獨立環境中執行，降低對日常工作裝置的影響。
每台實例提供獨享公網 IPv4，配合 SSH 與 VNC 遠端連線，方便依團隊流程分離操作與管理。