导语：MCP（Model Context Protocol）让大模型能够以标准方式连接外部数据、工具和业务系统，也让“模型能调用什么、以谁的身份调用、调用到什么程度”变成新的安全边界问题。官方规范将 MCP 描述为连接 LLM 应用与外部数据源、工具能力的开放协议，并明确提醒实现者关注任意数据访问和代码执行路径带来的安全与信任风险，参见 MCP 规范说明。🛡️
一、为什么 MCP 工具调用需要权限边界建模
在传统系统中，权限通常围绕用户、角色、接口和资源展开；而在 MCP 场景中，权限链路被拉长为“用户意图、AI Host、MCP Client、MCP Server、外部 API 或数据库”。如果只给 MCP Server 配置一个高权限密钥，再让模型自由决定何时调用工具，就很容易形成“模型被诱导后代替用户越权操作”的风险。
权限边界建模的核心，不是简单地问“这个工具能不能调用”，而是要回答四个问题：谁发起、代表谁、访问什么、允许做到哪一步。例如，同样是“查询客户资料”工具，客服场景可能只允许读取当前工单相关客户的基本信息，财务场景可能允许读取账单状态，但不应默认允许导出完整客户数据库。
二、MCP 调用链中的主要权限对象
MCP 权限模型可以拆成几个对象：用户身份、AI 应用身份、MCP Client 身份、MCP Server 身份、工具身份、资源身份和操作范围。只有把这些对象分开建模，才能避免“一个 token 走天下”的粗放做法。
- 用户身份：确认真实操作者是谁，以及该用户在业务系统中的权限范围。
- 应用身份：确认是哪一个 AI 应用或 Agent 在发起调用，避免第三方客户端冒用可信应用。
- 工具身份：为每个工具定义唯一名称、用途、输入参数、输出类型和风险等级。
- 资源身份：明确工具最终会访问哪些文件、数据库表、API、知识库或 SaaS 对象。
- 操作范围：区分读取、创建、修改、删除、导出、审批、支付等不同风险动作。
三、常见越权路径：不是漏洞一个点，而是链路失控
MCP 越权并不一定来自代码漏洞，也可能来自边界设计不清。比如用户只要求“总结项目进展”，模型却调用了“读取全部项目文档”的工具；用户只允许查看一条记录，工具却返回了同部门全部数据；用户只是草拟邮件，Agent 却自动发送给外部收件人。这些问题本质上都属于授权范围扩大。
另一个典型风险是“混淆代理”。MCP 官方安全最佳实践中特别提到，代理服务器连接第三方 API 时，如果没有做好按客户端、按用户、按场景的授权和同意校验，可能出现 confused deputy 问题，相关说明可参考 MCP 安全最佳实践。这类问题的危险点在于：攻击者不一定直接突破系统，而是诱导一个有权限的中间组件替自己完成操作。
四、权限边界建模方法：从“工具清单”升级为“授权矩阵”
实用的做法是为 MCP 工具建立授权矩阵，而不是只维护一个工具列表。授权矩阵至少应包含：工具名称、业务用途、允许角色、资源范围、操作类型、参数约束、输出脱敏规则、是否需要二次确认、审计级别和默认状态。
一个安全原则是：MCP 工具默认不可用，只有在明确业务场景、明确调用主体、明确资源范围、明确风险控制后才开放。
例如，“search_documents”可以定义为低风险读取工具，但必须限制索引范围和返回字段；“update_ticket_status”属于中风险修改工具，应校验工单归属和状态流转规则；“send_email”“delete_file”“create_payment”等高风险工具，则应默认要求人工确认、强审计和最小化参数输入。
五、最小权限：把能力拆小，把范围收窄
最小权限在 MCP 中要落到三个层面。第一是工具最小化，不要把“文件管理”做成一个万能工具，而应拆成读取元数据、读取正文、创建草稿、移动文件、删除文件等细粒度能力。第二是数据最小化，工具只返回完成任务所需字段，避免把完整记录交给模型。第三是时间最小化，授权应支持短期有效、会话级有效和一次性确认。
OWASP 在大模型应用风险中将 “Excessive Agency” 列为重要类别，强调过度功能、过度权限或过度自主性会让被操控的模型执行破坏性动作，可参考 OWASP LLM Top 10 2025。这对 MCP 很有启发：不要让模型拥有超过任务所需的工具组合，更不要让它在无确认的情况下串联多个高风险动作。
六、越权防护的关键控制点
1. 调用前：强约束与显式授权
工具调用前应做策略判断，包括用户是否有权、当前任务是否需要、参数是否越界、资源是否属于授权范围。对于高风险操作，应向用户展示“将调用什么工具、影响哪些资源、会产生什么结果”，并要求明确确认。确认文案要可读，不应只显示技术参数。
2. 调用中：参数校验与上下文隔离
MCP Server 不应信任模型生成的参数。所有 resource_id、file_path、account_id、email_to、amount、query_filter 都必须在服务端重新校验。尤其要防止路径穿越、越租户查询、批量导出、隐式通配符和通过自然语言拼接 SQL 或 API 查询的情况。
3. 调用后：输出过滤与审计追踪
工具返回结果也需要执行安全处理。敏感字段应脱敏，超出用户权限的数据应过滤，异常结果不应原样返回给模型。审计日志应记录调用主体、工具名称、参数摘要、资源范围、决策结果、确认记录和返回规模，便于事后追踪。
七、推荐的防护架构
较稳妥的架构是在 AI Host 与 MCP Server 之间增加策略执行层，或者在 MCP Server 内部实现统一授权网关。所有工具调用都先进入策略引擎，由策略引擎结合用户身份、Agent 身份、工具风险、资源标签和上下文状态做决策。
- 身份绑定：每次调用都绑定用户、会话、应用和 MCP Client，禁止匿名高风险调用。
- 策略判定：使用 RBAC、ABAC 或 ReBAC 表达工具权限，支持按部门、项目、数据标签和任务状态授权。
- 风险分级：读取类、写入类、外发类、删除类、资金类工具采用不同审批强度。
- 人工介入：高影响操作采用 human-in-the-loop，模型只能建议，不能直接执行。
- 沙箱隔离：代码执行、文件处理、第三方插件应运行在隔离环境中，并限制网络、文件系统和凭据访问。
八、落地清单：团队可以马上开始做什么
- 梳理所有 MCP 工具，标注读、写、删、外发、执行代码等风险类型。
- 为每个工具补充权限矩阵，明确谁能用、何时能用、能访问哪些资源。
- 禁止 MCP Server 使用长期共享高权限密钥，优先采用短期令牌和按用户委托授权。
- 对高风险工具增加二次确认，并把确认内容设计成业务人员能理解的语言。
- 对工具入参做白名单校验，对输出做脱敏、截断和越权过滤。
- 建立审计日志和异常告警，重点关注批量导出、跨租户访问、频繁失败、非常规时间调用等行为。🔍
总结
MCP 的价值在于让 AI 能安全、标准化地连接工具；MCP 的风险也正来自这种连接能力。权限边界建模的目标，是把“模型想调用”变成“策略允许调用”，把“工具能做到”收敛为“当前用户、当前任务、当前资源范围内可以做到”。
真正可靠的越权防护，不是依赖提示词告诉模型“不要乱用工具”，而是通过身份绑定、最小权限、参数校验、输出过滤、人工确认、审计追踪和运行时隔离，构建一套可验证、可追责、可持续演进的安全体系。只有这样，MCP 才能从实验集成走向生产级可信调用。✅
