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-RPCServer 暴露 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、风险和压测确定不能拍脑袋设固定值。下面用版本无关的伪代码说明职责边界// 传输层认证过滤器 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, filtersecurityFilter) 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 基础知识Overviewhttps://modelcontextprotocol.io/specification/2026-07-28/basicRetrieval-augmented generation (RAG) in Azure AI Searchhttps://learn.microsoft.com/en-us/azure/search/retrieval-augmented-generation-overviewMCP Java SDKhttps://github.com/modelcontextprotocol/java-sdk