DAO-Code 自动执行安全吗？2026 团队模式选择指南

你发现 DAO-Code 能读文件、改代码、执行 Shell，却不知道一次误操作会不会碰到密钥或仓库外目录。

最快解法：团队默认使用逐项审批；陌生仓库先用 plan，只有完成目录隔离、敏感信息保护和回滚验收后，才在限定工作区启用 auto。yolo 不适合正式项目，只能放在不含凭据、可随时销毁的隔离测试环境。

现在先做： 把团队默认模式设为逐项审批，并禁止在生产凭据目录中运行 DAO-Code。
本周再做： 准备一个可重置的 macOS 工作区，完成越权写入、密钥暴露、网络访问和恢复测试。

这篇文章适合三类人：

需要为团队制定 DAO-Code 使用基线的技术负责人；
负责保护代码仓库、API Key 和构建凭据的安全工程师；
准备批量交付 DAO-Code 开发环境的平台管理员。

模式选择：先限制风险上限，再谈效率

DAO-Code 官方仓库将它定义为可以读取代码、写入文件、执行命令的终端 AI 编程代理。它提供 plan、default、acceptEdits、auto 和 bypassPermissions 等权限方式，也支持 allow、ask、deny 分层规则。这里的功能说明是项目方的安全设计，不等于第三方安全认证，也不能替代团队自己的验收。具体模式和规则可查看官方 README与官方安全策略。

你需要先区分两件事：

提高操作效率：减少重复确认，让可信任务更快完成；
放弃人工控制：允许代理连续执行，扩大错误修改、凭据泄露和网络调用的影响范围。

因此，模式不能按“哪个最快”来选，而应按任务的最大风险来设上限。

决策条件列表

若仓库来源不明、包含第三方脚本或刚接入 MCP，选择 plan，只允许读取和提出方案。
若任务会修改团队代码，但每次变更都需要有人确认，选择默认逐项审批。
若目录已固定、凭据已隔离、网络访问有范围限制，并且恢复测试通过，才考虑在该工作区使用 auto。
若任务涉及生产账户、部署、支付、删除数据、修改权限或不可逆命令，回退到逐项审批。
若环境可以随时销毁，且不放入 API Key、SSH 配置、云凭据和客户数据，才可以在隔离测试中短时使用 yolo。
若任何一项无法验证，不要用更高权限模式“试试看”，直接回退到更保守的模式。

安全指标：操作范围、凭据、隔离、恢复和审计

没有任何自动执行模式可以被简单称为“绝对安全”。安全性取决于代理能访问什么、能修改什么、能调用哪些工具，以及出错后能否恢复。

1．操作范围：读取、编辑、Shell 和网络不是同一风险

只读分析通常只涉及代码读取和解释。文件编辑会改变工作区，Shell 命令可能安装依赖、生成构建产物或修改系统状态，网络工具则可能把数据发送到外部服务。

DAO-Code 的规则支持按工具、路径和命令前缀配置 allow、ask、deny。官方 README 说明，deny 优先级高于普通允许规则，复合命令会按片段检查；例如一条命令中只要有一个被拒绝的子命令，整行就不应放行。

你不能只检查“当前目录是否正确”，还要检查以下边界：

是否能通过 ../、符号链接或绝对路径写入工作区外；
是否能读取 ~/.ssh、云凭据、Shell 配置和项目外的密钥文件；
是否能通过 Shell 启动另一个未受控的脚本；
是否能访问未经审查的 MCP 工具；
是否能通过网络请求把文件内容发送到外部地址。

2．权限规则：deny 必须在 auto 下仍然生效

团队配置中，敏感目录和高风险命令应该优先使用 deny，而不是只依赖人工记忆。官方文档说明，deny 是硬阻断规则，即使进入 YOLO，也不会因为自动批准而失效；危险命令和敏感目标还应继续触发保护逻辑。

你至少要准备三类越权测试：

请求 DAO-Code 修改工作目录外的临时文件；
请求它读取脱敏的测试密钥文件；
请求它执行带有管道、重定向或链式连接的危险命令。

测试结果不能只看终端提示。你还要确认目标文件没有变化、命令没有真正启动、审计记录能定位到被拒绝的原因。

3．凭据保护：功能声明不等于完整秘密审计

DAO-Code 的安全策略提到敏感目标确认、秘密扫描、子进程环境脱敏、SSRF 防护和可选系统钥匙串。项目方还声明，敏感 API Key 不应进入持久记忆，子进程不应直接获得例如 DEEPSEEK_API_KEY 的敏感环境变量。

但你仍要把以下位置逐项检查：

~/.dao/config.json 是否明文保存密钥；
会话日志、调试输出、错误堆栈是否包含完整 API Key；
MCP 工具参数是否携带访问令牌；
子进程环境变量是否继承云平台凭据；
记忆、摘要或任务通知中是否出现私密配置；
构建日志和审计文件是否把请求头、URL 参数或密钥片段写进去。

相关安全建议强调，AI Agent 应遵循最小权限，为不同工具配置不同访问范围，并对敏感操作要求明确授权。对 MCP 场景，还应特别关注令牌管理、工具调用权限和外部数据导致的间接提示注入。(AI Agent 与 MCP 安全建议)

4．隔离边界：macOS Seatbelt 只能作为一层防线

DAO-Code 官方安全策略说明，可选择启用 macOS Seatbelt 或 Linux bubblewrap，让工作区可写、其他位置受限，并可通过选项禁用网络。

这能降低失控进程的影响范围，但不要把它理解为“开启后就安全”。macOS 的 App Sandbox 原理也是限制文件系统、网络和其他进程访问，从而降低被攻破程序的潜在损害；它并不能保证应用内部没有漏洞。(Apple 平台沙箱说明)

你要验证的是实际边界，而不是环境变量是否存在：

工作目录内可以创建、编辑和删除测试文件；
工作目录外的敏感路径无法读取或写入；
关闭网络后，代理不能访问外部地址；
符号链接不能把写入操作绕到受保护目录；
MCP 服务不能自动获得比主任务更大的权限；
沙箱失败或参数错误时，系统是否默认拒绝，而不是静默放行。

注意：如果你不能确认 Seatbelt 的实际参数、继承关系和网络策略，就不要把“已启用沙箱”写进团队合规结论。先用可观测测试验证，再决定是否允许 auto。

5．恢复能力：shadow-git 不替代正式版本控制

DAO-Code README 提到，shadow-git 会把工作树快照保存到独立目录，/restore 或 /rewind 可以恢复最近的变更，并且不会改写正式 .git 历史。

这降低了恢复成本，但不能代替正式版本控制、代码评审和备份。团队应分别验证：

多文件修改后能否恢复到任务开始前；
恢复操作是否会影响正式 Git 分支；
进程中断后检查点是否仍然可用；
磁盘空间不足时是否会明确失败；
外部程序同时改文件时，恢复结果是否可识别；
无法恢复时，是否能重新交付干净环境。

团队基线：不同仓库和任务采用不同模式

只读分析与陌生仓库：选择 `plan`

plan 适合代码评估、架构梳理、依赖分析和问题定位。官方说明中，plan 会拒绝写入和执行请求，只保留读取与方案提出。

在陌生仓库中，README、脚本、Hooks 和配置文件都可能携带未审查指令。你应先让 DAO-Code 读取和解释，不要在第一次启动时就信任项目目录。这样做的重点不是“相信模型不会犯错”，而是先阻断副作用。

可信仓库的常规开发：默认逐项审批

对个人可信仓库或已经过审查的团队仓库，逐项审批通常是更合适的默认基线。它保留人工判断，又不会完全放弃 DAO-Code 的连续工作能力。

审批时不要只看“修改了哪个文件”，还要看动作类型：

修改源代码：确认目标路径和差异范围；
执行测试：确认命令不会上传数据或删除构建目录；
安装依赖：确认包来源和锁文件变化；
网络访问：确认域名、请求目标和上传内容；
修改配置：确认是否影响凭据、CI/CD 或部署账户。

限定工作区的重复任务：验收后使用 `auto`

auto 适合边界清晰、重复度高、可自动验证的任务，例如格式化、生成测试、修复局部类型错误或在临时分支中运行测试。

上线前至少满足以下条件：

工作目录是独立副本，不连接生产凭据；
allow 只覆盖明确的工具和路径；
敏感目录和危险命令使用 deny；
网络访问按域名或工具范围限制；
测试失败时有自动停止条件；
shadow-git 检查点可以恢复；
审计记录能区分操作者、任务、命令和结果；
任务完成有明确验收命令，而不是由模型自行判断。

正式项目与生产凭据：不要使用 `yolo`

yolo 或 bypassPermissions 的核心问题不是“模型一定会执行恶意操作”，而是人工审批被大幅削弱。只要工作区中存在生产密钥、客户数据、部署权限或不可逆命令，错误判断的影响就可能直接扩大。

因此，yolo 只适用于一次性的隔离测试，并满足三个条件：没有凭据、没有真实客户数据、环境可以销毁重建。正式项目、生产部署和包含客户代码的共享环境，都应保留人工确认。

上线验收：七步完成 auto 模式检查

第 1 步：建立无凭据的测试副本

从正式仓库复制一个最小项目副本。删除 API Key、SSH 配置、云平台令牌、生产环境变量和真实客户数据。不要直接把团队主仓库作为第一次验收对象。

第 2 步：确认工作目录边界

记录工作目录的绝对路径。检查符号链接、挂载目录、共享目录和 additionalDirectories 配置。对项目外路径分别执行读取和写入测试，确认规则不是只拦截常见相对路径。

第 3 步：配置 allow、ask、deny

建议采用“默认询问、少量允许、敏感路径拒绝”的结构：

Read：只允许项目目录和必要的依赖缓存；
Edit：只允许源代码、测试和生成目录；
Bash：只允许固定命令前缀；
WebFetch：只允许必要域名；
MCP 工具：逐个登记，不使用全量通配；
.ssh、云凭据、Shell rc、系统目录：明确拒绝。

第 4 步：执行越权写入测试

让 DAO-Code 尝试修改工作目录外的测试文件，再尝试通过符号链接写入受保护位置。两次都应失败，并在日志中留下可定位的拒绝记录。

“没有看到文件变化”还不够。你要保存命令、目标路径、规则命中结果和最终文件校验值，方便后续复核。

第 5 步：执行秘密暴露测试

放入假的 API Key、假的 SSH 私钥和假的云凭据。让代理完成正常编码任务，再检查：

会话日志；
审计日志；
.dao 下的记忆和临时文件；
子进程环境；
MCP 请求参数；
构建和测试输出。

测试密钥必须是不可用的占位值，不能拿真实凭据做“验证”。

第 6 步：验证 shadow-git 与正式 Git 的分离

先让 DAO-Code 修改多个文件，再执行恢复操作。确认工作区回到测试前状态，同时确认正式 .git 的提交、分支和历史没有被改写。

还要测试恢复失败场景：磁盘空间不足、进程中断、文件被外部程序修改时，团队是否知道该回退到正式 Git、临时副本或重新交付环境。

第 7 步：检查审计与责任归属

官方安全策略提到，写入、执行和网络工具裁决会写入 .dao/audit.log。但团队仍需定义：

谁批准高风险操作；
谁复核每日或每次任务日志；
谁负责处理秘密泄露；
模式从 default 切换到 auto 时如何留痕；
审计文件保存多久；
日志本身如何脱敏和限制访问。

安全日志建议强调，事件应记录足够的决策信息，但避免把完整提示词和完整工具输入输出直接写入日志。(日志安全建议) DevSecOps 参考模型也把最小权限、环境隔离、审计和恢复作为开发环境的持续控制，而不是一次性配置。(DevSecOps 参考模型)

工作目录限制：让代理只能修改指定范围

限制 DAO-Code 只能修改工作目录，不能只依赖一句系统提示。应同时使用文件规则、命令规则、操作系统隔离和测试验收。

推荐顺序如下：

用独立副本作为工作区，不在用户主目录直接运行；
Edit 只允许工作区内的路径模式；
对工作区外路径设置 deny；
禁止通过 additionalDirectories 预授权过大的目录；
限制 Shell 命令前缀，禁止任意脚本执行；
启用 macOS Seatbelt，并验证工作区外访问；
对符号链接、硬链接和挂载路径做单独测试；
给每个任务配置验收命令和恢复点。

如果团队要批量交付环境，可以把这些规则写进版本化配置，再由安全工程师审核变更。不要让每个开发者自行复制一份“看起来差不多”的权限文件。

你可以先参考 Hashvps 的帮助中心整理环境交付和权限说明，再把 DAO-Code 的规则文件、沙箱参数和重置步骤纳入团队文档。

模式对比：审批、隔离和恢复能力

模式	适合任务	人工控制	目录越权风险	凭据处理要求	推荐级别
`plan`	陌生仓库、只读分析、架构梳理	高	低，写入与执行被拒绝	不放入真实凭据	✅ 首次接入
`default`	常规开发、代码修复、测试	高	取决于规则配置	使用假凭据或受控凭据	✅ 团队默认
`acceptEdits`	低风险批量编辑	中高	编辑范围必须限制	禁止读取生产密钥	⚠️ 需审查
`auto`	隔离工作区内的重复任务	中低	规则错误时扩大	沙箱、秘密扫描和审计必须通过	⚠️ 验收后使用
`yolo`	可销毁、无凭据的临时测试	低	最高	不得包含真实数据和凭据	❌ 不用于正式项目

环境选择：让模式和工作区绑定

团队场景	工作区要求	建议模式	必须满足的前置条件
陌生开源仓库	独立副本	`plan`	先审查脚本、Hooks、MCP 和配置
已审查的内部仓库	普通开发分支	`default`	每次写入、命令和网络操作逐项确认
自动生成测试	可重建工作区	`auto`	`deny` 规则、shadow-git、验收命令和审计均通过
MCP 工具探索	无生产数据的沙箱	`plan` 或 `default`	单独限制工具、令牌和网络目标
生产部署或数据迁移	受控发布环境	`default`	人工审批、双人复核和独立发布流程
一次性能力测试	可销毁临时环境	`yolo`	无凭据、无客户数据、测试结束即重置

安全团队可以参考AI Agent 开发环境隔离清单的环境隔离思路，把“工作区、凭据、网络、日志、恢复”拆成独立控制项。若需要远程交付多个干净环境，也可以查看 Hashvps 的套餐详情，重点确认环境是否支持独立使用、重新交付和按任务重置；不要只比较 CPU 或内存参数。

当前本地方案与 Mac 远程方案：先解决隔离，再谈算力

如果你直接在团队成员的本地 Mac 上启用 DAO-Code，常见问题不是工具无法运行，而是环境边界难以统一：开发者可能共用个人 SSH 配置，项目目录和私人文件混在一起；不同成员的权限规则、MCP 配置和日志保存方式也不一致；发生误改后，还要依赖个人备份或手工恢复。

对于短期测试、批量交付和需要频繁重置的任务，Hashvps 的远程 Mac 方案更适合先建立独立工作区，再按团队规则交付。你仍然需要自己配置 DAO-Code 的权限和密钥策略，但可以把“本地设备是否干净、环境能否重置、成员之间是否相互影响”从个人电脑上移开。若团队是长期稳定重负载开发、必须连接本地硬件，或已有成熟的本地隔离体系，自购 Mac 可能更合适；若只是临时验证 auto、沙箱和恢复流程，远程 Mac 往往更容易控制变量。

本周最稳妥的动作不是把所有人切换到 auto，而是先交付一个不含真实凭据的可重置环境，完成越权、秘密、网络、恢复和审计五类测试。测试通过后，只在限定工作区开放 auto；正式项目和生产操作继续保留人工确认。