只要 MCP 开始接触真实系统，权限设计就不能再停留在“能跑就行”。一个好的默认策略，不是上来给 AI 完整写权限，而是优先建立只读路径：先让模型看得到、问得到、查得到，再决定哪些动作真的要开放写入、发布、删除或执行命令。这样做并不是拖慢效率，而是在最大化可用性的同时，把误操作成本压到最低。
为什么要把只读放在第一位
因为大多数工作流失败，并不是失败在“读不到”，而是失败在“写错了”。读取错误通常还能靠人工复核纠正，写入错误却可能直接改坏文章、删错文件、误发内容、污染数据库。尤其当你还在探索提示词、工具说明和工作边界时，只读模式能让你先验证模型是否真的理解系统，再逐步决定是否给更高权限。
只读优先不等于永远不能写
很多团队误解了只读策略，以为这会让 MCP 失去价值。正确做法其实是分阶段放权：第一阶段只开放读工具和元数据；第二阶段开放低风险写入，例如新建草稿、写临时目录、创建预览记录；第三阶段才考虑真正高风险的发布、覆盖、删除或执行命令。这样你不是在拒绝自动化，而是在给自动化建立一条可审查的升级路径。
设计权限时先分四类动作
- 纯读取：列出项目、读取文档、查询状态、获取配置、搜索日志。
- 低风险写入：新建草稿、写沙箱目录、生成预览、添加待审核记录。
- 中风险变更：编辑已有内容、更新配置、移动文件、触发外部任务。
- 高风险动作：发布、删除、覆盖、执行高权限命令、操作生产数据。
把动作先分类，你就能看出哪些能力应长期只读，哪些能力只在特定步骤、特定账号、特定环境下开放。
范围最小化要落到具体维度
官方安全最佳实践特别强调 scope minimization，也就是范围最小化。不要只在口头上说“限制权限”，而要落到具体维度：只能读某个站点、某个项目、某个目录、某个表、某类工单；只能写草稿而不能发布；只能创建而不能删除；只能在工作时间或特定环境中执行。范围越可枚举，误操作后的影响越容易控制，日志也越有意义。
推荐的只读优先策略模板
- 默认提供读取型工具，把写入型工具单独分组。
- 写入工具必须带清晰名称和风险提示，不与读取工具混淆。
- 高风险工具要求人工确认或二次指令，不允许模型一次直接越过。
- 生产环境与测试环境分离，先在测试侧验证结果。
- 账号分离：读取账号、草稿账号、发布账号不要混用。
为什么账号分离特别重要
很多事故并不是因为工具本身危险，而是所有工具共用一个“全能管理员账号”。当读取、草稿、发布、删除全挂在同一凭证上时，任何一个错误调用都可能被放大。更稳妥的方式是：即便工具名相同，也让不同环境和不同动作走不同账号。这样就算模型误选了工具，伤害面也会被权限本身限制住。
配合人工确认的最佳时机
人工确认不必加在每一步，否则体验会很差。更实用的做法是把确认留给高风险边界，例如正式发布、覆盖已有内容、批量改动、删除记录、发送外部通知。低风险读取和草稿生成则可以尽量自动化。这样既不把人完全排除在外，也不会让每个无害查询都打断流程。
哪些设计看似方便，其实应该避免
- 一个工具同时支持读、写、删，参数里再偷偷切模式。
- 默认全局管理员令牌，不区分项目和环境。
- 把“是否发布”交给模型自由决定，没有人工确认节点。
- 没有审计日志，事后无法知道是谁触发了什么动作。
- 为了少写一个工具，直接开放任意命令执行。
相关阅读
总结
只读优先的本质不是保守，而是先把“看懂系统”这件事做扎实，再逐步开放“改动系统”的权力。对个人和团队来说，这通常是把 MCP 从演示环境带到真实业务时，最值得优先建立的一条底线。
