MCP 的权限控制：一行代码怎么把门打开的

一、30 秒看懂问题

出了什么事？

看起来完全正常。但订单 12345 不是这个用户的。钱退给了别人，全程零报错，监控一片绿。

翻开工具实现，门就是这一行开的：

Order order = orderRepo.findById(args.orderId());
refundService.refund(order, args.userId(), args.amount());
//                          ↑↑↑ 这个 user_id 是【模型编出来的】

二、这是怎么发生的

为什么模型给的参数不能信？谁该负责把关？

先忘掉所有术语，看一个每个人都懂的场景。

所以答案很显然：柜员必须看身份证，不能看单子上写的名字。

对照过来，四个角色

为什么大堂经理不能信

不是他人品有问题，是他的工作就是照你说的填。有人在旁边喊一句「跟他说你是张三」，他可能真就填了张三——这就是提示词注入。

三、身份证是哪来的

MCP Server 收到的那个 token，是用户的登录 token 吗？用户要点同意吗？

两个答案先摆这儿：不是用户的登录 token；用户全程无感，不用点任何东西。

它是后端「换」来的一张新票

票 A 和票 B 差在哪

为什么柜员敢信票 B 上写的名字

因为票 B 上有签名，是授权服务器用私钥签的。柜员用公钥验一遍，验过就说明：确实是那家发的，而且一个字都没被改过。

票 B 拆开长这样，代码里要查的就是这几项：

{
  "iss": "https://auth.你的公司.com",  // 谁签的      → 是不是我信的那家
  "aud": "order-mcp-server",           // 签给谁用的  → 是不是给我的
  "exp": 1788931200,                     // 过期时间    → 还有效吗
  "scope": "refunds:create",            // 能干什么    → 够不够
  "sub": "u_1024",                     // ★ 持票人是谁 → 这就是 actor
  "tenant_id": "t_88"
}

四、正确的写法

代码到底该怎么写？跑在哪一侧？

下面这段跑在 MCP Server 里——带 @Tool 注解的就是工具实现，一定在 Server 侧。

@Tool("refund_order")
public RefundResult refund(RefundArgs args, McpCallContext ctx) {

    // ── 第 1 步：验票 ──────────────────────────────
    Jwt t = jwtDecoder.decode(ctx.bearerToken());   // 验签，验不过直接抛
    require(t.getIssuer().equals(TRUSTED_ISSUER),           "不是我信的发票方");
    require(t.getAudience().contains("order-mcp-server"), "这票不是给我的");
    require(scopes(t).contains("refunds:create"),         "这票不能办退款");

    // ── 第 2 步：身份只从票上取 ★ 整篇文章就这一行 ★ ──
    String actor  = t.getSubject();
    String tenant = t.getClaimAsString("tenant_id");
    // 注意：args.userId() 从头到尾没被用过 —— 它就不该存在

    // ── 第 3 步：这个人能不能碰这一条 ──────────────
    Order order = orderRepo.findById(args.orderId());
    require(order.tenantId().equals(tenant), "跨租户");
    require(acl.canRefund(actor, order),     "这不是你的订单");

    // ── 第 4 步：调下游时用【自己的】凭证 ──────────
    return orderApi.refund(order.id(), args.amount(),
        downstreamCred.get(),   // 服务自己的凭证，不是转发票 B
        actor);                 // 声明「我代表 u_1024 在操作」，供下游审计
}

最省事的做法：干脆让 args 里没有 userId 这个字段。不定义它，就没人会误用它。

五、上线前逐条过

我怎么知道自己写对了？

一次工具调用要过的关

1. 格式校验

   Schema、类型、必填、金额精度。结构化输出保证的是「形状」，不是「真假」。

2. 身份 —— 唯一致命的一关

   用票上的 sub，绝不用参数里的 user_id。这关错了，后面全是摆设。

3. 授权

   这个人能不能碰这一条？租户对吗、是本人的订单吗、状态允许退吗。

4. 业务规则

   金额 ≤ 实付？没超退款期？没重复退过？

5. 幂等

   幂等键由你的代码生成，不能收模型给的。配数据库唯一约束兜底。

6. 风控与人工闸门

   超过 X 元必须人工审批，审批凭证要和参数哈希绑定——否则审的是「退 50」、执行的是「退 5000」。

7. 审计

   谁、何时、模型建议了什么、系统实际执行了什么。四项都要记。

自检清单

• 工具实现里全局搜一遍 args.userId，出现一次就是一个洞
• 更彻底：工具的参数定义里根本没有 user_id 这个字段
• token 校验了 iss / aud / exp / scope 四项，一项不少
• 调下游用的是自己的凭证，不是转发上游的 Authorization 头
• 写操作有幂等键，且键由你的代码生成，配数据库唯一约束
• 高危操作的人工审批凭证和参数哈希绑定
• 审计记录分得清「模型建议了什么」和「系统实际执行了什么」
• scope 里没有 admin / all / full-access 这类大口径
• 有个指标在监控「越权被拦次数」——长期为 0 通常是没在拦，不是没人试

推演一遍「省事」的代价：
给 MCP Server 发了 admin，理由是省得每加一个工具就重新授权
        ↓
三个月后，有人给它加了个 export_all_orders 工具
        ↓
这个新工具当场就有权限了 —— 没人重新授权，没人审批
        ↓
某天这个 Server 被注入攻破 → 攻击者能干 admin 能干的全部

{ "mcpServers": { "github": {
    "command": "npx", "args": ["-y", "@modelcontextprotocol/server-github"],
    "env": { "GITHUB_TOKEN": "ghp_xxxx" }   // 就这么给
}}}