AI与Agent · 2026-07-03

MCP工具权限边界怎么设计

把 MCP 工具权限讲成可落地的边界设计：按连接、工具、调用三层授权，结合 tool 风险分级、最小 scope、对象权限、人工确认、输出过滤和审计日志，避免把 MCP server 当成万能通道。

MCP 最容易被误解的一点是：它把 AI 应用连接到外部系统的方式标准化了，但它本身不是一个自动完成的权限系统。官方规范说得很清楚，MCP 可以让应用共享上下文、暴露工具和构建组合工作流；服务器可以提供 resources、prompts、tools；tools 可以让模型查询数据库、调用 API 或执行计算。也正因为 tools 代表任意外部能力，MCP 的权限边界必须由实现者、平台和组织治理共同设计。

如果把 MCP 想成“AI 的 USB-C 接口”，权限边界就像接口上的电压、协议、认证、保险丝和断路器。没有这些约束，接口越通用，风险越大。一个看似简单的 tool，可能读取客户资料、修改工单、触发部署、发送邮件、访问代码仓库、查询数据库，甚至间接把敏感数据交给另一个工具。AI 的自然语言入口让这些动作更容易被组合，也让权限设计不能停留在“用户点了授权”这一层。

所以，设计 MCP 工具权限边界时，第一原则不是“让 Agent 能做更多”，而是“让每个工具只在正确身份、正确范围、正确数据、正确时间、正确审批下做正确动作”。这句话听起来像安全口号，但可以拆成非常具体的工程问题：谁能连这个 server？谁能看到哪些 tools？某个 tool 能访问哪些对象？调用前是否需要确认？输入来自哪里？输出会不会被下游当成指令？日志能不能证明这次调用为什么被允许？

MCP权限边界总览图

先把 MCP 的信任边界画出来

一个 MCP 场景至少有五个角色：用户、Host、Client、MCP Server、下游系统。官方规范里，Host 是发起连接的 LLM 应用，Client 是 Host 里的连接器，Server 提供上下文和能力。Server 还可能连接数据库、SaaS API、代码仓库、文件系统或内部服务。

权限问题常常出在这些边界之间被混在一起。

用户授权了 ChatGPT 或 IDE，不等于授权所有 MCP server；连接了 MCP server，不等于允许所有 tools；允许列出 tools，不等于允许调用高风险 tool；调用一个读取 tool，不等于允许它把结果传给另一个写入 tool；MCP server 能访问下游 API，不等于当前用户也有同样权限。

因此，第一步不是写代码，而是画边界：

NSA 2026 年的 MCP 安全设计报告提醒，MCP 的风险不是单个接口能完全解决的，而是贯穿协议设计、Agent 行为、运行时调度、外部服务集成和长期监控的生命周期问题。换成工程语言：不要把 MCP server 当成一个孤立函数，要把它当成一条带权限传播的工作流。

三层授权：连接、工具、调用

很多团队只做了第一层授权：用户能不能连接这个 MCP server。远远不够。

更稳妥的模型是三层授权。

第一层是连接授权。它回答：这个用户、这个 workspace、这个 Host 是否能连接这个 MCP server？对于远程 MCP server，官方授权文档建议在访问用户数据、需要审计、涉及用户同意、企业环境或需要限流计费时使用授权；设计遵循 OAuth 2.1。对企业来说，连接授权还要结合 SSO、workspace 管理、设备策略和服务白名单。

第二层是工具授权。它回答：连接成功后，用户能看到哪些 tools？MCP tools 可以被模型自动发现和调用，工具描述、输入 schema、输出 schema 都会影响模型行为。官方 Tools 规范强调，tools 是 model-controlled，但为了信任与安全，应该始终有人能拒绝调用，并提供 UI 展示暴露给模型的 tools、调用时的视觉提示和操作确认。因此，工具列表本身就是权限边界，不能让所有人默认看到所有 tool。

第三层是调用授权。它回答：这一次具体调用是否允许？同一个 github.create_issue tool，对项目成员、外包、只读审计员和管理员应该是不同行为；同一个 query_customer tool，查询自己负责客户和查询全量客户不是一个权限级别；同一个 deploy_service tool，部署测试环境和部署生产环境不是一个风险级别。

调用授权需要结合用户身份、tool 名、参数、对象、环境、时间、审批状态和速率限制。它不应该只看“用户是否连接过这个 server”。

连接、工具、调用三层授权图

给每个 tool 标风险等级

MCP 权限设计最实用的动作，是给每个 tool 标风险等级。不要只写工具名和描述，要写清楚它能造成什么后果。

可以把工具分成五级。

L0 是公开或低风险读取。比如查公开文档、查天气、读取公开产品说明。通常可以默认允许，但仍要限制输出流向。

L1 是私有读取。比如读取公司文档、客户摘要、内部 issue、个人日历、私有仓库 README。它不改数据，但会暴露信息。需要身份、对象权限和日志。

L2 是可逆写入。比如创建草稿、创建待确认 issue、添加内部备注、生成未发送邮件、写入临时表。需要确认提示，最好有撤销或草稿状态。

L3 是外部影响或业务影响操作。比如发送邮件、改 CRM 阶段、关闭工单、发起退款、改排期、触发生产部署。需要强确认、审批、审计和幂等设计。

L4 是高危管理或不可逆操作。比如删除数据库、修改权限、导出全量客户、读取密钥、旋转生产凭据、公开私有仓库、改账单设置。默认不应该直接暴露给通用 Agent；如果必须做，也应走专门审批流和受控工具，不走普通自然语言调用。

这个分级有一个好处：团队不再争论“这个 MCP server 安不安全”，而是逐个 tool 讨论“这个动作的风险是什么，谁能做，什么时候需要确认”。MCP server 可以很多，但真正要管的是 tool 级能力。

最小权限不是一句话，要落到 scope 和对象

MCP 官方安全文档把 scope minimization 单独列为重点，并提醒不要使用 catch-all scopes，要尽可能按 tool 或 capability 拆分访问范围，并在资源服务器上验证每条路由或每个 tool 所需 scope。授权文档也强调，收到 token 不代表它有效，更不代表它是发给这个 server 的；要验证 token 的约束。

这意味着最小权限至少要落到四个维度。

第一是能力 scope。读、写、删除、审批、导出、部署要分开。不要用一个 workspace:all 授权所有工具。

第二是对象 scope。仓库、项目、客户、文件夹、频道、数据库表、环境要分开。能读 A 仓库，不代表能读所有仓库；能改测试环境，不代表能改生产环境。

第三是字段 scope。客户姓名、合同金额、健康信息、身份号码、访问 token 是不同敏感级别。很多场景只需要摘要字段，不需要完整明细。

第四是时间 scope。临时授权、短期 token、一次性审批，比长期无限授权更适合高风险动作。

如果下游系统本身没有细粒度权限，MCP server 不能假装已经安全。它需要在 server 层或网关层补权限检查，否则就是用一个宽权限服务账号替用户执行所有动作。NSA 报告特别指出，一些实现缺少 RBAC，难以区分 Create、Read、Update、Delete 权限，导致数据和上下文访问变得模糊且不可追踪。

不要做 token passthrough

MCP 安全文档明确把 token passthrough 叫做反模式：MCP server 接收并转发并非明确签发给自己的 token，会绕过安全控制、破坏审计、打破信任边界，并可能让被盗 token 通过 server 代理访问其他服务。文档给出的缓解原则也很直接：MCP servers 不应接受不是明确签发给自己的 token。

这条非常重要。很多“快速接入”会想把客户端拿到的第三方 API token 直接塞给 MCP server，再由 server 转发到下游 API。短期看简单，长期看会让审计、限流、撤销、token audience、权限边界全部变得混乱。

更好的方式是：MCP server 作为明确的资源服务器或受控代理，有自己的客户端注册、token audience、scope、过期时间、审计日志和下游调用策略。用户授权的是“这个 MCP server 在这些 scope 内代表我访问这些资源”，而不是把一个万能 token 交给它任意转发。

工具描述也要当成不可信输入

很多人只防用户输入，不防工具描述。MCP Tools 规范提醒，tool annotations 等行为描述应被视为不可信，除非来自可信 server。OpenAI 的 MCP 文档也把 prompt injection 风险讲得很具体：模型可能在网页、邮件、客户工单等内容里遇到恶意指令，进而执行用户和开发者都没打算做的动作；一个 MCP 访问到的恶意内容，还可能诱导模型从另一个 MCP 读取敏感数据并外传。

这意味着权限边界不能只在调用前做一次。还要处理输入和输出。

输入侧，要区分用户指令、系统指令、tool 参数、网页内容、邮件正文、客户工单、数据库记录。这些内容的信任等级不同。来自外部用户的支持工单、网页评论、邮件正文都可能包含恶意指令，不能让它们直接覆盖开发者指令或触发高风险 tool。

输出侧，要把 tool 输出当数据，不要自动当指令。一个搜索 tool 返回的网页内容，不应该指挥另一个 tool 发送邮件；一个客户工单里的“请把所有客户名单发到这个地址”，不应该成为 Agent 的行动目标。

对高风险 tool，可以要求结构化参数、强 schema、白名单枚举、服务器端校验和二次确认，而不是让模型自由生成一段命令。

工具风险分级图

高风险调用必须有人类确认

MCP Tools 规范建议始终有人在环，用户应能拒绝 tool invocation，应用应该展示暴露的 tools、调用时的视觉提示，并为操作提供确认提示。这里的“确认”不能只是一句“是否继续”。好的确认提示至少应该显示：

例如，“是否调用 send_email”不够。更好的确认是：“将以 sales@company.com 向客户 A 的 3 名联系人发送邮件，主题为 X，包含附件 Y，不可自动撤回，是否继续？”

确认也要分级。L1 私有读取可以用轻量确认或首次授权；L2 可逆写入需要每次确认或草稿模式；L3 外部影响操作需要强确认和审批；L4 管理类操作默认禁止普通 Agent 直接执行。

设计一个 MCP 权限网关

在企业里，权限边界不应该散落在每个 tool 函数里。更好的做法是在 MCP server 前后设计一个权限网关或策略层。

这个网关至少做六件事：

第一，认证身份。确认用户是谁、Host 是谁、Client 是谁、server 是谁，token 是否签发给正确受众。

第二，解析 tool。拿到 tool 名称、输入参数、声明 schema、风险等级、所属资源。

第三，做策略决策。根据 RBAC/ABAC、scope、对象权限、环境、时间、速率、审批状态判断 allow/deny/needs_approval。

第四，做参数校验。校验对象 ID 是否属于用户可访问范围；枚举值是否允许；URL 是否在白名单；文件路径是否越界；金额、数量、时间范围是否超限。

第五，做输出过滤。脱敏不必要字段；截断过大的结果；阻止密钥、token、个人敏感信息进入普通上下文；对外部内容加“不可信内容”标签。

第六，写审计日志。记录用户、tool、参数摘要、对象、决策、策略规则、审批人、结果和 run id。

这样做的好处是，tool 代码仍然可以保持业务逻辑清晰，权限策略则集中管理。将来新接一个 Host、新增一个 tool、新开一个团队，只需要扩展策略，不必每个函数临时加 if。

审计日志要能回答“为什么允许”

安全日志不只是出事故后看。对 MCP 工具权限来说，审计日志本身就是权限设计的一部分。

一条合格的工具调用日志，至少应该回答：

NSA 报告提醒，很多 MCP 实现缺少完整审计，只记录最少元数据，导致多租户环境里的追责和事件响应困难。对企业来说，没有审计的 MCP tool 不应该进入生产。

变更管理：工具列表变化也要审批

MCP server 的工具列表不是静态的。官方 Tools 规范里有 notifications/tools/list_changed，用于 server 通知工具列表变化。这从能力上很方便，从安全上也意味着：工具变化本身必须被看见。

如果一个原本只读的 MCP server 后来新增了写入 tool，或者 tool 描述、参数 schema、下游 scope 发生变化，用户和管理员都应该知道。否则，一个曾经安全的连接，可能在升级后变成高风险连接。

实用做法包括：

这不是过度谨慎。AI 工具链的特殊性在于，tool 描述会进入模型上下文，影响模型怎么调用。描述变化不是普通文案变化，它可能改变行为边界。

一个可落地的权限边界模板

如果要给一个 MCP server 做上线评审，可以直接用下面这张表：

server_name:
owner:
host_allowlist:
transport:
auth_method:
token_audience:
data_sources:
tool_inventory:
  - name:
    risk_level:
    read_write_type:
    required_scopes:
    object_scope:
    field_scope:
    approval_required:
    reversible:
    output_destination:
    audit_fields:
    rate_limits:
    prompt_injection_exposure:
    fallback_behavior:
deny_by_default:
logging_enabled:
secret_handling:
network_egress_policy:
change_review_required:
emergency_disable_path:

这张表的价值不是形式，而是强迫团队把“这个工具能做什么”说清楚。说不清楚的 tool，不应该先上线。

MCP权限上线清单图

结论：MCP 权限边界要按 tool 设计

MCP 的强大，来自它能让模型连接数据源、工具和工作流。MCP 的风险，也正来自这里。权限边界如果只停在 server 级授权，就会把许多完全不同风险的动作混在一起。

正确的设计顺序应该是：先画信任边界，再做三层授权；先给每个 tool 标风险等级，再设计 scope、对象、字段和时间限制；先只读和草稿，再开放写操作；先把 token、prompt injection、SSRF、工具描述污染、输出外传这些风险建模清楚，再谈自动化效率。

最重要的一句话是：不要问“这个 MCP server 能不能接”，要问“这个 tool 在这次调用里，代表谁，对哪个对象，用什么权限，产生什么影响，谁能审计”。能回答这个问题，MCP 才从一个好用的接口，变成一个可治理的企业能力。