🧑💻 面试官：Agent 通过 MCP 查询订单，权限在哪里检查？
🙋♂️ 我：服务端要检查凭证和权限，不能只靠提示词限制。
🧑💻 面试官：用户已经登录，也有查询订单的权限。他让模型填一个别人的订单号，可以查吗？
🙋♂️ 我：还要检查这条订单是否在他的授权范围内。
🧑💻 面试官：如果 MCP Server 用一个管理员账号访问下游系统，这个检查又由谁负责？
能连接服务器、能调用工具、能操作这条数据，是三个不同的问题。鉴权必须一直检查到实际要访问的业务对象。
面试速答（60 秒版）
Agent 调用 MCP 工具时，模型负责提出工具和参数，权限要由可信服务检查，不能让模型判断自己有没有权限。
对于需要授权的 HTTP MCP 服务，服务器先验证访问令牌是否有效、是否是签发给自己的，以及是否具备本次请求需要的权限。随后，处理业务操作的服务还要根据真实用户、租户和目标对象继续校验。
例如用户能调用查询订单工具，不代表他能查所有订单。用户身份应该来自已验证的会话或凭证，不能相信模型在参数里填写的用户编号。
MCP Server 访问下游服务时，也要使用适用于下游的凭证和授权方式，不能把收到的令牌不加区分地直接转发。
因此，客户端可以提前过滤工具和提示审批，但最终限制仍需在服务端落实，并保留必要的操作审计。
知识点详解：沿着一次 MCP 调用检查权限
用户登录成功，只回答了其中一个问题
假设咱们做一个企业订单助手。甲公司的员工希望查询订单，AI 应用通过 MCP Client 调用订单 MCP Server，后者再访问订单业务服务。
一次请求可能经过这些环节：用户会话、AI 应用、MCP Client、MCP Server、订单业务服务。
模型在其中提出“查询订单 O-208”，但它输出的参数只是待处理的数据。如果 O-208 实际属于乙公司，服务端必须拒绝，不能因为模型认为这是合理查询就放行。
这里至少有三层判断：请求方身份是否可信，是否允许查询订单，以及是否允许查询 O-208。前两层通过，不能省略第三层。
MCP 接口这一层，要检查什么？
以受保护的 HTTP MCP 服务为例，MCP Server 需要按令牌类型和授权方案，验证签发方、有效性、有效期、目标受众等信息，再检查请求需要的授权范围。
其中“目标受众”可以简单理解为：这张访问凭证究竟是发给哪个服务使用的。 用户拿着另一个服务的有效令牌，并不意味着订单 MCP Server 就应该接受它。令牌也不一定是 JWT，不能把所有实现都写成“解码一下 JWT 就完成鉴权”。
按本次核验的 MCP 2026-07-28 授权规范，这一授权流程针对 HTTP 传输；STDIO 的凭证处理不同，不能直接照搬。协议允许某些实现不启用授权，也不代表承载私有订单数据的产品可以省略访问控制。
凭证应由客户端与服务端的可信代码管理，不需要放进模型上下文。模型只需知道当前可使用的能力，不需要看到可以复制出去的访问令牌。
进入工具之后，还要检查目标对象
模型可能提出下面几个业务参数：订单号、要查看的字段、查询时间范围。
而当前用户、所属租户和可信权限信息，应该从已经验证的上下文中取得。如果工具接口允许传租户参数，服务端也必须校验它是否属于当前授权范围，不能直接拿模型提供的值当过滤条件。
| 检查位置 | 需要回答的问题 |
|---|---|
| MCP Server 的认证入口 | 凭证是否有效，是否确实用于访问本服务？ |
| 工具处理入口 | 当前主体是否允许执行这个操作？ |
| 业务数据访问层 | 当前主体是否有权访问这条订单及这些字段？ |
| 高风险动作入口 | 是否还需要审批，当前参数是否与审批一致？ |
检查不一定分散在四套独立服务里，但这些责任不能漏掉。可以复用统一策略服务，也可以在可信业务边界集中执行。
针对订单查询，最好在数据读取时就限定授权范围，而不是先把全量数据交给模型，再要求它“不要展示别人的订单”。模型一旦读到，数据隔离就已经失败了。OWASP 的对象级授权说明描述的正是这类风险。
MCP Server 的下游账号，不能掩盖真实用户
如果 MCP Server 使用一个权限很大的服务账号访问订单服务，下游可能只看到“服务账号有权查询”，却不知道请求来自甲公司员工。
此时必须有明确的授权设计：由可信服务在调用前落实用户和对象权限，或者通过适当的委托机制，让下游获得可验证的用户授权上下文。不要仅在普通参数里附一个用户 ID，就声称实现了身份委托。
连接两个系统时，还要区分两段凭证。MCP 客户端访问 MCP Server 的令牌，通常不能直接当成下游订单 API 的令牌使用。下游凭证需要按目标服务的授权方式获取和管理。
MCP 安全实践明确反对令牌透传这种做法，尤其不能接受不是签发给本 MCP Server 的令牌，再原样转交下游。接入方便，不能成为跨越凭证边界的理由。
工具列表过滤和人工确认，各能解决什么？
应用可以不向用户展示没有权限的工具，减少模型误选；对修改订单等动作，可以要求用户确认。这些都很有用，但不是最终防线。
因为攻击者可能绕过界面直接构造请求，或者用户权限在任务执行期间发生变化。工具真正执行时，仍然要重新检查。
人工确认也要绑定具体动作与参数。如果用户确认的是订单 O-208，模型之后把参数改成另一条订单，原来的确认就不能继续沿用。
测试时，除了验证正常请求，还应主动更换订单号、租户、权限范围和令牌目标服务，检查服务端是否拒绝。日志记录谁请求了什么、针对哪个对象、为什么允许或拒绝，但不要把完整访问令牌写进日志。
面试官继续追问
模型能看见某个工具，是不是就说明它有权调用？
不能。目录过滤只能改善使用体验和降低误调用，不能代替执行时鉴权。工具列表可能过期，调用也可能不是通过正常模型路径发起的，因此服务端必须独立判断。
使用本地 STDIO MCP，就没有权限问题了吗？
仍然有。只是不用直接套用 HTTP 的 OAuth 流程。需要管理进程可读的凭证、文件、网络和系统权限。如果本地服务又被代理给多个远程用户，还要设计用户隔离，不能因为底层是本地进程就默认所有调用可信。
用户说“我同意查询所有订单”，可以提升权限吗？
不可以。用户意愿不能扩大其账号本来没有的权限。审批只能在已授予的权限范围内确认具体动作，不能替代管理员授权或组织策略。
面试速记卡
- 模型职责：提出动作和参数，不负责授予自己权限。
- 接口授权：验证访问凭证、目标服务和所需权限范围。
- 业务授权：继续检查真实用户对具体数据的访问权限。
- 下游调用：使用适用的凭证与委托机制，不直接透传令牌。
- 最终边界：目录过滤和用户确认都不能代替服务端检查。
