MCP 面试高频考点：给 Tool 调用加身份认证、最小权限与 RAG 协作，你能答到第几层？

面试场景

某团队正在把内部知识库和业务操作接入 MCP Server：一部分能力是只读检索，另一部分是会产生副作用的业务 Tool，例如修改工单、导出报表、读取财务文档。面试官希望候选人设计一套可落地的认证、授权与最小权限方案，并说明 JSON Schema、RAG 在其中的分工与边界。

基础问题：先说说 MCP Tool 的安全边界

面试官： 如果我们已经给每个 Tool 都写了清晰的描述，也定义了 JSON Schema 入参校验，是不是就可以认为 Tool 调用是安全的？为什么？

候选人： 结论是：远远不够。JSON Schema 只能做结构和格式约束，不能代替服务端的身份认证、授权和业务校验。 $资料1$

MCP 是客户端---服务端架构，Host 中的 MCP Client 与 MCP Server 建立会话，通信使用 JSON-RPC；Server 暴露 Tools、Resources、Prompts 三类能力。 $资料1$ Tool 是模型可发起调用的操作，通常带有副作用，所以 Server 必须把模型传入的文本视为不可信输入，不能因为请求来自 AI 应用就默认可信。 $资料1$

JSON Schema 的作用是： 1. 告诉模型和客户端这个 Tool 需要什么字段、字段类型、枚举范围； 2. 在协议层做基础参数校验； 3. 减少明显错误调用。

但它解决不了这些问题： - 当前用户是谁； - 用户是否有权访问某条数据或执行某个动作； - 参数中的文件路径、URL、资源 ID 是否属于当前用户； - 高风险操作是否需要用户确认； - 检索出来的知识库内容是否越权。

所以我的方案会把 JSON Schema 放在"接口契约层"，把认证授权放在"传输层和业务执行层"，把 RAG 检索权限放在"查询过滤层"，三者不能互相替代。

面试官点评： 考察点是是否理解 MCP 的安全边界。合格回答需要明确"Schema 不是安全边界"，并指出模型输入不可信。加分项是能把 Schema、授权、RAG 权限初步分层，而不是把所有校验混在一起。

追问一：认证和授权应该放在哪一层？

面试官： 那你具体怎么设计认证和授权？放在 Tool 方法里判断行不行？

候选人： 结论是：认证应尽量在传输层完成，细粒度授权应在 Tool 执行前和资源访问时完成，不能只依赖登录状态。 $资料1$

如果是本地 stdio 场景，通常是 Host 启动本机子进程，身份上下文可以由 Host 按约定传给 Server；但调试日志必须写到标准错误，不能写到标准输出，否则会破坏 JSON-RPC 通信。 $资料1$

如果是远程 Streamable HTTP 场景，Server 需要处理认证、会话管理、限流和超时。 $资料1$ MCP 规范允许客户端和服务端协商自定义认证授权策略，没有强制唯一方案。 $资料2$ Java SDK 也提供了可插拔的服务端授权钩子，授权能力集成在服务端传输层，但 SDK 本身不内置授权系统，目的是兼容 Spring Security、JWT 或企业自定义方案。 $资料4$

我的落地分层是：

传输层认证 - 远程部署时在 HTTP 层校验令牌、会话或双向证书； - 解析出用户身份、租户、角色、部门等主体信息； - 认证失败直接拒绝，不进入 Tool 分发。
Tool 级授权 - 在 Tool 执行前判断当前主体是否有该 Tool 的调用权限； - 例如普通用户不能调用"导出全员薪资报表"Tool。
参数级与资源级授权 - 即使有 Tool 调用权限，也要校验参数里的资源 ID 是否属于当前用户或授权范围； - 例如工单 ID、文档 ID、项目空间、财务期间都要做范围约束。
审计层 - 记录谁在什么时间调用了哪个 Tool、关键资源范围、结果状态； - 敏感字段脱敏； - 凭据不能出现在日志、Tool 返回值或模型上下文中。 $资料1$

如果把认证授权全部写在每个 Tool 方法里，短期可行，但会出现重复代码、绕过风险和审计不一致；如果只在传输层判断"已登录"，又会缺少最小权限控制。远程 MCP Server 必须对每次请求执行授权检查，不能只判断用户是否登录。 $资料1$

面试官： 那 JSON Schema 在这个分层里具体负责什么？

候选人： JSON Schema 负责协议层和输入结构约束，不负责权限判断。MCP 全协议都使用 JSON Schema 做校验，并提供了官方 JSON Schema 供自动化工具使用。 $资料2$

在 Tool 设计中，我会用 JSON Schema： - 明确必填字段，例如 document_id、ticket_id； - 限制类型、长度、枚举和格式； - 对高风险参数增加模式约束，例如资源 ID 必须符合内部命名规则； - 避免把自由文本直接拼接到 SQL、Shell、URL 或文件路径中。

但 Schema 无法知道某个 document_id 是否属于当前用户，所以服务端必须再次校验资源归属。 $资料1$

追问二：RAG 知识库和 Tool 权限怎么协作？

面试官： 我们还有一个企业知识库 RAG，财务文档只能财务团队看。如果把检索封装成 MCP Tool，模型可以主动调用检索，权限怎么做？这和普通业务 Tool 有什么区别？

候选人： 结论是：RAG 检索不是"搜到再看有没有权限"，而是要在查询时做安全裁剪，否则模型可能先拿到越权片段，再产生错误回答。 $资料1$ $资料3$

RAG 的基本链路包括文档解析、切块、建立索引、召回、可选重排，最后把相关片段和来源交给模型。 $资料1$ 检索结果需要保留来源元数据，才能支持引用和排错。 $资料1$ 但检索到的文档仍然是不可信数据，不能让其中的指令覆盖系统规则。 $资料1$

针对知识库权限，我会分三层处理：

知识源级别接入控制 - 如果知识来自已有权限系统，例如 SharePoint 或受身份系统保护的存储，应继承原有权限； - 这和企业检索方案中的"知识源级访问控制""继承存储权限元数据"一致。 $资料3$
索引文档级权限元数据 - 每个文档或切块保存可读主体信息，例如部门、角色、用户组、租户、密级； - 查询时根据当前身份生成过滤条件，只召回当前用户有权访问的片段； - 这对应文档级安全裁剪和查询时过滤。 $资料3$
检索 Tool 级最小权限 - 不是所有用户都能调用"全库检索"； - 可以按域拆分 Tool，例如"公开知识库检索""财务知识库检索""工单知识库检索"； - 高敏域检索 Tool 只开放给对应角色，并记录审计日志。

如果把 RAG 做成 MCP Tool，优点是模型可以根据任务决定何时检索，更灵活；但需要控制调用次数和权限。 $资料1$ 如果由 Host 在调用模型前主动检索，流程更简单、可预测。 $资料1$ 我的取舍是： - 公开或低敏知识，可以由 Host 预检索，减少模型滥用 Tool； - 高敏或跨域知识，使用受控 MCP Tool，并在查询时强制权限过滤； - 返回结果必须带来源元数据，便于引用、审计和排错。

这里有一个容易踩坑的细节：不能把权限判断放在召回之后。如果先根据向量相似度召回财务文档，再在应用层丢弃越权结果，可能造成上下文污染、引用错误，甚至在日志或错误信息中泄露敏感标题。正确做法是把权限条件下推到查询阶段。

方案设计：一个最小权限的 Tool 调用链路

面试官： 如果让你设计一个"读取并总结财务报表"的 MCP 能力，从请求到执行的完整链路是什么？异常怎么处理？

候选人： 我会这样设计：

第一，能力拆分。不要把"读取财务报表"做成一个万能 Tool。只读资料优先考虑 Resources 或受控检索 Tool，不要强行设计成有副作用的 Tool。 $资料1$ 如果只是读取报表内容，可以用带权限控制的检索或资源读取；如果涉及导出、发送邮件、修改状态，再单独定义 Tool。

第二，Tool 定义。用 JSON Schema 明确参数，例如报表周期、部门、输出格式；但同时在描述中说明需要财务权限，让模型知道何时不该调用。Schema 只约束格式，不决定权限。

第三，认证授权链路： 1. Host 中的 MCP Client 发起 JSON-RPC 调用； 2. 远程 Server 在传输层完成认证，解析用户身份； 3. 授权钩子检查用户是否有财务报表读取权限； 4. Tool 执行前校验报表周期、部门是否在用户授权范围内； 5. 如果是导出、发送等不可逆或高风险操作，返回明确影响范围，并要求用户确认后再执行； $资料1$ 6. RAG 或报表存储层根据用户身份做查询过滤，只返回授权数据； 7. 执行结果返回给 Client，同时写脱敏审计日志。

第四，异常处理： - 认证失败：返回明确的认证错误，不泄露内部权限结构； - 授权失败：提示"无权限访问该报表"，不返回文档标题、路径、其他部门名称等敏感信息； - Schema 校验失败：返回参数错误，提示哪个字段不合法； - 检索无结果：区分"没有权限"和"没有数据"，避免用无结果掩盖越权； - 部分成功：例如检索到内容但生成摘要失败，要保留来源并记录失败原因； - 凭据异常：令牌过期、签名无效时直接拒绝，不降级执行。

第五，可观测性： - 记录请求 ID、会话 ID、用户主体脱敏标识、Tool 名称、资源范围、耗时、结果状态； - 不记录原始令牌、完整密钥、敏感文档正文； - 对 Tool 调用频率、拒绝率、高敏 Tool 使用量做监控； - 限流、超时策略需要结合业务 SLA、风险和压测确定，不能拍脑袋设固定值。

下面用版本无关的伪代码说明职责边界：

text 复制代码

// 传输层：认证过滤器
onRequest(request):
    principal = authenticate(request)
    if principal is null:
        return auth_error
    context.setPrincipal(principal)
    return next(request)

// Tool 执行前：Tool 级 + 参数级授权
beforeToolCall(toolName, args, principal):
    if not hasToolPermission(principal, toolName):
        return permission_denied
    if not matchesSchema(toolName, args):
        return schema_error
    if not isResourceInScope(principal, toolName, args):
        return permission_denied
    if isHighRisk(toolName, args):
        requireUserConfirmation(toolName, args)

// RAG 检索层：查询时权限过滤
retrieveKnowledge(query, principal, domain):
    securityFilter = buildSecurityFilter(principal, domain)
    chunks = vectorStore.search(query, filter=securityFilter)
    chunks = rerankIfNeeded(chunks)
    return withSourceMetadata(chunks)

// 审计层
audit(toolName, principal, resourceScope, status):
    log(desensitize({
        requestId, toolName, principalId,
        resourceScope, status, timestamp
    }))

面试官点评： 考察点是能否把认证、授权、Schema 校验、RAG 权限过滤和审计串成完整链路。合格回答需要说明"查询时下推权限过滤""高风险操作需确认""凭据不入日志"。加分项是能区分认证失败、授权失败、Schema 错误、无数据等异常语义，并考虑可观测性。

面试官总结

这道题表面问的是"怎么给 MCP Tool 加认证授权"，实际考察三层能力：

第一，是否理解 MCP 基本架构与安全边界。MCP 是客户端---服务端协议，Tool、Resources、Prompts 各有适用场景；模型输入不可信，Schema 校验不能替代授权。 $资料1$

第二，是否能做出正确的工程分层。认证放传输层，Tool 级授权放执行前，资源级授权放数据访问层，RAG 权限在查询时过滤，审计贯穿全链路。SDK 提供授权钩子，但不替你做安全策略，这要求团队接入成熟的身份体系而不是自造脆弱逻辑。 $资料4$

第三，是否理解最小权限与业务取舍。不是所有能力都要做成 Tool；检索可以由 Host 预检索，也可以封装成受控 Tool；高风险操作要确认；日志、返回值、模型上下文都不能泄露凭据。 $资料1$

一个容易踩坑的点是：很多实现会把 RAG 权限做成"先召回后过滤"，或者把 JSON Schema 当成安全防线。前者可能泄露敏感内容，后者会在越权参数面前失效。真正可落地的方案，必须让协议约束、身份授权、数据权限和审计日志各自归位，才能在不破坏 MCP 灵活性的前提下控制风险。

参考资料

MCP 基础知识
Overview，https://modelcontextprotocol.io/specification/2026-07-28/basic
Retrieval-augmented generation (RAG) in Azure AI Search，https://learn.microsoft.com/en-us/azure/search/retrieval-augmented-generation-overview
MCP Java SDK，https://github.com/modelcontextprotocol/java-sdk