MCP Server 在本地跑通之后，团队一用会坏在哪里？

开发者把 MCP Server 接到桌面客户端，列出几个工具，让 Agent 读仓库、搜 issue、起草修复。跑通了。Demo 之所以有说服力，是因为关键条件都在本地：一个用户、一把 token、一个文件系统、一台机器，也没有别人等结果。

然后团队想把这个 Server 放进共享助手。十个人接进来，每个人的仓库权限不同。Server 还拿着同一把 token；列文件的工具还看得见宿主机的 home 目录；一个慢请求还能堵住整个队列。本地成功没有预测这些，因为本地根本没有共享状态可坏。

这篇讲的是 Server 接上之后的检查。第三方 MCP Server 准入决定要不要接；这篇决定多人依赖时，它是否安全、可运行。

本地能跑，掩盖了共享状态的问题

本地 MCP 通常有四个简化假设：

• 一个身份。 Server 用开发者的 token 跑，所有工具调用权限相同。
• 一个数据范围。 文件根目录、仓库或数据库都是开发者自己的。
• 一次一个请求。 没有队列、并发限制，也没有吵闹邻居。
• 没有持久审计。 对话记录对一个人够用，对团队和事故复盘不够。

团队接入会同时拆掉这四个假设。Server 必须回答：代表谁、访问哪份数据、以什么速率、留下什么记录、故障时隔离到什么程度？ 回答不了的 Server 仍然是本地工具，哪怕它已经能通过 HTTP 访问。

团队接入后，四件事变了

本地假设	团队要求	跳过后的故障
共用一把 token	每用户或每服务身份，带范围授权	所有人都以 token 主人身份行动；撤销只能一刀切
一个文件根	每次调用检查租户与资源范围	一个路径或查询返回了别的团队数据
一次一个请求	限流、排队、超时与背压	一个慢工具堵住所有用户
只有对话记录	结构化审计：用户、工具、参数、结果、审批	出事后无法归因

协议可以携带工具定义与调用，但不会自动提供你的授权模型、租户模型或审计策略。这些是应用的责任，也是“本地跑通”最容易漏掉的地方。

案例一：共用一把 GitHub Token

团队接了一个 GitHub MCP Server，用的是搭建者自己的 personal access token。这把 token 能读三个私有仓库，也能写 issue。

Demo 正常。放进共享助手后，每个用户都拥有了这三个仓库，包括两个他们本不该看到的。有人离职时，团队没法只撤销他的权限；要么轮换 token 让所有人断掉，要么继续共用。

修复不是改 Prompt，而是换身份：

• 每个用户授权自己的 GitHub 身份，或 Server 使用带明确仓库白名单的服务身份；
• Server 把已认证用户映射到授权范围，每次工具调用检查仓库是否在范围内；
• 工具结果记录使用了哪个身份；
• 撤销只移除一个人的授权，不影响其他人。

如果 Server 不支持每用户授权，团队仍可以让它单用户或只读运行；但不要用某个人的凭据把它当多用户服务共享。

反例：文件工具读到了另一个租户

一个文件搜索 MCP Server 暴露 search_files 工具，参数里有 root。本地使用时，root 是开发者自己的项目目录；共享服务里，root 由调用方传入。

用户问自己工作区里的文件。模型传了一个带 ../ 的路径，Server 解析到了预期根目录之外，另一个租户的文件出现在结果里。工具描述看起来毫无危险，它只是“信任了路径”。

抓住这个问题只需要一个小测试：

1. 建两个租户工作区，各放一个已知的 canary 文件。
2. 以租户 A 身份认证。
3. 让 Server 搜索租户 B 的 canary 路径，包括编码和路径穿越变体。
4. 记录 canary 是否出现在结果、报错或引用里。

通过条件不是“模型拒绝了”，而是“Server 在读取文件之前就拒绝了”。模型层面的拒绝是第二层，不是授权边界。

团队上线前的检查表

在团队依赖 Server 之前，逐项填这张表。它要短到每个 Server 都能填，又要具体到另一位复核者能验证。

检查	问题	证据
身份	每次调用用谁的凭据？	认证流程、token 范围、用户到授权的映射
工具白名单	哪些工具对哪些用户开放？	Server 配置与助手策略
数据范围	这次调用能碰哪个租户、仓库或记录？	代码里的范围检查与一次拒绝测试
限流与并发	到达上限时发生什么？	带队列与超时值的负载测试
故障隔离	一个慢工具会不会堵住其他工具？	每工具超时与熔断测试
审计	能否还原谁调了什么、结果如何？	一条脱敏后的真实 trace
版本固定	正在跑哪个 Server 版本与工具 schema？	lockfile 或镜像 digest
停用开关	能否只停一个工具/一个 Server 而不整体重部署？	一次演练过的停用动作

这不是安全认证，而是发布门。任何一行未知，Server 就不适合共享使用，哪怕所有本地测试都过了。

限流与故障隔离

本地 Server 没有队列，共享 Server 有。没有限制时，一个不断重试慢搜索的 Agent 可以吃掉所有人的容量。

至少设两层限制：

• 每用户： 每分钟请求数和并发调用，防止一个人饿死团队。
• 每工具： 并发与超时，因为文件搜索和付款调用不该共享同一份预算。

然后在限制处测试行为。Server 应返回清楚的“稍后再试”或“已排队”，而不是挂到客户端超时。Agent 应看到可路由的类型化错误，而不是一个引诱它重试的通用失败。

故障隔离是下一层。一个 MCP Server 慢，助手仍应回答不需要它的请求。每 Server 熔断、每工具超时、备用路径，都比“一个文件调用导致全局不可用”后再排查便宜。

审计，但不要记录秘密

一次 MCP 工具调用的审计记录应回答：

• 谁发的请求（用户或服务身份）；
• 适用哪个租户与资源范围；
• 跑了哪个工具、哪个版本；
• 参数哈希或脱敏摘要；
• 结果状态与耗时；
• 审批 ID 或策略决定。

它不应保存 token、完整文件内容或不受限的个人数据。审计是为了归因与重放，不是为了再造一份数据副本。

一个实用测试：拿一条真实调用，只看记录，能否回答“谁做的、碰了哪份数据、改了什么”。如果必须翻模型对话才能回答，审计还不够结构化，不适合团队。

不适用边界

这份检查适合共享助手、内部工具网关和多租户 Agent 平台，前提是 MCP 工具会被一个以上用户使用。它不能替代安全评审、渗透测试或供应商自己的威胁模型，也不足以支持受监管数据、支付发起或生产写入；这些还需要单独的审批与恢复设计。如果 Server 无法执行每用户授权和租户范围检查，就让它保持本地或只读。本地能跑是好起点，不是团队可以依赖的证据。