企业官网建设流程全解析

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]

我的落地分层是：

1. 传输层认证- 远程部署时在 HTTP 层校验令牌、会话或双向证书； - 解析出用户身份、租户、角色、部门等主体信息； - 认证失败直接拒绝，不进入 Tool 分发。

2. Tool 级授权- 在 Tool 执行前判断当前主体是否有该 Tool 的调用权限； - 例如普通用户不能调用“导出全员薪资报表”Tool。

3. 参数级与资源级授权- 即使有 Tool 调用权限，也要校验参数里的资源 ID 是否属于当前用户或授权范围； - 例如工单 ID、文档 ID、项目空间、财务期间都要做范围约束。

4. 审计层- 记录谁在什么时间调用了哪个 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]

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

1. 知识源级别接入控制- 如果知识来自已有权限系统，例如 SharePoint 或受身份系统保护的存储，应继承原有权限； - 这和企业检索方案中的“知识源级访问控制”“继承存储权限元数据”一致。[资料3]

2. 索引文档级权限元数据- 每个文档或切块保存可读主体信息，例如部门、角色、用户组、租户、密级； - 查询时根据当前身份生成过滤条件，只召回当前用户有权访问的片段； - 这对应文档级安全裁剪和查询时过滤。[资料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, 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