MCP 让 AI 更容易接入浏览器、文件、设计稿、数据库和代码托管平台。AI 不再只能回答“应该怎么做”，还可以进入工作现场执行一部分动作。

但工具接入之后，新的问题马上出现：到底应该让 Agent 做到哪一步？它能读什么、能写什么、哪些操作需要审批、出了问题怎么回滚？

MCP 解决的是工具连接问题，权限边界解决的是连接以后如何不失控。

从“能不能”转向“该不该”

当 AI 只能聊天时，主要风险是说错。它能调用工具以后，风险变成做错：

• 读取敏感日志
• 修改仓库文件
• 创建或关闭 issue
• 改 CI 配置
• 写外部系统
• 触发部署或数据变更

这些能力都可能有价值，但不能混在一个权限层级中。一个工程化 Agent 不应该默认拥有所有工具权限，而应该按任务风险授予最小能力。

一套实用的能力分层

我会把 Agent 能力分成下面几层：

read-only：只能读代码、文档和日志
suggest：可以生成方案、评论或 patch，但不能直接写入
workspace-write：可以修改隔离工作区文件
test-runner：可以运行测试、构建和 lint
external-read：可以读取外部系统信息
external-write：可以写 issue、评论或任务状态，需要确认
production：部署、迁移和生产数据操作，默认禁止

分层的意义不只是安全。它还让人类更容易理解 Agent 当前被允许做什么，出了问题以后也更容易追踪责任。

不同任务应该给不同权限

做代码 review

通常只需要读取代码、diff 和测试结果，并输出审查意见。不需要修改主分支、创建 release 或访问生产数据。

修复一个工作区 bug

可以允许读取相关代码、修改工作区和运行测试。涉及推送远程分支、修改部署配置或删除迁移文件时，应单独确认。

查询业务数据

优先提供脱敏、只读的数据接口。不要因为 Agent 能连接数据库，就直接给它任意 SQL 和生产写权限。

发布和部署

可以让 Agent 生成部署步骤、检查配置和分析日志，但真正的生产执行应有明确审批、审计和回滚方案。

默认策略可以更保守

一个小团队也可以先使用这样的默认规则：

默认允许：

- 读代码、文档和测试结果
- 生成建议和 patch
- 在隔离工作区运行低风险验证

需要确认：

- 修改多个模块
- 新增依赖
- 修改配置
- 写外部系统
- 运行长时间或高资源命令

默认禁止：

- 操作生产数据库
- 删除历史迁移
- 推送主分支
- 触发生产部署
- 使用未说明的凭证

这不是永远不变的规则，而是一个安全起点。随着任务类型和风险被验证，再逐步开放更具体的能力。

权限设计还要考虑审计和回滚

只写“需要审批”还不够。审批应该知道：Agent 要执行什么、影响哪些资源、为什么需要这项权限，以及失败后如何恢复。

工具调用最好能留下最少但足够的记录：调用者、时间、工具、参数摘要、结果和审批人。敏感内容不必全部写入日志，但要能追踪一次高风险动作的来源。

对于文件修改，隔离工作区和可查看 diff 是基础能力。对于外部写操作，应优先支持预览、确认、执行和结果回查。对于数据库和部署，更要提前设计回滚路径，不能把“执行成功”当作唯一状态。

Agent 越强，边界越要清楚

权限不是为了让 AI 少做事，而是为了让它能在合理范围内放心做事。读权限和写权限分开，工作区和外部系统分开，建议和执行分开，能把很多模糊风险变成可管理的流程。

真正工程化的 Agent，不是连接工具最多的 Agent，而是每次只获得完成当前任务所需能力的 Agent。

用一次记账 App 任务设计权限

假设任务是：修复最近 7 天统计查询，并补测试。这个任务不需要所有工具权限，可以按阶段分配：

阶段 1：分析

- 允许读取 parser、stats service、相关测试和 CI 日志
- 禁止修改文件
- 禁止访问外部系统

阶段 2：实现

- 允许修改隔离工作区
- 允许运行后端单元测试
- 禁止推送分支
- 禁止修改生产配置

阶段 3：提交

- 生成 diff 和 PR 描述
- 允许创建草稿 PR
- 创建正式 PR、写外部评论前需要确认

这样做的好处是：权限跟着任务阶段变化，而不是一开始就给 Agent 一个“全能工作区”。如果分析阶段就允许写文件，错误理解会直接变成代码改动；如果测试阶段就允许外部写入，失败修复可能扩大成对远程系统的误操作。

把工具权限写成可检查的策略

不要只在团队口头上说“生产环境谨慎一点”。可以在项目规则里写成明确表格：

操作	默认权限	需要确认
读取源代码和文档	允许	否
修改隔离工作区	允许	跨模块修改时
运行单元测试	允许	长时间命令时
新增依赖	禁止	需要解释版本和影响
创建草稿 PR	允许	否
写 issue 或评论	禁止	是
推送主分支	禁止	不开放
生产数据库写入	禁止	默认不开放

权限规则要能被执行环境真正落实。只写在文档里、工具层却没有拦截，仍然只是愿望。

审批要看动作，不要只看工具名称

“调用 GitHub 工具”这个描述太粗。读一个 issue、评论一个 issue、关闭一个 issue，风险完全不同；“调用数据库工具”也不代表所有 SQL 都一样。

审批前至少要显示：目标资源、动作类型、参数摘要、影响范围、是否可回滚和执行后的验证方式。

如果 Agent 请求“修改配置”，审批人应该知道它要改哪一个文件、哪一个环境变量，以及失败后如何恢复，而不是只看到一个模糊的工具名。

先做最小权限，再根据记录开放

实际落地时，我会先给 Agent 只读和隔离工作区权限，观察它需要哪些额外能力，再逐项开放。每增加一个权限，都要回答三个问题：

1. 不增加它，当前任务是否真的无法完成？
2. 这个权限的最小资源范围是什么？
3. 出错后能否审计、撤销或回滚？

这套方法比先把所有 MCP Server 接上，再靠人盯着 Agent 小心一点，更容易形成稳定流程。

MCP 解决的是 Agent 怎么接上工具，权限边界解决的是 Agent 接上工具以后，怎样不会把真实系统带偏。