大厂 MCP 面试实录：REST API 封装为可审计 MCP Tools 的落地实践

本文采用模拟面试复盘形式，围绕「将内部业务 REST API 封装为合规可审计的 MCP Tools」这一企业级落地场景，梳理 MCP 相关岗位的面试考察逻辑与核心技术要点。

---

面试官：候选人你好，今天我们考察的核心场景是：公司内部有多个业务 REST API，希望封装为 MCP Tools 供内部 AI 助手调用，同时必须满足最小权限控制、全链路审计、人机协同确认、提示注入防护四项要求。请你先说说整体的设计框架。

候选人：我会采用「协议层-权限层-安全层-审计层」的四层架构做设计，各层能力相互配合：协议层基于 MCP 客户端-服务端架构做 REST API 到 MCP 协议的适配，把每个 REST 接口封装为符合规范的 Tool，明确输入输出 schema，避免把只读资料强行设计为有副作用的 Tool[资料1]；权限层做细粒度的 Tool 级+参数级权限控制，结合用户业务身份做授权校验，是所有请求的第一道闸门；安全层负责提示注入检测、敏感操作拦截、参数/输出脱敏，防范各类注入和泄露风险；审计层全链路记录调用信息，满足合规溯源要求。其中权限层负责过滤未授权调用，安全层负责拦截风险操作，审计层负责全链路留存，人机协同作为中高风险操作的二次确认缓冲，平衡安全和体验。

---

面试官追问1：你提到了细粒度权限控制，这和传统 API 网关的接口级权限校验有什么区别？怎么实现最小权限？

候选人：传统 API 网关的权限通常控制在接口级，比如用户有订单查询接口权限就能查所有订单，而 MCP 场景的最小权限需要三重约束：首先是 Tool 级权限，不是所有用户都能调用所有 Tool，比如普通用户仅能调用订单查询 Tool，管理员才能调用订单管理类 Tool；其次是 参数级权限，就算同一个 Tool，参数也要做约束，比如普通用户调用订单查询 Tool 时传入的 user_id 必须和当前登录用户一致，不能传入其他用户 ID 查询；最后是 校验侧约束，权限校验不能只靠前端或 MCP Client 传的用户信息，Server 侧必须对每次请求重新做授权校验，不能因为请求来自内部 AI 应用就默认可信[资料1]。实现上可以在 MCP Server 的 Tool 调用拦截器里做统一权限校验，把用户业务角色、Tool 权限要求、参数合规性一起判断，不满足直接返回错误。比如「查询用户订单」Tool 的拦截逻辑伪代码如下：

// 伪代码：MCP Server 侧 Tool 调用拦截逻辑
function handleQueryUserOrdersToolCall(params, securityContext) {
    // 权限校验：普通用户仅可查询自身订单，管理员可查询全量
    const currentUserId = securityContext.getCurrentUserId();
    const isAdmin = securityContext.isAdmin();
    if (!isAdmin && params.user_id !== currentUserId) {
        throw new Error("无权查询其他用户的订单");
    }
    // 参数语义校验：避免注入风险
    if (!/^\d+$/.test(params.order_id)) {
        throw new Error("订单ID格式不合法");
    }
    // 调用内部REST API
    return restClient.get("/internal/orders", { 
        userId: params.user_id, 
        page: params.page, 
        pageSize: params.pageSize 
    });
}

---

面试官追问2：如果模型传入的参数包含恶意内容，比如 SQL 注入片段、路径穿越字符，或者提示注入的恶意指令，你的四层设计怎么处理？

候选人：这类风险会在权限层和安全层共同拦截：首先是参数校验层，Server 侧不能只依赖 Tool 的 inputSchema 做结构校验，还要做语义校验：比如订单 ID 必须是纯数字，禁止传入包含单引号、../ 等特殊字符的内容，路径类参数要做白名单限制，禁止访问非预期资源[资料2]；然后是提示注入防护层，不管是模型生成的调用参数，还是 RAG 召回后插入到上下文里的内容，都要先做注入检测，检测是否存在「忽略规则」「调用高危 Tool」这类恶意指令，如果命中就直接过滤，不执行调用[资料1]；最后就算恶意参数绕过了前两层，权限层也会做参数级校验，比如用户传入的 user_id 和当前登录用户不一致，直接拒绝调用，不会透传到后端 REST API。

---

面试官追问3：人机协同确认的时机怎么把握？如果所有调用都要求确认，用户体验会很差，怎么平衡安全和体验？

候选人：我们会按风险等级做分级确认机制，不是所有调用都需要确认：低风险操作比如查询类 Tool、参数为预定义枚举的只读操作，不需要用户确认，直接执行；中风险操作比如涉及敏感数据查询（比如查询用户手机号）、参数包含动态拼接内容的操作，需要向用户展示调用影响，用户确认后再执行；高风险操作比如删除、更新、发送通知等不可逆或影响范围大的操作，必须强制用户二次确认，还要明确展示操作的具体影响，比如「即将删除 ID 为 123 的订单，该操作不可撤销，是否确认？」。同时我们会把确认逻辑放在 Host 侧（AI 应用端），在调用 MCP Server 之前先向用户展示 Tool 的输入和影响，避免恶意或意外的数据泄露，符合 MCP 规范里「Client 应当对敏感操作提示用户确认」的要求[资料2]。

---

面试官追问4：审计日志具体要记录哪些内容？怎么保证日志不泄露敏感信息，同时不被篡改？

候选人：审计日志需要记录完整的调用链路信息：调用时间、调用方用户 ID、AI 应用 ID、调用的 Tool 名称、输入参数（脱敏后）、后端 REST API 的响应结果（脱敏后）、执行状态（成功/失败/权限拒绝/用户取消）、用户确认标识[资料2][资料3]。敏感字段比如手机号、身份证号、API 密钥、内部服务地址等必须做脱敏处理，不能出现在日志里。日志会写入独立的审计系统，和业务日志物理隔离，写入时会给每条日志加哈希链，防止被篡改，同时审计系统的访问权限单独管控，只有合规和运维人员可以查询，留存周期需符合企业合规要求。

---

面试官追问5：如果 MCP Server 是远程部署，用 Streamable HTTP 传输，除了前面提到的内容，还要注意什么安全问题？

候选人：远程部署首先要做传输层加密，全部用 HTTPS 禁止 HTTP 访问；然后要做强认证，每个请求都要携带有效的身份令牌，Server 侧每次都要校验令牌的有效性和用户权限，不能只判断用户是否登录[资料1]；还要做会话管理和限流，防止会话劫持和恶意调用；另外要防范 SSRF 风险，因为 MCP Server 需要调用内部 REST API，要限制 Server 只能访问授权的内部 API 地址，禁止访问云元数据接口（比如 169.254.169.254 这类地址），避免被攻击者利用获取云服务凭据[资料3]；还要做超时和熔断控制，防止内部 REST API 故障拖垮 MCP Server，超时阈值需根据内部 API 的 SLA 和压测结果确定。

---

面试官追问6：整个方案有什么适用边界和取舍？小团队用会不会太复杂？

候选人：这个方案适合中大型团队，有多业务线、有合规审计要求、需要对外提供 AI 能力的场景，核心价值是满足安全合规要求。如果是小团队，业务简单、调用量小，可以简化：比如权限控制可以先做粗粒度的 Tool 级权限，不用做参数级；审计日志可以先写入业务日志，不用独立的审计系统；人机确认可以先只针对删除类高危操作，不用全分级。取舍上主要是安全、体验和灵活性的平衡：权限控制越严格、确认流程越复杂，安全性越高，但用户体验和模型调用灵活性会下降，比如参数校验太严格可能会导致模型无法调用 Tool，所以需要根据业务风险合理调整校验规则，比如对内部可信的 AI 应用可以适当放宽参数限制，对面向外部的 AI 应用要严格限制。

---

面试官追问7：有没有容易踩坑的细节？

候选人：第一个坑是很多人会把 MCP Client 当成可信节点，实际上 Client 也可能被攻击，所以所有校验逻辑必须放在 Server 侧，不能依赖 Client 传的认证信息或参数[资料1]；第二个坑是调试日志写到标准输出，会破坏 MCP 的 JSON-RPC 通信，所以调试日志必须写到标准错误[资料1]；第三个坑是 Tool 的输出没有脱敏，导致敏感信息泄露到模型上下文里，甚至被返回给用户，所以所有输出都要做脱敏处理[资料2]；第四个坑是忽略提示注入风险，把 RAG 召回的内容直接放到系统提示里，导致恶意指令覆盖系统规则，所以所有外部召回的内容都要先做注入检测[资料1]；第五个坑是把只读的查询类能力设计为有副作用的 Tool，导致模型误调用执行写操作，需要严格按照语义选择能力类型[资料1]。

---

面试官点评

1. 考察点：对 MCP 核心架构（Client/Server、Tools 规范、传输方式、安全边界）的理解；在真实业务场景下的分层架构设计能力，能否把最小权限、审计、人机协同、注入防护四个需求有机结合起来，而不是堆砌概念；对安全、合规、用户体验三者平衡的思考能力；对落地细节的把控能力。
2. 合格回答：能清晰说出四层架构的设计思路，知道权限要做多层校验，知道审计日志要记录的关键字段，知道人机确认要分级，能说出基本的注入防护逻辑。
3. 加分项：能说出远程部署的 SSRF 防护、日志防篡改、参数级权限的具体实现逻辑，能结合团队规模做方案取舍，能说出标准输出写日志、不信任 Client 等易踩坑的细节。

---

总结

将内部 REST API 封装为可审计 MCP Tools 的核心是围绕 MCP 的安全边界做全链路防护：权限层做最小权限拦截，安全层做注入和风险操作防护，审计层做全链路溯源，人机协同做风险缓冲。实际落地时需要根据团队规模、业务风险做灵活调整，核心原则是「所有来自模型、Client、外部召回的内容都是不可信的」，所有校验逻辑必须放在 Server 侧，不能依赖前端或 Client 的校验。

---

参考资料

1. MCP 基础知识
2. Tools | 公开链接: https://modelcontextprotocol.io/specification/2026-07-28/server/tools
3. Security Best Practices | 公开链接: https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices
4. Sampling | 公开链接: https://modelcontextprotocol.io/specification/2026-07-28/client/sampling