MCP 的权限与审计设计

MCP工具的访问权由谁决定？

访问权应由服务端依据可信主体、工具动作和业务对象决定。客户端传来的工具名称、商城编号或自然语言说明不能证明用户有权处理该对象。把后台接口包装成工具后，原来的账号类型、权限项和数据范围仍需核验；包装层还要约束模型能够选择的参数和返回字段。

MCP 接入基于源码定制（¥900 / 人天），需求确认后给固定总价。协议服务、授权衔接、工具目录、参数预览与专项审计需要定制工程。已有权限声明可作为审查依据，但不能替代新的接入测试，也不意味着现有管理会话可以直接发给任意模型客户端。

MCP官方授权规范说明HTTP传输的授权流程与令牌验证责任。本文核对版本为2026-07-28，查阅日期2026-10-03。协议授权解决访问受保护服务的问题；商城对象归属、字段可见性和交易动作仍需业务授权检查，二者都通过才可执行。

为什么一个管理员账号不适合覆盖所有工具？

多个使用者共用管理员身份，会把实际责任和访问范围混在一起。客服查订单、运营审商品、财务看汇总、实施人员排查配置，目的并不相同。工具服务如果只记下模型会话而丢失真实业务主体，就无法回答是谁请求、凭什么允许、处理了哪个范围以及离职后怎样撤权。

先画出客户端、授权服务、工具服务和商城业务服务的身份传递关系。明确哪个环节能够验证用户、哪个环节持有服务凭据、哪个环节做对象级判断；凭据应留在受控服务端，日志和模型上下文不能出现真实秘密。跨系统身份映射要能够撤销，不能只记录首次绑定成功。

单体版存在账号类型声明、权限目录和业务审计声明；检查授权需同时核对请求方法、主体权限与业务数据范围。 对一个工具逐项检查：业务主体是否来自可信会话、是否具有对应权限、目标对象是否在允许范围。即便列表被过滤，详情、附件、汇总和批量操作仍需要独立检查；用户猜中另一个对象编号也不应获得结果。

工具应该怎样拆分才能限制输入？

按具体业务动作拆分，例如受限订单查询与取消建议应是不同能力。查询工具限制筛选项、结果字段和分页；写入工具只接受业务允许的动作与结构化参数。不提供接受任意接口地址、SQL或文件路径的万能工具，避免一次调用越过原本分开的业务边界。

工具说明应标明输入含义、允许范围、结果新鲜度和失败含义。输入仍由服务端校验，说明里写着“只读”不会自动让执行安全。来自商品文案、附件或网页的内容只能作为数据，不能改变工具权限；验证过程中要把诱导跨范围读取、隐藏写入意图等样本放进去。

工具设计项	服务端检查	验收反例
身份与范围	从可信主体确定商城及对象归属	改传另一商城编号仍被拒绝
只读查询	字段白名单、分页与结果上限	任意字段或无界导出无法执行
写入建议	动作、对象状态和参数预览	过期预览无法改变对象
外部资源	允许地址与读取授权	附件地址不能绕过访问判断
审计记录	主体、操作标识、授权及回执	失败和拒绝同样留下可查证据

这是工具接口评审表，不是现有工具实现。每行的反例需要在隔离数据与允许账号下执行，结果保留输入范围、服务版本、状态变化与拒绝原因。开发环境样本通过后，还要核对正式身份、网关、缓存和外部服务配置是否一致。

写入工具怎样取得明确确认？

执行前形成可读预览，显示对象、动作、数量或金额以及受影响的业务范围。确认必须绑定这次预览中的参数与对象版本，并有失效条件；“以后都同意”不适合高影响交易动作。确认后再次检查权限和状态，不能假设用户仍在线、身份仍有效或对象仍未改变。

执行使用能够追踪的操作标识，保存预览、确认与实际回执的关联。若外部调用超时，先查询既有操作结果，再决定重试或人工处理。模型重复调用相同动作时，应按业务设计避免第二次产生影响；要验证的是结果状态，不是对话中出现“完成”两个字。

取消、发货、退款等动作还可能依赖支付、仓储或物流回执。工具不能将“已受理”表达成“业务完成”，也不能跳过原有状态机。返回结果应把已确认事实、等待外部结果与需人工处理分开，让使用者知道能否继续处理下一步。

审计该记什么，又不该记录什么？

建议记录请求时间、业务主体、客户端标识、工具版本、对象范围、参数摘要、授权判断、预览确认、操作标识与最终结果。摘要应足以复盘但减少敏感正文；令牌、密码、支付秘密和完整私人附件不进入普通日志。日志本身也需要权限、保留策略与导出审查。

单体版具有管理会话列表、详情和撤销入口；访问受账号类型与相应权限检查约束。 该入口证明既有会话有受控管理流程，但新增MCP授权不应被假设自动随它撤销。实施方案需要定义会话撤销、工具授权过期、账号停用和外部令牌撤销之间的关系，并分别验证；否则一个入口登出可能仍留下其他有效授权。

对一次问题调查，用操作标识关联客户端请求、工具判断、商城业务处理和外部回执。若日志只能看到模型说过什么，而看不到授权和状态结果，就无法据此判定业务是否执行。业务数据应通过有权访问的系统核对，不能为了调查把所有用户对话导出给无关人员。

如何验证越权、撤权与执行失败？

准备不同角色、不同商城、已撤销账号和已变化对象的测试资料，分别验证列表、详情、附件及动作。工具授权有效但业务权限不足应拒绝；业务身份有效但工具授权撤销也应拒绝。不能只测双方均允许的正常请求，这会遗漏两层授权衔接中的缺口。

故障样本包含授权服务不可用、工具超时、业务结果未知、重复确认、外部回执延迟和日志写入失败。每项记录业务对象是否变化、用户看到什么、下一步由谁接管。降级方案可以关闭工具入口并回到常规后台处理，但仍需保证已发出的业务动作得到查询和收尾。

上线之后，新增工具、字段、角色与模型客户端都是权限变化，必须重新评审受影响路径。不要把初次验收当成永久授权证明。对接团队应交付工具清单、权限矩阵、拒绝样本、审计字段、撤权流程和维护人，使接手者能够重复执行这些检查。

回到AI与商城专题确定任务风险等级，使用对接需求模板填写身份和回执责任，再与系统集成服务讨论适配范围。协议版本、外部客户端、账号与费用均由项目确认，