你交给编程 Agent 一件很小的事：修一个失败的测试。二十分钟后，它改写了三个无关文件，对着 shell 里找到的 DATABASE_URL 跑了数据库迁移，还强推到别人正在用的分支。提示词里没有一句要求它这么做。这台机器它能随便用，它就用了。
权限就是事先决定 Agent 可以碰什么。编程 Agent 的权限是一组规则：这次运行里，这个 Agent 能碰到哪些文件、命令、凭证和仓库，以及人必须在哪里介入。配对了，跑偏的 Agent 会安全地失败在你画好的盒子里。配错了，一次糟糕的运行就能碰到生产环境。
这篇文章按层讲权限模型，每一层都点出失败方式，最后给一份今天就能过一遍的清单。每一层都用 HiFox 写具体，因为 HiFox 的工作就是站在编程 Agent 上面，把这个范围收在一个地方。编程 Agent 你已经有了。HiFox 把它们收成一个团队，团队就得有规则：谁可以做什么。
Agent 的权限住在三层里
编程 Agent 的权限不是一个开关。它住在三个地方，任何一层有缺口，另外两层都会被拆掉。
- 运行时决定 Agent 能调用哪些工具：读文件、改文件、跑 shell、访问网络。执行工作的是 Claude Code、Codex、Gemini CLI，或你实际在用的那个 Agent。
- 机器决定这些工具够得着什么：哪些目录、哪些凭证、哪些环境变量、哪段网络。HiFox 里的电脑提供 Agent 需要的操作系统、文件、凭证、网络和工具，所以爆炸半径其实是这台机器。
- 任务决定意图的边界：这次运行限定在哪个仓库，Agent 可以改哪些状态，以及人在哪里验收结果。
有一条边界要说清楚：权限不是审批关卡。权限是 Agent 能够做什么。审批关卡是人在哪里做决定。两个都要。权限收得很紧但没有关卡，就没人看结果。有关卡但权限很松，等人看见的时候损害已经发生。编程 Agent 的审批关卡讲的是后一件事。
第一步：收紧运行时的工具
从 Agent 真正动手的地方开始。多数编程 Agent 自带一套权限：工具的允许名单和拒绝名单，再加上破坏性操作之前的询问。例如 Claude Code 可以允许或拒绝特定工具，跑 shell 之前会问。具体设置名每个运行时不一样，也经常改，看你这个 Agent 现在的文档，不要用去年抄来的片段。
安全的默认是：读从宽，写从紧。让 Agent 读仓库、跑测试、做类型检查、构建，都不必先问。文件修改和 shell 命令放在询问后面，或放进明确的允许名单。
失败方式有名字，而且赶工期时人人都会伸手去开：一键跳过全部询问。每个运行时都有一个关掉所有提示的旗标，有人看着的会话里它很方便。危险在于无人值守的运行也开着。一个从不用问的 Agent，计划一旦错了，会很开心地删掉它理解错的东西。你看着的时候再用自动接受。人离开就把这个开关关掉。
第二步：收紧机器和凭证
如果机器把什么都交给 Agent，运行时的工具名单就没有意义。Agent 要是能在你的日常电脑上跑 shell，它就能读到你登录身份够得着的每一把 SSH 密钥、每一个 .env、每一份凭证。失败是安静的：看起来都正常，直到 Agent 用了一把它本不该看见的生产密钥。
两步可以缩小爆炸半径。第一，让 Agent 跑在范围明确的地方，而不是放着真秘密的那台笔记本。HiFox 用一次性安装令牌注册电脑，令牌短时有效、只用一次。文档说得很直：不要把这个令牌放进可复用的镜像、脚本、任务或评论。电脑是容器、服务器还是一台备用机器都行，Agent 的触及范围是那一个环境，不是你的。你不在时还想让 Agent 继续干活，就把它们放到远程电脑上，而不是开着的笔记本。
第二，一次运行只给它需要的东西。一次运行的环境由明确配置拼出来：挂上的仓库、环境变量、秘密绑定和工作目录。Agent 需要比空间默认更窄的代码范围时，把仓库挂到这个 Agent 上，这样前端 Agent 不会检出计费服务。每次运行放在它自己的独立 worktree 里。这是「一次改坏只留在一份检出」和「两个 Agent 把同一棵工作树改坏」的差别。每条字段都按同一条规矩：只填产品要求的配置，不要把密码或令牌粘进无关字段或启动命令。
第三步：收紧任务，合并留给人
最后一层是意图。沙箱和凭证都对的 Agent，仍然可能做错误的工作：把自己的任务标成完成，把做了一半的改动推进共享分支，或认定一个 Pull Request 可以合并。
人和 Agent 的分工就放在这里。Agent 负责调研、执行、测试和汇报。人定方向、授予权限，并验收结果。需要团队判断的地方，自动化就停。Agent 可以开一个草稿 Pull Request，附上测试输出；它不应该批准这个 Pull Request，也不应该把它合并进受保护分支。托管方的分支保护，加上任务上的人工审阅，是守住这条线的两把锁。
在 HiFox 里，限制就在任务上。任务类型的工作流约束 Agent 能选哪些状态，所以 Agent 不能悄悄把工作推进一个人负责的「完成」或「已发布」。Agent 需要决定时，任务会停在等你审阅或等你回复。这类交接出现在主侧栏的「对话」里，桌面横幅和飞书 / Slack 提醒会送到该处理的人；指派、执行异常和评论仍会进收件箱。执行、阻塞、结果和审阅都回到这一条任务，而不是散在五个终端里。
自己拼的那套也会在这里撑不住。一个 Agent、一个仓库、一个很小心的工程师：整套权限模型可以记在脑子里。再加上第二个、第三个 Agent，更多仓库，还有一位同事，「这里每个 Agent 被允许做什么」就成了没人能凭记忆回答的问题。任务看板把这些规则变成可以一起查看的配置：谁派的活，这次运行的范围是什么，回来了什么证据，谁验收的。这就是编程 Agent 上面的那一层管理。你可以用 worktree、收紧的凭证和分支保护自己搭，也可以让现有的编程 Agent 走 HiFox，把权限、任务和审阅放在一个地方。
今天就能过一遍的权限清单
每一个允许碰真实仓库的 Agent，都过一遍：
- 运行时：读取和测试不必询问；编辑和 shell 要拦住；无人值守的运行关掉一键跳过。
- 机器：Agent 跑在范围明确的电脑上，不是你的日常电脑；安装令牌和访问令牌只用一次，绝不提交进仓库。
- 凭证：只有这次运行需要的环境变量和秘密绑定，不要粘进无关字段。
- 仓库范围：Agent 只挂它的工作需要的仓库，不是空间里的每一个仓库。
- 隔离：每次运行有自己的 worktree，一次改坏不会弄脏共享检出。
- 任务范围：Agent 可以改进行中的状态，不能把任务推进到人负责的已验收或已发布状态。
- 合并：分支保护，加上带着任务级证据的人工审阅，挡在 Agent 的 Pull Request 和主分支之间。
哪一行松了，在下一次运行之前收紧，不要等那次事故来教你它为什么重要。
常见问题
编程 Agent 的权限和审批关卡有什么区别？ 权限定义 Agent 在技术上能做什么：它够得着哪些文件、命令和凭证。审批关卡是人决定接不接受 Agent 所做的事。两个都要。权限再紧，仍然有人该签字的工作；如果 Agent 已经有权限造成损害，审批关卡也帮不上。
编程 Agent 可以合并它自己的 Pull Request 吗？ 默认不可以。让 Agent 开草稿 Pull Request 并附上验证输出，合并留给人或必需的审阅。理由就是人和 Agent 的分工：Agent 执行并汇报，人验收并发布。Agent 做了大部分工作、人在回路里的流程，这条同样成立。
把所有权限询问都关掉，安全吗？ 只有你看着的时候可以。自动接受适合有人盯着、能叫停错误步骤的会话。无人值守或过夜的运行，保留询问或允许名单，并把 Agent 放在范围明确的机器上，这样错误被关在里面。
HiFox
