区分连接认证、用户授权和资源权限，避免把工具连通误认为业务授权已经完成。
本文于 2026-09-12 补充整理，按 2026-05 专题归档。示例为方案设计，参数用于说明方法，不代表已上线项目或实测成果。
连接成功之后，授权才刚开始
企业接入 MCP 时，需要分开看三个主体：连接 MCP 服务的客户端、提出请求的员工，以及最终被访问的业务资源。客户端能连上服务器，并不意味着它可以代替任何员工查询任何工单。
MCP 2025-11-25 的授权规范描述传输层授权框架。应用仍需实现项目、记录和字段层面的业务权限。本文固定引用这个协议版本，不假设所有存量 SDK 已完整支持它。
画清身份传播链
员工会话
→ Java 应用校验身份与租户
→ MCP Client 使用面向目标服务的授权
→ MCP Server 校验调用上下文
→ 业务授权策略
→ 工单 API / 知识服务
工具参数中写着 userId=admin，不应改变调用者身份。用户可选“查询谁负责的工单”，但“以谁的权限执行”必须来自可信认证上下文。
异步任务还要保存发起人、授权范围和相关版本。任务延迟数小时后执行，原权限可能已经撤销；不能因为创建任务时通过了校验，就永久继承当时的权力。
不要原样透传所有令牌
面向 MCP 服务的令牌与面向下游工单系统的令牌，可能有不同受众和作用域。接收到一个 token 后不加区分地传给所有下游，会模糊谁向谁授权。
MCP 安全最佳实践专门讨论令牌透传等风险。具体可以使用受约束的服务身份、明确支持的令牌交换机制或下游自己的授权流程；选哪一种，需要匹配身份提供方和业务系统的能力。
若采用共享服务账号，下游只看到服务身份，那么用户级授权和审计责任会更多地落在 MCP Server 或中间策略层。这个代价必须写进架构，而不能假装下游已经自动识别真实用户。
将工具发现与工具执行分开治理
工具目录可以按身份过滤，但这只是减少误用机会。每次实际调用仍检查当前权限、资源归属和操作风险。缓存的工具列表、长连接会话和历史计划，都可能比授权状态活得更久。
工具 schema 或描述更新时，客户端应识别版本变化。对审批中的写操作，升级后的工具语义若不兼容，应重新生成提案或重新审批，不能把旧授权解释成新动作。
日志需要能解释谁做了什么
建议记录 taskId、actorId、serviceIdentity、toolName、resourceId、decision 和策略版本。日志不记录访问令牌原文。对敏感参数，保存脱敏摘要和受控引用。
“拒绝”日志同样重要：可以区分员工本来无权、会话过期、作用域不匹配和资源已删除。把这些问题统一报成网络异常，会诱发错误重试。
验收应覆盖权限变化
用两个租户、两个角色和一个撤权动作测试：正常查询成功；另一个租户资源不可见；只读角色不能创建；任务等待期间撤权后不能继续写；重连不会恢复已失效权限。
还要尝试向工具传入伪造的租户或用户字段。正确行为是拒绝非法字段或忽略其身份作用，并始终使用认证上下文。只有这一层成立，MCP 才能成为受控的集成入口。
