大厂 MCP 面试实录：高风险 Tool 调用的 OAuth 2.1 防护方案设计

本文为模拟面试复盘形式，围绕「防止提示注入诱导 MCP 高风险 Tool 调用」的业务场景展开，考察候选人对 MCP 安全边界、OAuth 2.1 授权规范及工程落地的理解。

面试场景开场

面试官 ：候选人你好，我们内部知识助手集成了 MCP 能力，包含文件删除、数据全量导出、工单强制关闭等高风险的 Tool，近期出现用户通过提示注入诱导模型违规调用的事故。先说说为什么 MCP Tool 自带的参数 Schema 校验不够用？ 候选人 ：首先给结论：Tool 的参数 Schema 仅能做结构层面的约束，完全无法防御提示注入导致的高风险操作，必须叠加 OAuth 2.1 细粒度授权与用户显式确认机制 $资料1$ 。原理层面，参数 Schema 仅约束参数的格式、类型和必填项，比如文件删除 Tool 的路径参数是字符串类型，传入 ../../etc/passwd 这类恶意路径在结构上是完全符合 Schema 要求的。而提示注入可以把恶意操作指令伪装成用户的正常需求，模型会直接发起 Tool 调用请求，参数结构完全合法。同时 MCP 的安全边界明确要求：Server 必须把模型传入的所有文本视为不可信输入，不能因为请求来自 AI 应用就默认其可信 $资料1$ ，所以仅靠参数校验无法覆盖风险。

基础概念追问

面试官 ：明白了，那 OAuth 2.1 在这个场景里的分工是什么？和 MCP 传输层自带的认证有什么区别？ 候选人 ：OAuth 2.1 在这里解决的是「用户操作授权」和「细粒度权限控制」的问题，和 MCP 传输层认证是互补关系，不是替代。 MCP 传输层的认证（比如 Streamable HTTP 传输下的 Bearer Token）只能证明「当前请求来自合法的 MCP Client」，也就是 Host 应用是经过认证的，但无法证明「当前操作是用户本人同意发起的」，也无法限制用户能调用哪些 Tool。而 OAuth 2.1 的 access token 是用户授权后发放的，绑定用户的身份和权限范围（scope），可以实现两个核心能力：一是校验操作是否经过用户授权，二是通过细粒度 scope 限制用户只能调用被授权的 Tool $资料3$ 。另外根据 MCP 授权规范，MCP Client 发起 OAuth 请求时必须携带 resource 参数，明确指定目标资源是当前的 MCP Server，避免 access token 被跨服务滥用；同时 MCP Server 绝对不能透传从 Client 收到的 token 给上游 API，需要单独向上游授权服务器申请对应的 token $资料4$ 。

面试官追问 ：如果攻击者绕过了 Host 侧的前端确认，直接诱导模型发起 Tool 调用，OAuth 2.1 怎么拦截这类请求？ 候选人 ：核心是两层校验：第一是 scope 校验，第二是风险分级确认。首先我们需要把高风险 Tool 的权限单独拆分为细粒度的 scope，比如把原本笼统的 tool:write 拆分为 file:delete、data:export、ticket:close 等独立的 scope，用户授权时默认只授予低风险 Tool 的权限，高风险权限需要用户显式勾选同意。MCP Server 收到 Tool 调用请求时，首先校验 access token 的 scope 是否包含当前 Tool 对应的权限，如果没有直接返回权限不足错误。其次对于有权限的高风险 Tool，不能直接执行，需要返回「需要用户确认」的响应，由 Host 侧弹出确认框，用户明确点击同意后才继续执行。如果攻击者诱导模型调用，没有用户的显式确认，请求会被直接拦截 $资料3$ 。

面试官再追问 ：那如果攻击者获取了带有高风险 scope 的有效 token，比如偷了用户的 token，怎么防止越权调用？ 候选人 ：需要叠加三方面的防护：第一是授权流程的风险提示，用户在授权页面申请高风险 scope 时，必须明确展示该权限的操作影响（比如「file:delete 权限可永久删除您工作目录下的所有文件，操作不可恢复」），禁止默认勾选高风险权限，避免用户被诱导授权 $资料3$ 。第二是异常行为检测，MCP Server 可以记录用户的历史调用行为，比如用户平时只调用知识检索类 Tool，突然发起文件删除请求，或者调用时间是凌晨等异常场景，可以触发二次验证（比如短信验证码、管理员审批），验证通过后才执行。第三是完整的审计日志，按照安全最佳实践，审计日志需要记录调用者的用户标识、调用的 Tool 名称、关键参数、时间、结果状态，同时敏感字段（比如文件路径、导出数据的关键字段）要脱敏，方便事后溯源 $资料1$ 。

方案设计与落地

面试官 ：现在需要你用 Python MCP SDK 落地这套方案，说说架构设计和关键实现，以及容易踩的坑。 候选人：整体架构分为三层：第一层是 Host 侧的前置校验，对用户输入做基础的提示注入检测，拦截明显的恶意指令；第二层是 MCP Server 的 OAuth 2.1 授权层，负责 token 校验、scope 校验和风险分级判断；第三层是 Tool 执行层，高风险 Tool 绑定用户确认钩子，执行前做二次校验。核心校验流程用伪代码示意如下：

伪代码复制代码

# 伪代码：MCP Server 核心校验流程
class MCPServer:
    def __init__(self):
        # 预定义 Tool 与所需权限的映射
        self.tool_permissions = {
            "delete_file": ["file:delete"],
            "export_data": ["data:export"],
            "close_ticket": ["ticket:close"],
            "search_knowledge": ["knowledge:read"]
        }

    async def handle_tool_call(self, request):
        # 1. OAuth 2.1 token 校验，携带 resource 参数绑定当前 Server
        token = extract_bearer_token(request)
        oauth_result = validate_oauth_token(
            token, 
            resource="https://mcp.internal/knowledge-assistant"
        )
        if not oauth_result.valid:
            return error_response("invalid_token", 401)

        # 2. 校验 scope 是否包含当前 Tool 的权限
        tool_name = request.params.name
        required_scopes = self.tool_permissions.get(tool_name, [])
        if not set(required_scopes).issubset(set(oauth_result.scopes)):
            return error_response("insufficient_scope", 403)

        # 3. 高风险 Tool 触发用户确认
        if tool_name in ["delete_file", "export_data"]:
            confirmation = await request_user_confirmation(tool_name, request.params.arguments)
            if not confirmation:
                return error_response("user_denied", 400)

        # 4. 执行 Tool 逻辑，参数二次校验
        return await execute_tool(tool_name, request.params.arguments)

容易踩的坑有四个：第一个是日志输出问题：MCP 基于 JSON-RPC 通信，调试日志必须写到标准错误（stderr），不能写到标准输出（stdout），否则会破坏协议消息的传输 $资料1$ 。第二个是 resource 参数问题：OAuth 2.1 请求必须携带固定的 resource 参数，绑定当前 MCP Server 的标识符，不能省略，否则 access token 可能被其他服务滥用 $资料4$ 。第三个是 token 透传问题：如果 MCP Server 需要调用上游 API（比如调用对象存储接口删除文件），绝对不能把 Client 传过来的 access token 透传给上游，需要 MCP Server 单独作为 OAuth 客户端，向上游授权服务器申请对应的 token，避免权限混乱 $资料4$ 。第四个是参数二次校验：OAuth 授权只能证明用户有调用 Tool 的权限，不能保证参数合法，比如用户有文件删除权限，但不能删除系统文件，所以 Tool 执行前必须对路径、SQL 参数等做二次约束，把模型传入的文本当成不可信输入处理 $资料1$ 。

边界与权衡追问

面试官追问 ：这个方案的适用边界是什么？有什么取舍？ 候选人 ：适用边界是有统一身份体系、需要细粒度权限控制的内部 MCP 场景，比如企业内部的知识助手、运维工具等，用户身份已经对接了公司的 IdP，支持 OAuth 2.1 授权流程。如果是公开的、无用户身份体系的 MCP Server，OAuth 2.1 的流程成本过高，更适合用 API Key 等轻量认证方式。关键取舍有两点：第一是安全与体验的权衡：细粒度的 scope 和用户确认能大幅降低越权风险，但高频调用低风险 Tool 时反复确认会影响用户体验，所以需要做风险分级：低风险 Tool（比如知识检索）不需要确认，中风险 Tool（比如生成报表）需要单次确认，高风险 Tool（比如删除、导出全量数据）需要二次验证或者管理员审批，平衡安全和体验。具体的分级阈值和确认策略需要根据业务风险等级和用户调研确定，没有通用的固定值。第二是安全与维护成本的权衡：细粒度的 scope 需要提前维护所有 Tool 和权限的映射，如果 Tool 迭代频繁，scope 的管理成本会很高，这种情况下可以适当合并低风险 Tool 的 scope，或者用动态权限的方式，根据 Tool 的实际风险动态申请权限。

面试官点评

考察点 ：第一是对 MCP 安全边界的理解，是否知道参数 Schema 的局限性，以及 Server 不能默认请求可信的原则；第二是 OAuth 2.1 在 MCP 场景中的正确用法，是否理解传输层认证和用户授权的区别，是否知道 resource 参数、token 不能透传等规范要求；第三是工程落地的权衡能力，是否清楚方案的适用边界，以及常见的实现坑。

合格回答：需要覆盖 MCP 参数校验的不足、OAuth 2.1 细粒度授权的必要性、高风险 Tool 需要用户确认、审计日志的要求。

加分项 ：提到 resource 参数的作用、token 不能透传的上游场景、风险分级的实践、Python MCP SDK 实现的常见坑（比如日志输出到 stderr）。

总结

整体来看，MCP 场景下的提示注入防护不能只靠协议本身的校验能力，需要结合外部的授权体系做纵深防御。OAuth 2.1 的细粒度授权是解决越权问题的核心手段，但需要配合风险分级、用户确认、审计日志和参数二次校验，才能在安全和体验之间找到平衡。对于 Python 生态的开发者，实现时尤其要注意 MCP 协议的通信规范，避免因为日志输出、token 透传等细节问题引入新的安全风险。

参考资料

MCP 基础知识
MCP Java SDK | https://github.com/modelcontextprotocol/java-sdk
Security Best Practices | https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices
Authorization Security Considerations | https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/security-considerations