大厂 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]。面试官点评考察点对 MCP 核心架构Client/Server、Tools 规范、传输方式、安全边界的理解在真实业务场景下的分层架构设计能力能否把最小权限、审计、人机协同、注入防护四个需求有机结合起来而不是堆砌概念对安全、合规、用户体验三者平衡的思考能力对落地细节的把控能力。合格回答能清晰说出四层架构的设计思路知道权限要做多层校验知道审计日志要记录的关键字段知道人机确认要分级能说出基本的注入防护逻辑。加分项能说出远程部署的 SSRF 防护、日志防篡改、参数级权限的具体实现逻辑能结合团队规模做方案取舍能说出标准输出写日志、不信任 Client 等易踩坑的细节。总结将内部 REST API 封装为可审计 MCP Tools 的核心是围绕 MCP 的安全边界做全链路防护权限层做最小权限拦截安全层做注入和风险操作防护审计层做全链路溯源人机协同做风险缓冲。实际落地时需要根据团队规模、业务风险做灵活调整核心原则是「所有来自模型、Client、外部召回的内容都是不可信的」所有校验逻辑必须放在 Server 侧不能依赖前端或 Client 的校验。参考资料MCP 基础知识Tools | 公开链接: https://modelcontextprotocol.io/specification/2026-07-28/server/toolsSecurity Best Practices | 公开链接: https://modelcontextprotocol.io/docs/tutorials/security/security_best_practicesSampling | 公开链接: https://modelcontextprotocol.io/specification/2026-07-28/client/sampling