MCP工具权限矩阵怎么设计：先把可读、可写和高风险动作分开

Written by

MCP让模型接入工具变得顺手，但顺手也意味着边界更容易被忽略。很多团队一开始只关心“这个工具能不能调通”，等进入生产环境后才发现，更难的问题是“谁能调、能调到什么程度、出了问题怎么追”。

如果把所有工具都当成同一类能力，AI Agent很快会从“辅助查询”变成“可以对业务系统做动作的自动化入口”。这时只靠提示词约束不够，应该在AI中转站或网关层建立工具权限矩阵。

第一层：可读和可写必须分开

最基础的分级是可读工具和可写工具。

可读工具包括知识库查询、订单状态查询、文档检索、日志摘要等。可写工具包括创建工单、修改配置、发送邮件、更新客户资料、触发部署等。两者风险完全不同，不应该共用同一套授权。

一个稳妥的做法是：默认只开放可读工具，可写工具需要单独启用，并且绑定调用来源、用户角色和环境标签。

可写工具里还要继续拆高风险动作。例如删除数据、批量修改、对外发送、退款、权限变更、生产环境发布，这些动作即使技术上可以自动化，也不应该和普通写入放在一起。

高风险动作至少要有：

AI中转站的价值就在这里：它可以在模型和工具之间加一层统一策略，而不是让每个业务应用各写一套半成品权限逻辑。

很多事故不是因为工具危险，而是因为工具打到了错误环境。测试环境可以宽一些，生产环境必须窄一些；内部演示可以松一些，面向外部用户必须严一些。

权限矩阵里建议显式加入：

这样网关能在执行前判断：这个Agent现在是否有资格调用生产工具。

权限不只是“能不能调用某工具”，还包括“能用哪些参数调用”。例如一个查询工具允许查自己的团队数据，不代表允许查全公司数据；允许创建普通工单，不代表允许创建最高优先级工单。

因此工具参数最好做结构化校验：字段白名单、枚举限制、长度限制、敏感字段过滤、资源归属校验。模型输出再合理，也不能绕过这些规则。

如果每个Agent自己处理权限，后续会非常难维护。有人把规则写在提示词里，有人写在业务代码里，有人只在前端隐藏按钮，风险很快变得不可见。

像 https://top-api.cc 这样的统一入口更适合作为收口层：把模型调用、工具权限、预算、日志和回退策略放在一起管理。这样团队不是给每个工具单独补安全补丁，而是在入口处建立一致的治理规则。

MCP工具权限矩阵不需要一开始就复杂，但必须从第一天区分可读、可写和高风险动作。工具越强，越要把授权、参数和环境边界前置。否则AI Agent看起来更聪明，系统实际却更难控。