当 AI 应用通过 MCP（Model Context Protocol）连接数据库、代码仓库、工单系统和企业知识库时，多租户隔离就不再只是“给接口加一个 tenant_id”那么简单。模型会根据自然语言自主选择工具并组织参数，一次看似普通的提问，可能触发跨系统查询、写入甚至审批操作。因此，平台必须同时解决租户身份可信传递、资源边界隔离、工具级授权和全链路审计四个问题，避免越权调用与数据串租。🔐
一、先建立清晰的租户安全边界
多租户 MCP 平台通常包含 AI 应用、MCP Client、MCP Gateway、MCP Server，以及下游业务系统。推荐把网关作为统一安全入口：客户端不能绕过网关直接访问 MCP Server，服务端也不能仅凭模型生成的参数判断租户身份。
租户上下文应来自经过验证的登录凭证或服务身份，而不是提示词、工具参数或自定义请求头。网关完成令牌校验后，可形成内部可信上下文，包括 tenant_id、subject_id、client_id、roles、scopes、token_jti 和 trace_id。业务代码使用该上下文执行授权，不接受模型自行提交的 tenant_id 覆盖它。
核心原则：模型可以提出“访问哪个资源”的请求，但不能决定“自己属于哪个租户”，更不能自行扩大权限。
二、认证与租户识别必须分层处理
认证回答“调用者是谁”，租户识别回答“调用者当前代表哪个组织”，授权则回答“能否执行这项操作”。三者不能混为一谈。一个用户可能同时加入多个租户，因此令牌中只有用户标识并不足够，还应包含明确且经过授权服务器签发的租户声明。
对于远程 HTTP MCP Server，可采用基于 OAuth 2.1 的授权流程，并校验签发者、受众、有效期、权限范围及令牌状态。MCP 的授权规范还要求资源服务器验证令牌是否确实签发给自身，禁止把收到的访问令牌原样转发给下游服务，以降低令牌被误用的风险。相关要求可参考 MCP 授权指南 与 授权安全注意事项。
服务间调用应使用工作负载身份或受控的令牌交换，使下游令牌同时绑定目标服务、租户和必要权限。不要在所有 MCP Server 之间共享一个高权限密钥，也不要把用户访问令牌写入提示词、日志、缓存键或工具返回内容。🛡️
三、采用“工具、动作、资源”三级授权
仅判断用户能否连接某个 MCP Server，粒度通常过粗。更实用的授权模型应至少包含三个层次：
- 工具级：租户是否启用了该工具，例如是否允许连接代码仓库或客户数据库。
- 动作级：调用者能否执行 read、create、update、delete、approve、execute 等动作。
- 资源级：本次操作能否访问指定项目、文档、数据行、命名空间或仓库。
平台可以组合 RBAC 与 ABAC：RBAC 管理管理员、开发者、审计员等稳定角色；ABAC 根据 tenant_id、资源归属、数据级别、调用时间、环境和风险评分做动态判断。例如，“项目维护者可以读取本租户普通仓库，但生产环境删除操作必须由管理员审批”。
工具清单也应按租户和用户动态裁剪。未经授权的工具最好不要出现在模型可见的 tools/list 结果中；即便已经隐藏，服务端仍必须在 tools/call 阶段再次鉴权，因为工具列表过滤只能改善暴露面，不能替代强制访问控制。
四、数据层隔离不能依赖应用自觉
数据库访问应把租户过滤固化在数据访问层。可根据风险和规模选择共享库共享表、共享库独立 Schema，或独立数据库，但无论采用哪种方式，都要确保查询默认附带租户条件，并对更新、删除和批量导出执行同样检查。
共享表方案中，建议使用复合主键或唯一约束，将 tenant_id 纳入索引与关系约束；支持行级安全策略的数据库，可进一步在数据库层实施强制过滤。缓存、向量库、对象存储和消息队列同样需要租户命名空间，例如缓存键包含租户前缀、向量检索增加不可被模型覆盖的租户过滤条件、对象路径依据可信上下文生成。📦
还要警惕“先按全局条件检索，再由应用过滤”的实现方式。它不仅可能泄露结果，还可能通过总数、排序、错误信息和响应时间暴露其他租户的存在。正确做法是在最靠近数据源的位置先施加租户约束，再执行搜索、聚合或分页。
五、对高风险工具增加策略闸门
读取公开知识与执行生产变更不应使用相同策略。对于付款、删除、发布、发送邮件、执行脚本及修改权限等工具，应引入参数校验、额度限制、环境限制、二次确认或人工审批。
- 先验证调用者是否拥有工具和动作权限。
- 再确认目标资源属于当前租户。
- 校验参数是否满足允许列表、格式与数量限制。
- 根据风险等级决定直接执行、要求确认或进入审批。
- 执行后记录结果摘要、策略版本和资源标识。
工具描述本身也属于安全面。不要仅在描述中写“只能访问本租户数据”，因为提示文本不是强制控制。真正的租户约束必须由网关、策略引擎、MCP Server 和数据层共同执行，形成纵深防御。
六、审计、限流与故障处理要按租户设计
每次 MCP 调用应记录租户、主体、客户端、工具名、动作、资源标识、授权结果、策略版本、耗时和 trace_id。敏感参数应脱敏或存储摘要，访问令牌、密钥以及完整文件内容不应进入普通日志。审计记录还应具备防篡改和受控查询能力。🧾
配额与限流也要同时覆盖租户、用户和工具三个维度，避免单一租户耗尽连接池、模型额度或下游 API 配额。发生身份服务、策略引擎或租户配置中心故障时，高风险操作应默认拒绝；只读低风险功能是否降级放行，则应通过预先定义的策略决定，而不是临时绕过鉴权。
七、上线前重点验证这些攻击路径
- 篡改工具参数中的 tenant_id，确认服务端不会采用该值。
- 使用 A 租户令牌访问 B 租户资源标识，确认请求被拒绝且无信息泄露。
- 将令牌提交给错误的 MCP Server，验证受众校验是否生效。
- 测试批量查询、搜索、导出与分页接口是否存在漏加租户条件。
- 检查缓存、向量检索、异步任务和重试队列是否保留可信租户上下文。
- 验证普通用户不能通过提示注入调用管理员工具或扩大参数范围。
- 确认授权失败、审批拒绝和重复调用均能形成完整审计链路。
总结
AI MCP 工具调用的多租户安全，本质上是把传统身份与访问控制延伸到模型驱动的动态调用链中。可靠的方案应坚持租户身份不可由模型声明、令牌必须绑定目标资源、权限按最小范围授予、数据过滤靠近数据源、高风险操作设置策略闸门。只有当网关、MCP Server、策略引擎和存储系统都执行同一租户边界，平台才能在保持工具调用灵活性的同时，真正实现可验证、可审计、可持续治理的租户级授权。✅
