摘要
当 AI 编程助手只能补全当前代码时，风险通常局限在编辑器里；当它能搜索文件、执行命令、访问网络和修改远程服务时，权限边界就成为工程设计的一部分。你需要决定助手能读什么、能改什么、哪些命令可以运行，以及哪些操作必须经过人工确认。
把权限设计成可理解、可撤销、按任务逐步开放的边界，才能既保留效率，又避免把整个开发机、密钥或生产环境交给一个模糊的提示词控制。不同工具的权限名称和实现并不相同，实际配置要以所用产品当前文档为准。
一、背景与问题
"请不要删文件"只表达了意图，不会阻止文件系统操作；"不要访问密钥"也不能替代对密钥文件、环境变量和日志的实际保护。模型可能误解任务，扩展范围，或者通过脚本、管道和子进程执行超出预期的动作。
权限配置常见两个极端：每一步都要求确认，开发者最后习惯性点"允许"；或者为了顺畅一次打开全盘读写、任意命令和网络访问。前者让审批失去意义，后者让一次误操作的影响范围过大。
先按数据和副作用分类，再决定哪些操作由助手自动完成、哪些需要确认、哪些必须禁止。权限边界应由工具配置、操作系统账号、沙箱、凭据管理和 CI 等机制共同落实，而不是只写在项目说明里。
二、核心概念
1. 权限不是一个开关
| 能力 | 主要风险 | 控制思路 |
|---|---|---|
| 读取文件 | 读取密钥、个人资料、生产数据或其他项目 | 限定工作目录，敏感路径单独保护 |
| 编辑文件 | 覆盖用户改动、修改生成物或扩大改动范围 | 检查工作区，约束文件清单，审查 diff |
| 执行命令 | 删除、安装、提交、部署、启动后台进程 | 区分只读与有副作用命令，按目标确认 |
| 网络访问 | 上传代码、调用外部 API、下载未知脚本 | 限制目标与凭据，确认数据去向 |
| 使用密钥 | 访问云资源、数据库、代码仓库或生产服务 | 短期、最小权限、按环境隔离、可撤销 |
| 远程写操作 | 修改数据库、发布、合并、发送消息 | 预览影响、备份或回滚、人工授权 |
"读权限"也可能带来影响：机密被模型上下文读取后就可能出现在回答、日志或后续工具调用中。相反，一个本地文件编辑能力如果被严格限制在临时工作区，风险可以显著降低。
2. 三种决策：允许、询问、拒绝
- 允许：范围清楚、可逆、影响局部的常规动作，例如读取项目源码或运行已知的纯测试命令。
- 询问：目标、影响或可逆性不够明确的动作，例如新增依赖、访问网络、删除文件或运行迁移。
- 拒绝：违反任务边界或组织策略的动作，例如读取未授权密钥、把数据发送到未批准的服务、直接操作生产数据。
需要确认的提示应说明具体目标、命令、影响范围和回滚方式。若界面只显示"允许工具访问"，却不说明它将访问什么，先暂停并查明细节。
3. 软指令与强制控制
README、项目指令和提示词帮助助手理解约定，但仍属于对模型的说明。操作系统文件权限、容器隔离、网络策略、秘密管理、受保护分支和部署审批才是可强制执行的控制。对安全关键动作，至少让一个外部机制能独立阻止越权行为。
三、工作原理
为每个任务画出权限边界：
text
确定任务目录和数据分类
↓
列出所需读取、写入、命令和网络能力
↓
默认授予最小范围
↓
遇到新增副作用 → 展示目标、影响和回滚 → 人工决定
↓
任务结束撤销临时凭据、检查 diff 与运行痕迹权限应随任务而非模型能力决定。同一个助手在写文档时不需要数据库写权限；执行只读分析时不需要提交权限；本地测试也不应自动获得生产凭据。把开发、测试、预发布和生产凭据分开，即使误操作也能限制影响范围。
"人工确认"不能沦为重复点击。每次确认前都要看清将执行的动作；命令变化、参数变化、目标环境变化时，应重新评估，而不是沿用之前对相似命令的批准。
四、实战示例
1. 开始任务前列权限清单
text
任务：为本地订单模块增加参数校验测试。
允许：
- 读取当前仓库中的源码、测试和项目说明；
- 编辑已确认的订单模块和对应测试文件；
- 运行仓库已有的本地测试与静态检查命令。
需要先说明并等待确认：
- 安装或升级依赖；
- 访问网络、调用外部 API、启动会写入数据的服务；
- 修改任务清单以外的文件；
- 删除、移动文件或运行数据库迁移。
禁止：
- 读取 .env、凭据目录、个人浏览器配置和生产数据；
- 把代码、日志或数据发送到未批准的外部服务；
- 访问生产环境、提交、推送、部署或合并。
执行前检查 git status，保留所有已有修改。发现测试命令会改动共享服务或真实数据时先停止。把示例中的路径和命令换成项目真实约定。若使用的工具不支持按文件或命令精细控制，就通过单独工作区、低权限账号、容器和凭据隔离缩小影响面；不要假设不存在的配置项。
2. 审批前检查命令的实际影响
看到以下动作时，不要只看命令的名称：
text
git status / git diff → 通常是读取版本状态和差异
包管理器安装命令 → 可能写入依赖文件、锁文件和本机环境
数据库迁移命令 → 可能修改表结构或数据
git push / 发布命令 → 会影响远程仓库或运行环境
下载脚本后立即执行 → 同时引入外部代码和执行副作用确认命令来自哪里、使用哪些凭据、影响本机还是远程环境、能否预览或回滚。curl ... | shell 一类管道尤其要先审查下载内容与来源；不要只因为它出现在 README 或助手建议中就直接执行。
3. 管理密钥与敏感数据
- 将真实凭据存放在系统密钥库或组织批准的秘密管理器，不写进源代码、提示词、提交或截图；
- 为测试任务使用独立测试账号和测试数据，权限只开放所需资源；
- 优先使用短期令牌，结束任务后撤销或轮换；
- 日志发送给模型前做脱敏，同时保留排障所需的错误类型和控制流字段；
- 检查环境变量和命令历史，避免在输出中意外回显密钥。
如果怀疑凭据已经暴露，应按凭据管理流程立即撤销或轮换，再检查访问日志；单纯删除聊天记录或本地文件不能保证令牌失效。
4. 任务结束做权限与改动复核
结束前重新检查工作区和外部状态：
text
git status --short
git diff --stat
git diff --check
git diff确认改动只落在预期文件，没有密钥、调试产物或意外生成文件；核对是否创建了后台进程、下载了依赖、修改了数据库或触达远程服务。撤销本任务临时授权，清理临时测试凭据，但不要自动删除用户原有文件或配置。
五、常见问题与实践建议
1. 关闭所有确认后效率变高了
检查是否同时扩大了命令、路径和网络权限。把低风险重复操作精细授权，把不可逆或远程操作继续保留确认；速度提升不应依赖全局放开。
2. 提示词禁止读取密钥，但助手仍能访问
提示词不是访问控制。用文件权限、忽略规则、沙箱和凭据隔离阻断读取；并检查搜索工具、日志和子进程是否能间接获得同一内容。
3. 测试命令看起来只读，实际会写数据
先读测试配置、夹具和服务连接目标。使用独立测试库或容器，不让本地测试连接生产凭据；不确定副作用时先在隔离环境运行。
4. 每次审批都点允许
调整授权粒度，而不是把所有权限一次放开。按可信目录、明确命令和环境设置有限许可；高风险操作仍逐项确认。
5. 使用容器就认为完全安全
容器若挂载了整个磁盘、Docker Socket、SSH Agent 或宿主密钥，隔离边界会被削弱。审查挂载、网络、用户身份和能力配置；沙箱本身也需要定期验证。
六、进阶思考
可以按任务定义权限配置：读代码任务允许只读仓库，不开放网络；测试任务开放临时测试库，不注入生产令牌；发布任务由独立流水线和人工审批完成。这样把权限从"工具能做什么"转为"这次任务必须做什么"。
团队还可以记录审批理由和高风险动作的审计事件，定期检查误批准、越权尝试和凭据暴露。出现事故时能知道哪个身份访问了什么、影响了哪些资源，以及怎样撤销，不依赖会话摘要来重建。
结论
权限边界应具体到文件、命令、凭据、网络和远程副作用。先收集任务必需能力，再按最小权限开放；对安装、删除、迁移、推送和部署检查目标与回滚；对密钥采用隔离、短期授权与可撤销设计。把软指令与系统级控制结合起来，人工确认才有实际意义。
下一篇将把这些边界放进 Git 与 Pull Request 流程，逐步检查 AI 生成的工作区差异、暂存内容和最终提交。