MCP 多租户隔离：从请求上下文到缓存键的完整防串租设计

多租户 MCP Server 的风险不只在数据库查询。即使每条 SQL 都带了 tenant_id，缓存 key、后台任务、文件下载链接或日志查询只要遗漏一次租户上下文，就可能把一个团队的数据静默暴露给另一个团队。与其依赖每个开发者“记得加过滤条件”，不如让隔离成为执行路径的默认属性。

租户上下文只能来自可信身份层

工具参数里的 tenantId 应被视为用户输入，不能作为授权依据。Server 在完成客户端和用户身份验证后，从签名会话或内部授权服务中提取租户上下文，并把它封装为不可随意修改的 request context。工具执行器只接收这个 context，而不是让模型在参数里指定任意团队。

当管理员需要跨租户支持时，也不要简单跳过过滤。给支持人员单独的 scope，并要求显式选择目标租户、记录理由和审计事件。跨租户是特殊能力，不是普通查询的默认模式。

在数据访问层强制过滤

业务查询应该通过一个统一的数据访问入口，把租户条件自动注入。以下伪代码体现的是边界，而不是具体 ORM 写法：

const projects = projectRepository.forTenant(context.tenantId).findMany({ status: "active" });

不要在每个工具里手写 where: { tenantId }，因为新增查询很容易遗漏。对于高敏感表，可以在数据库层额外使用行级安全策略或受限视图，让应用层失误也不至于跨租户返回整表。是否采用哪种机制取决于数据库与运维能力，但“至少两层约束”是值得坚持的目标。

缓存、队列和对象存储最容易漏

缓存 key 必须包含租户和权限影响因素。report:latest 这种 key 在单租户测试里没有问题，在生产会立刻串数据。更安全的形式是 tenant:{id}:report:{queryHash}:role:{roleVersion}。如果结果还受项目成员关系影响，角色版本或权限版本也要进入 key，权限变更后再主动失效。

异步任务同样要持久化 tenantId，并在 worker 消费时重新加载授权约束。文件导出不要生成永久公共 URL；下载 token 应绑定租户、资源、过期时间和用户，下载服务再次检查上下文，而不是相信文件名中的 ID。

工具设计要避免越权组合

单个工具看起来安全，组合起来也可能越权。例如 list_projects 返回可猜测的全局 ID，get_project_metrics 只按 ID 查询，二者组合就能枚举其他租户。每个读取工具都必须独立授权，不能依赖“调用者理论上不可能拿到这个 ID”。

对于搜索、分页和聚合，确认过滤发生在排序、计数和游标生成之前。否则虽然列表项被过滤，totalCount、错误信息或游标行为仍可能泄露其他租户规模和活动信息。

把租户上下文传到每一个边界

一次工具调用往往会穿过 HTTP handler、权限服务、缓存层、消息队列、worker 和对象存储。任何一层把 context 丢掉，后续代码就会尝试使用默认租户或空条件。为请求上下文定义明确的数据结构，并在异步消息中携带不可变的 tenantId、主体 ID、traceId 和授权快照版本。worker 不应从消息中的任意字段重新推断租户，而应验证任务属于该上下文后再执行。

数据库连接池也值得单独检查。若使用会话级变量、行级安全或临时表，连接归还前必须清理状态，否则下一个租户可能继承前一个会话的权限设置。缓存清除任务、全文索引和数据导出这类后台工作同样需要租户测试，因为它们常常绕过正常的 HTTP 中间件。

用反向测试证明隔离存在

测试不应只验证 A 团队能读到 A 数据，还要专门验证 B 团队拿到 A 的资源 ID、缓存 key、任务 ID 和下载链接后仍然失败。建立一组固定的跨租户攻击回归用例：修改工具参数中的 tenantId、重放过期任务、切换账号后复用游标、命中同一缓存、尝试下载旧链接。

上线后监控被拒绝的跨租户请求、无租户上下文的调用和缓存 key 格式异常。隔离缺陷往往不是一次大事故，而是某次新工具、性能优化或迁移时悄悄引入的一条绕路。把这些路径持续纳入回归和审计，MCP 才能安全地成为多租户产品的能力层。

延伸阅读

• MCP 协议深度解析
• AI Agent 的核心架构
• Prompt Injection 防御