MCP 让 AI Agent 能够连接文件、浏览器、数据库、知识库和自动化工具，这也是它真正有价值的地方。但连接能力越强，权限问题越不能含糊。一个 MCP Server 配错权限，轻则让 AI 读到不该读的密钥和隐私文件，重则误发消息、改错数据、触发真实业务流程。
所以在讨论“装哪个 MCP Server”之前，更应该先问：AI 能访问哪里？能不能写？关键操作要不要人工确认？出错能不能追溯和回滚？这篇文章放在 AI智能体与自动化专题 和 AI编程工具专题 的交叉位置，适合准备把 Claude Code、Codex、n8n、Dify 或其他 Agent 客户端接进真实工作的用户。
先说结论：MCP 权限要按损失半径设计
MCP 权限不是越多越好，而是要按“出错后会造成多大损失”来设计。读取一份公开文档，损失半径很小；读取整个用户目录，可能会暴露密钥和私人资料；写生产数据库，损失半径就更大；自动给客户发邮件或群消息，则可能直接影响业务关系。
如果你刚开始接触 MCP，可以先看 MCP怎么用？把 Claude Code 和 Codex 接进真实工作流的入门路线。本文不重复讲概念，而是专门讲权限边界。
第一条：默认只读，写入必须有理由
很多 MCP Server 一开始就提供读写能力，但普通用户没必要马上打开写权限。文件、数据库、表格、知识库、自动化平台，都应该先问一句：只读能不能完成 80% 的任务？
例如让 AI 阅读项目代码、分析日志、整理旧文章、生成 SQL 草稿，大多只需要读权限。只有当你已经确认任务稳定、输出可检查、失败可回滚时，才考虑给写权限。写权限也不应该一次性放开到全部目录或全部表，而是从测试目录、临时表、草稿区开始。
第二条：文件系统只开放项目目录
文件系统 MCP 最常用，也最容易被低估。很多人为了方便，把整个用户目录开放给 AI，这会让桌面、下载、密钥、浏览器资料、私人文档都进入可读取范围。更稳的做法是只开放当前项目目录，再单独开放一个输出目录。
如果是 AI 编程场景，可以结合 AI编程上下文管理怎么做 的方法，让 AI 明确只读取相关代码、测试、配置样例和文档。不要让它为了“多了解一点”扫描无关目录。
第三条：浏览器 MCP 要区分测试环境和真实账号
浏览器类 MCP 很适合做页面检查、表单测试、截图验收和后台巡检。站长维护 WordPress、开发者检查前端、运营人员录入数据，都会用到它。
但浏览器里通常有登录态。AI 一旦能点击真实后台，就可能发布、删除、付款、群发或修改配置。建议把浏览器任务分成两类：测试环境可以让 AI 多操作；真实账号只允许检查、草稿、预览，涉及发布、删除、付款、群发的动作必须人工确认。
如果你要把浏览器能力接进 Agent 工作流，可以参考 MCP浏览器自动化怎么用。那篇偏使用场景，这里要补上的就是权限边界。
第四条：数据库先只读，再限制表，再限制语句
数据库 MCP 的价值很高，风险也高。让 AI 查数据、写报表、定位异常很方便，但让 AI 直接改生产数据就要非常谨慎。
建议顺序是：先用只读账号；再限制到特定数据库和特定表；再限制可执行语句；最后才考虑受控写入。即便需要写，也优先写临时表、任务表、草稿表，而不是直接改订单、客户、权限、财务等核心表。
另外，不要把数据库连接串直接写进提示词或草稿文档。密钥应该放在环境变量或专门的配置里，并且避免被 AI 复制到文章、README、日志或聊天记录中。
第五条：自动化工具必须有人工审批点
n8n、Zapier、飞书、Notion、邮件、表格这类自动化工具，一旦接入 MCP，就可能从“生成建议”变成“触发动作”。例如创建任务、发送通知、更新客户状态、把线索写入表格、调用接口。
这类场景最好按三层推进：
- 第一层：AI 只生成草稿，不触发外部动作；
- 第二层：AI 写入测试表或测试频道，人工检查结果；
- 第三层：AI 可以提交执行请求，但关键动作需要人工审批。
如果你正在做 n8n 和 MCP 的组合，可以对照 n8n MCP Server怎么用。真正上线前，记得把“自动执行”改成“先生成、再确认、再执行”。
第六条：为每个 Server 写一张权限卡片
不要只在脑子里记权限。每接一个 MCP Server，都建议写一张简短权限卡片，内容包括：
- Server 名称和用途；
- 可访问的目录、表、账号、工作区；
- 是否只读，是否允许写入；
- 是否能触发外部动作；
- 哪些动作必须人工确认；
- 日志在哪里看，如何回滚；
- 密钥放在哪里，是否会被 AI 读取。
这张卡片不用复杂，关键是让权限可见。以后你更换工具、排查问题、交接项目时，也能快速知道某个 Agent 到底能做什么。
第七条：把审计日志当成上线条件
只要 MCP Server 能写入、调用接口或触发自动化，就必须有审计日志。日志至少要能回答四个问题：谁触发的、触发了什么、输入是什么、结果是什么。
对个人项目来说，日志可以很简单：命令输出、自动化平台运行记录、表格变更记录、Git diff、发布后检查结果。重要的是不要只看“成功了”，还要能在出错时找到是哪一步造成的。
第八条：先做失败演练，再给真实权限
给 MCP 放开权限前，最好做一次失败演练。比如：
- 如果 AI 写错文件，怎么恢复？
- 如果自动化重复发送消息，在哪里停止？
- 如果数据库写入错误，有没有备份或回滚脚本？
- 如果浏览器点错按钮，是否有二次确认？
- 如果密钥泄露，能不能快速吊销和重建？
这一步看起来保守，但它能帮你发现权限设计里的空洞。AI Agent 接进真实工具后，安全不是靠“模型应该不会乱来”，而是靠系统边界兜底。
一份 MCP 权限设置清单
- 文件系统：只开放项目目录和输出目录，不开放整个用户目录。
- 浏览器：真实账号只做检查和草稿，关键动作人工确认。
- 数据库：先只读账号，再限制库表，再考虑受控写入。
- 自动化：先草稿、再测试环境、最后人工审批执行。
- 密钥：只放环境变量或安全配置，不写入提示词和文档。
- 日志：写入、调用接口、触发外部动作都要可追溯。
- 回滚：每个高风险动作上线前都要知道怎么恢复。
老达点评：MCP 真正成熟的标志，是敢少开权限
很多人刚接触 MCP，会兴奋于“AI 什么都能连”。但真正把它用到工作里以后，你会发现成熟的配置往往不是权限最多，而是权限最清楚。文件只读、数据库只查、自动化先草稿、关键动作人工确认，这些看起来不够酷，却能让 AI Agent 稳定进入日常流程。
如果你还在选择 MCP Server，可以先看 MCP服务器怎么选；如果你已经开始配置 Claude Code，则可以接着看 Claude Code MCP怎么配置。选型解决“接什么”，本文这份清单解决“接到什么程度”。把这两件事分开，MCP 才不只是好玩的插件，而是可交付的 AI Agent 基础设施。
