编程智能体的隔离不能只靠 worktree

给 AI 编程代理开一个独立 worktree，代码就有了单独的落点，交付时也方便看 diff。但文件分开，不代表权限隔离：代理进程可能仍然读得到你的主目录、其他项目的凭据，也可能连接任务之外的服务。

原文借 DeepSeek 的 dsh-superagent-prototype 提出一个部署问题：代理到底继承了谁的权限？作者没有做安全实测，而是梳理了几种容易混淆的控制手段，并提出运行前的检查流程。它适合用来审视你准备交给代理的那台机器。

worktree 管的是改动位置，谁来管访问权限

worktree 能让任务拥有独立的工作目录，方便并行开发和审查补丁。它回答的是「这次修改放在哪里」，没有回答「执行任务的进程能访问什么」。

原文把相关控制分成四类：

• 会话和 worktree 决定对话、文件改动属于哪个任务。
• 凭据包装器决定某个集成默认使用哪个账号。
• 操作系统身份及运行限制决定进程能访问哪些资源。
• 人工审核决定是否接受代理交回的结果。

它们各有用途，不能互相顶替。例如，GitHub token 的权限收得很窄，也挡不住代理读取同一进程可见的另一份凭据。某个包装器默认选择了指定账号，也不代表代理无法绕过它，直接按路径调用其他程序。

干净的 diff 只能帮助审查交付，无法证明执行期间没有读取额外资源。

所以，审批计划和审核 PR 都有价值，却不能代替进程权限限制。等 PR 交回来再拒绝合并，也撤销不了已经发生的秘密读取。

DeepSeek 的部署文档具体提醒了什么

dsh-superagent-prototype 的 README 将其描述为研究原型：处理获准的 GitHub 请求，也可选择接入 Feishu；每项工作使用独立会话和目录，完成后把结果返回原来的讨论线程。

另一半信息藏在部署方式里。原文引用的部署指南说明，已发布的预设使用 danger-full-access，工作进程运行在操作者的操作系统账号下。

这里的风险并不取决于目录是否整齐。代理继承了这个账号的访问能力，而账号包装器选择默认身份，并不能阻止它读取操作者的主目录，或者按路径调用程序。部署指南因此建议使用独立的操作系统账号。

这个结论有明确范围：它描述的是该原型文档中的预设，不能据此断言所有编程代理都采用同样配置。部署指南也不是独立安全审计，原文没有提供针对该原型的攻击测试结果。

独立账号同样只是起点。假如给它挂载了包含其他项目秘密的共享目录，隔离效果仍会削弱；出站网络如果不受限制，也需要单独检查。账号叫什么不重要，实际授予了哪些能力才重要。

第一个任务启动前，应该验证哪些事情

作者提出了一套预检流程，并明确说明：这是建议的审查程序，既不是他在 DeepSeek 原型上跑过的测试，也不是适用于所有环境的沙箱配方。

先记录真正执行工作进程的操作系统账号，以及它能看到的主目录和挂载路径。不要只登记代理用来回复消息的 GitHub 身份，两者可能处于不同的权限层次。

接着列出任务确实需要的凭据和网络目的地，再通过账号、挂载、凭据权限及出站网络控制，把无关项目、个人凭据和生产访问排除在外。关键是限制必须由运行环境执行，不能只写在提示词里。

然后，在只包含合成文件和合成 token 的一次性环境里，使用计划投入真实任务的同一套运行配置，分别尝试一次允许访问和一次禁止访问，记录实际结果。

声明禁止访问，与亲眼确认访问被拒绝，是两种证据。

预设改变后，还要比较变更前后的有效账号、挂载、凭据范围和出站规则。作者建议对脱敏后的权限清单做文本 diff；如果缩进有含义，就不要开启忽略空白。参与比较的只能是脱敏或合成文本，不能放入真实秘密或私有配置。

不过，文本差异只能指出配置哪里变了，不能证明策略正确生效。最后仍要检查补丁，以及代理实际运行过哪些检查。访问边界在执行之前就已产生作用，代码审查则负责验收结果。

我的判断

我认同作者把「改了什么」和「能碰到什么」拆开讨论。对程序员来说，worktree 是熟悉、可见、容易检查的东西，很容易让人把交付流程的整洁误认为执行环境的安全。

这套流程的实用之处，是要求检查落到实际运行账号上，并同时验证允许与拒绝两条路径。相比只审批计划，它能提供更直接的权限执行证据；相比只看配置 diff，它也更接近代理真正运行时的行为。

但它仍是一份部署检查思路。作者没有给出对照实验，也没有证明独立账号或某套配置足以完成隔离。文中提及的 Reddit 事故汇总来自作者整理，未经独立核实，不能拿条目数量推算风险；另一篇 DEV.to 文章属于厂商撰写的讨论，也不能当作该原型的验证材料。

原文也没有规定应该选容器、虚拟机还是其他运行方式。选择取决于任务所需能力。一个文档修改任务，和一个需要安装依赖、调用外部服务、访问客户数据的任务，所需边界并不相同。新增例外如果扩大了权限，应在启动前审查，而不是等漂亮的 PR 出现后再处理。

能拿来做什么

• 给前端或 Node 项目接入编程代理前，先登记执行账号、可见目录、可用凭据和网络目的地，把这份清单与 worktree 配置分别检查。
• 对只修改文档或局部代码的任务，按实际需要开放目录和凭据；遇到安装依赖、调用外部服务的需求，再明确审查需要增加的访问能力。
• 在一次性环境中放入合成文件和 token，验证任务所需访问能够成功，同时确认无关资源的访问确实被拒绝，并保留观察结果。
• 每次调整运行预设后，比较脱敏权限清单并复查实际限制；交付时继续看 diff 和检查记录，让运行前的权限验证与运行后的代码审查各自承担责任。