MCP 远程服务器如何限制工具权限：allowlist、来源校验与审计留痕

把远程 MCP 服务器接进智能应用后，最容易出现的误区是“能发现的工具都可以调用”。更稳妥的做法是把发现、授权、调用和留痕拆开：先用 allowlist 限定工具，再校验 OAuth 令牌的来源与受众，最后让每次调用都能回到一条审计记录。

远程 MCP 的权限边界应以“允许调用什么工具、令牌发给谁、调用发生了什么”为准，而不是以服务器返回了多少工具为准。

先把 MCP 远程服务器上的资产分清楚

这里的资产不是一个抽象的“AI 能力”，而是三层具体对象：远程服务器暴露的工具清单、工具可以触达的数据或业务动作，以及调用凭据本身。比如一个服务器同时提供只读搜索和修改工单的工具，前者的风险是数据外泄，后者还多了业务状态被改变的风险。

因此，权限设计要回答三个问题：调用方能看到哪些工具，能否真正调用这些工具，调用时可以携带哪些资源范围。MCP Tools 规范明确把工具视为可被模型调用的能力，同时提醒客户端不要无条件信任工具注解；这也是把发现与授权拆开的依据。

为什么 tools/list 返回结果不等于授权

一次典型的远程调用会先执行 tools/list，客户端拿到工具名和输入 schema，再根据模型选择发起 tools/call。如果客户端把第一步返回的全部工具原样交给模型，服务器稍微增加一个写操作，风险面就会跟着扩大。

图中只保留了正文里的三个节点：tools/list 是发现入口，allowed_tools 是客户端的授权筛选，tools/call 才是产生实际动作的调用点。最小配置可以先只允许只读工具；需要写入外部系统时，另做一次人工确认或业务审批。

const tools = await client.listTools();
const allowedTools = tools.filter(tool => readOnlyAllowlist.has(tool.name));
const result = await client.callTool(allowedTools[0].name, input);

这段示例的重点不是某个 SDK 的固定写法，而是调用链的顺序：先发现，再筛选，最后调用。实际项目还应在服务端再次检查权限，不能把客户端的筛选当成唯一防线。

allowlist 应该怎样落到可复核的规则

只允许业务真正需要的工具

把工具按“只读查询、低风险写入、高风险写入”分组。默认 allowlist 只放入本次业务需要的只读工具，其他工具不因为 schema 看起来简单就自动开放。OpenAI 的 Remote MCP 参数支持按工具名指定 allowed_tools，也支持按只读提示筛选；但筛选结果仍应结合你信任的服务器和自身审批规则判断。

把输入字段也纳入边界

工具名称允许，不代表所有参数都允许。例如查询工具可以限制租户 ID、时间范围和返回数量；写入工具要限定目标项目、字段范围和操作者身份。服务端应拒绝越界参数，并把拒绝原因写入审计记录。

不要信任未经核验的工具注解

工具的只读标记、幂等标记或风险描述只能作为辅助信息。MCP Tools 规范要求客户端把工具注解视为不可信，除非它们来自已经建立信任关系的服务器。真正的权限判断仍应依赖服务器身份、策略版本和调用主体。

OAuth 来源校验要看 resource 而不只是 token

HTTP 传输下，MCP 授权规范要求围绕受保护资源和授权服务器建立流程。实际核验时，至少检查授权请求中的 resource、令牌的 audience，以及当前 MCP 服务器是否就是令牌的预期接收方。令牌存在但受众不匹配，不能继续调用。

这一步的原因很实际：一个发给服务器 A 的访问令牌，如果被转交给服务器 B，B 不应把“签名正确”误认为“可以使用”。MCP 规范还强调令牌受众绑定、HTTPS 通信、PKCE 和安全存储；日志里不要记录完整 access token，只记录哈希或末尾少量标识。

这条调用链把 resource 和 access_token 放在同一处核验，只有通过后才到 tools/call；成功或拒绝都写入 audit log。如果授权服务器不支持动态注册，也不能因此跳过受众校验，应采用规范允许的注册方式并保留配置依据。

审计记录怎样支持追责和回滚

一条可用记录至少包含：服务器标识、工具名、请求主体、时间、资源范围、策略版本、结果状态、拒绝原因和关联请求 ID。结果内容要按数据敏感度脱敏，尤其不要把密码、API key、个人信息或完整令牌写入日志。

对写操作，建议额外记录审批单号或人工确认结果，并保留调用前后的业务对象版本。这样出现误操作时，排查路径不是“模型好像做过什么”，而是可以从审计记录定位具体工具、主体和状态变化，再按业务系统提供的回滚能力恢复。

上线前的权限验证清单

• 用普通调用身份执行 tools/list，确认返回工具不会自动全部进入模型上下文。
• 调用不在 allowlist 的工具，确认服务端返回拒绝且没有副作用。
• 把发给其他资源的 access_token 送入当前服务器，确认受众校验失败。
• 用越界租户 ID、超长时间范围和写入参数做负面测试。
• 检查成功、拒绝、超时三类 audit log 是否都能关联请求主体和请求 ID。
• 模拟撤销凭据，确认后续 tools/call 不能继续使用旧权限。

常见问题

只在客户端配置 allowed_tools 够不够？

不够。客户端筛选可以减少模型看到的工具，但服务端仍需根据请求主体、令牌受众和参数范围再次授权。

只读工具是不是可以不记录日志？

不建议完全省略。只读调用也可能触及敏感数据，至少应保留主体、工具、资源范围和结果状态，内容按需要脱敏。

为什么令牌签名正确仍可能被拒绝？

签名只能说明令牌由某个授权方签发，还要确认它的 resource 或 audience 与当前 MCP 服务器匹配，并且没有过期或被撤销。

把权限边界留在服务器一侧

远程 MCP 接入的安全起点不是“让模型看见更多工具”，而是先建立一条能复核的权限链：tools/list 发现能力，allowed_tools 缩小范围，resource 与 access_token 完成来源和受众校验，tools/call 产生动作，audit log 保存结果。每一层都有明确的失败状态，后续才能做告警、撤权和回滚。