MCP 面试高频考点：如何给 Tool 调用做身份认证、最小权限与可观测-平芜编程栈

MCP 面试高频考点：如何给 Tool 调用做身份认证、最小权限与可观测

面试场景

一位候选人正在面试 AI 应用平台开发岗位，岗位要求熟悉 MCP（Model Context Protocol）客户端/服务端架构，能把内部系统能力安全地暴露给大模型调用。面试官没有从“什么是 MCP”开始，而是直接给出一个常见业务场景：你们要把企业内部的文档检索、工单创建、数据查询等能力封装成 MCP Server，供多个 Host 应用接入。现在需要解决 Tool 调用的身份认证、授权、最小权限，以及线上排障问题。

基础问题：先把边界说清楚

面试官：如果我让你为一个远程部署的 MCP Server 设计 Tool 调用安全方案，第一步你会怎么划分责任边界？

候选人：我的结论是：认证、授权和最小权限不能只放在模型侧，也不能只靠 Tool 的参数 schema，必须以 MCP Server 为执行边界，在传输层做身份接入，在 Tool 执行层做细粒度授权，在返回和日志层做凭据脱敏。

原因有三点。第一，MCP 是客户端—服务端架构，Host 里的 MCP Client 会和 Server 建立会话，消息基于 JSON-RPC；对远程 HTTP 传输来说，认证和授权属于传输层能力，适合在接入层完成身份校验和会话建立[资料1][资料3]。第二，Tool 的输入 schema 只是结构约束，比如字段是不是字符串、是不是必填，它不能判断“这个用户能不能查财务部文档”“能不能关闭别人的工单”，所以服务端必须把模型传入的文本当作不可信输入[资料1]。第三，stdio 场景和远程 HTTP 场景不同：本地子进程启动的 Server 通常从运行环境拿凭据，不适合照搬 HTTP OAuth 流程；而 Streamable HTTP 远程服务必须额外考虑认证、授权、会话、限流和超时[资料1][资料3]。

面试官：那你说的“传输层做身份接入，Tool 层做授权”具体怎么落？

候选人：我会分成两层。第一层是传输层鉴权。对于 HTTP 传输，按照 MCP 授权规范，授权能力位于传输层，客户端代表资源所有者访问受限服务端，HTTP 传输应遵循授权规范；如果是 stdio 传输，则不应套用 HTTP 授权流程，而是从环境获取凭据[资料3]。Java 生态里，MCP Java SDK 提供的是可插拔授权钩子，不内置具体认证系统，授权集成在 server transport 层，这样应用可以接入 Spring Security、JWT 或自定义鉴权，而不是被 SDK 锁死[资料2]。

第二层是 Tool 执行层授权。身份通过后，不能直接认为“登录了就能调所有 Tool”。我会为每个 Tool 定义权限点，例如docs.search、ticket.create、ticket.close，再结合资源范围判断，比如只能查本部门文档、只能处理自己创建的工单。Tool 参数必须二次校验，特别是文件路径、URL、SQL、Shell 参数和资源标识符，避免越权和注入[资料1]。高风险或不可逆操作，例如批量删除、对外发消息、执行工单流转，还应在 Host 侧展示具体影响并要求用户确认，而不是模型一说就执行[资料1]。

追问一：最小权限不是“有 token 就行”

面试官：你提到最小权限。如果现在有个文档检索 Tool，模型调用时只传了关键词，用户身份在 token 里，你怎么避免它搜到不该看的内容？

候选人：结论是：检索 Tool 不能把“用户已登录”当成“可以搜全库”，必须把用户身份和权限上下文带入检索条件，并在返回结果前后都做约束。

我会把文档检索设计成 Tool，而不是 Prompt 或 Resource 模板，因为它是模型根据任务动态发起的操作，需要输入查询词、过滤条件，并返回带来源元数据的结果；但它本质上应是只读操作，不能借“检索”之名执行写入[资料1]。RAG 检索链路里，切块、索引、召回后，要保留来源元数据，这样才能做权限过滤、引用和排错[资料1]。

具体做法是：第一，传输层拿到用户身份后，解析出用户 ID、部门、角色、租户、可访问文档库范围；第二，Tool 执行时把这些范围转成检索过滤条件，例如只在授权空间内召回，而不是先全库召回再简单截断；第三，对返回片段保留来源元数据，必要时在结果层再做一次权限复核，避免索引权限延迟导致越权；第四，审计日志记录谁在什么时间调用了哪个 Tool、关键资源范围和结果状态，敏感字段脱敏，凭据绝不能进入日志、Tool 返回值或模型上下文[资料1]。

这里有个容易踩坑的点：很多人会把权限检查做成“先查出结果，再根据结果过滤”。这样不仅浪费召回配额，还可能把无权限文档的片段通过排序、摘要或错误信息泄露出去。我更倾向于把权限条件前置到检索过滤，再对返回结果做复核。

面试官：如果权限服务临时异常怎么办？比如 JWT 有效，但权限中心查不到角色，你是放行还是拒绝？

候选人：默认拒绝，不做隐式放行。因为远程 MCP Server 应对每次请求执行授权检查，不能只判断用户是否已登录[资料1]。但拒绝也要区分可观测性：我会记录鉴权失败原因是“权限服务不可用”还是“明确无权限”，并给 Host 返回可理解的错误，而不是暴露内部堆栈。对于可重试的短暂故障，可以由传输层或客户端按业务 SLA 做有限重试；重试次数、超时和缓存时长不能拍脑袋定，要根据业务风险、SLA 和压测结果确定。

追问二：Prompts 和 OpenTelemetry 在这里怎么协作

面试官：你刚才主要讲了 Tools 和安全。题目里还提到 Prompts 和 OpenTelemetry。很多候选人会把 Prompts 当成普通提示词，把 OpenTelemetry 当成打日志。你怎么让它们和权限方案真正协作？

候选人：我的结论是：Prompts 负责把用户可显式选择的安全工作流模板化，OpenTelemetry 负责把跨 Host、Client、Server、Tool、权限服务、检索服务的调用链串起来，二者都不直接替代授权，但能显著降低误调用和排障成本。

先说 Prompts。MCP 里的 Prompts 是用户可显式选择的模板化消息或工作流，不是所有系统提示都叫 Prompt[资料1]。在这个场景里，我不会把“权限规则”偷偷写进模型看不见的地方，而是会暴露几个受控 Prompt 模板，例如“按最小权限检索并总结文档”“创建工单前先校验必填字段并生成确认信息”“执行高风险操作前列出影响范围”。这些 Prompt 的作用不是授权，而是规范模型在调用 Tool 前后的行为：先明确任务目标，再选择必要 Tool，再收集参数，再触发确认。这样可以减少模型随意拼接 Tool 参数、绕过确认流程的概率。

举个版本无关的接口设计例子：一个文档检索 Prompt 可以要求输入“查询主题、时间范围、是否包含跨部门资料”；如果用户选择“不包含跨部门资料”，Prompt 模板会在生成给模型的消息里明确要求调用docs.search时带上限定范围参数。但这只是行为约束，不是安全边界。真正是否允许跨部门检索，仍然由 Server 端 Tool 根据用户身份判断[资料1]。

再说 OpenTelemetry。MCP 的一次 Tool 调用会跨越多个组件：用户在 Host 发起请求，Host 内的 MCP Client 通过 HTTP 或其他传输向 Server 发 JSON-RPC 消息，Server 进入传输层鉴权钩子，调用权限服务，执行 Tool，可能再访问数据库、检索引擎或工单系统，最后返回结果。没有链路追踪时，线上出现“为什么这个用户搜到了不该看的文档”“为什么 Tool 超时”“为什么 Prompt 触发了高风险 Tool”时，只能靠零散日志猜。

我会在这些关键节点埋点： 1. MCP Client 发起请求时创建 span，记录会话、用户主体摘要、目标 Tool 或 Prompt、请求 ID； 2. Server 传输层鉴权时创建子 span，记录鉴权结果、使用的授权策略、失败类别，但不记录原始 token； 3. Tool 执行时创建子 span，记录 Tool 名称、参数校验结果、访问的资源范围摘要、执行状态； 4. 对下游权限服务、检索服务、工单服务继续传播 trace context，形成端到端链路； 5. 指标层统计 Tool 调用量、错误率、鉴权失败率、P95 延迟、限流触发次数； 6. 审计日志与 trace ID 关联，但敏感字段脱敏，凭据不写入日志或返回值[资料1]。

面试官：如果我发现某个 Prompt 经常诱导模型调用高风险 Tool，OpenTelemetry 能帮我做什么？

候选人：可以从三个层面定位。第一，链路里能看到是哪个 Prompt 模板触发了哪次 Tool 调用，因为我会在 span 属性里记录 Prompt 标识和版本；第二，可以聚合统计某个 Prompt 对应的高风险 Tool 调用率、确认率、拒绝率，判断是 Prompt 模板设计问题、模型路由问题，还是权限配置过宽；第三，如果出现异常飙升，可以通过 trace 关联到具体用户、会话、参数校验失败原因和下游错误，而不是只看到“调用失败”。

这里的取舍是：埋点不能过细到把完整用户输入、文档内容、token 都打进 trace，否则会带来新的数据泄露风险。OpenTelemetry 解决的是可观测，不是安全本身；它必须和授权、脱敏、审计一起设计。

方案设计：一个可落地的分层方案

面试官：你把认证、授权、Prompts、OpenTelemetry 串一下，给我一个完整但不过度设计的方案。

候选人：我会采用四层方案。

第一层，传输接入层。远程 HTTP Server 按 MCP 授权规范在传输层接入认证，支持企业现有身份体系；本地 stdio Server 从环境获取凭据，不强行走 HTTP 授权流程[资料3]。SDK 侧使用可插拔授权钩子，不重复造认证系统[资料2]。

第二层，会话与主体层。认证通过后建立 MCP 会话，解析出用户、租户、角色、资源范围等主体信息，并在请求上下文中传递。凭据只在接入层短暂使用，不进入 Tool 实现、日志和模型上下文[资料1]。

第三层，Tool 与 Prompt 协作层。只读能力优先设计为 Tool 或 Resource，不把查询包装成有副作用的 Tool；高风险操作单独设计 Tool，并要求用户确认[资料1]。Prompts 暴露为用户可选的工作流模板，帮助模型按安全流程调用 Tool，但不承担授权责任。

第四层，可观测与审计层。用 OpenTelemetry 打通 Client、Server、鉴权、Tool、下游服务的 trace、metrics 和 logs；审计日志记录谁、何时、调用哪个 Tool、访问了哪类资源、结果如何，并与 trace ID 关联；敏感字段脱敏，异常按“默认拒绝、可观测、可重试边界清晰”处理[资料1]。

适用边界上，这套方案适合多 Host 接入、远程部署、涉及企业内部数据和操作的 MCP Server；如果只是本地单机、单用户、完全受控的 stdio 工具，则不必上完整 OAuth 流程，但仍要做参数校验和危险操作确认。关键取舍是：安全和体验之间要平衡，确认步骤过多会降低可用性，所以只对高风险、不可逆操作做显式确认；可观测数据要足够排障，但不能泄露凭据和敏感内容。

最容易踩坑的细节是：把 Tool 参数 schema 当安全校验、把登录态当授权、把 Prompt 约束当服务端边界、把调试日志写到 stdio Server 的标准输出导致 JSON-RPC 通信被破坏[资料1]。

面试官点评

考察点：这组问题主要考察候选人是否理解 MCP 的客户端/服务端边界，能否区分传输层认证、Tool 层授权、参数校验、审计和可观测性的职责，是否知道 Prompts 的正确定位，以及是否能把 OpenTelemetry 用于真实排障而不是泛泛谈“打日志”。

合格回答：能明确说明远程 HTTP 与 stdio 的授权方式差异；能指出 schema 校验不能代替授权；能把最小权限落实到资源范围过滤；能说明高风险操作需要用户确认；能解释 Prompts 是用户可显式选择的模板化工作流，不是安全边界；能设计端到端链路追踪并避免凭据泄露。

加分项：能提到 MCP Java SDK 只提供可插拔授权钩子、不内置授权实现[资料2]；能说明 confused deputy 风险背景下必须每次请求做授权，而不是信任来自 AI 应用的请求；能讲清楚 trace、metrics、审计日志三者的分工；能主动给出适用边界、取舍和踩坑点。

总结

MCP 的安全设计不是“加个 token”就结束。传输层负责把身份接进来，Tool 层负责按最小权限决定能不能执行，Prompts 负责把安全流程模板化，OpenTelemetry 负责把整条调用链看清楚。真正上线时，最危险的不是“没有认证”，而是误以为有了认证、有了 schema、有了 Prompt 约束，就可以让模型随意调用内部能力。对 MCP Server 来说，每一次 Tool 调用都应被当作不可信输入来校验，每一次授权结果都应可审计，每一条链路都应可追踪。