导语：MCP 让 AI 应用可以像调用插件一样访问外部工具、数据源和业务系统，但工具调用一旦涉及数据库、工单、代码仓库、云资源或内部 API，鉴权凭证如何传递就会成为核心安全问题。🔐 如果把 MCP 服务器当成“万能中转站”，很容易出现令牌滥用、权限过大、审计困难和越权调用等风险。
一、先理解 MCP 工具调用中的身份边界
MCP 的典型结构包含 Host、Client 和 Server：Host 是承载 AI 的应用，Client 负责与 MCP Server 建立连接，Server 则向 AI 暴露工具、资源或提示模板。官方规范将 MCP 定义为一种连接 LLM 应用与外部数据源、工具的开放协议，工具调用本质上是在 AI 推理链路中引入了外部执行能力，相关安全原则可参考 来源链接 官方文档。
在这个链路中，最关键的问题是：AI 不是最终权限主体，用户、客户端、MCP Server、后端资源服务器才是实际的安全边界。也就是说，工具调用不能因为“模型需要”就默认拥有全部权限，而应明确回答三个问题：谁在请求、请求什么、凭什么可以请求。
二、鉴权凭证不要在链路中“裸奔” 🚦
在 MCP 工具调用中，凭证可能包括 OAuth access token、API Key、Session Cookie、云服务临时密钥或内部系统访问令牌。最佳实践是避免让模型直接看到、拼接或转发这些凭证。凭证应由受控组件管理，例如 MCP Client、MCP Server 或企业网关，而不是暴露在 Prompt、工具参数或日志文本中。
对于基于 HTTP 的 MCP 传输，官方授权规范说明 MCP 可在传输层提供授权能力，使客户端代表资源所有者访问受限 MCP Server；当实现支持授权时，HTTP 传输应遵循相关授权规范，STDIO 传输则不应套用该 HTTP 授权流程，而应从环境中获取凭证，详见 MCP Authorization Specification。
三、优先使用短期、范围明确的访问令牌
凭证传递的基本原则是“短期有效、用途单一、可撤销、可审计”。如果一个工具只需要读取某个项目的 Issue，就不应拿到整个代码平台的管理员令牌；如果一次调用只需要查询订单状态，就不应授予修改订单、退款或导出用户数据的权限。
在 OAuth 场景下，应优先使用 access token，并通过 scope、audience、resource 等机制限制令牌可访问的资源。MCP 授权规范提到其机制参考了 OAuth 2.1、Bearer Token、授权服务器元数据、受保护资源元数据和资源指示符等标准，目的正是提升安全性与互操作性，可参考 官方授权说明。
四、最小权限不是口号，而是工具设计方式
很多 MCP 安全问题并不是出在协议本身，而是出在工具设计过粗。例如，一个名为 run_sql 的工具如果允许模型提交任意 SQL，那么它天然比 get_customer_order_status 更危险。前者把权限边界交给了模型判断，后者把能力收敛在明确业务动作内。
- 工具粒度要小：优先提供面向任务的工具，而不是万能执行器。
- 参数要受限：使用枚举、白名单、长度限制和格式校验，避免任意命令、任意路径、任意 URL。
- 权限要分层：读取、写入、删除、审批、转账等动作应拆分授权。
- 高风险操作要二次确认：涉及资金、权限变更、数据删除、外部发送等动作，应要求用户确认。
五、防止“令牌透传”变成权限放大器 ⚠️
令牌透传看似省事：客户端拿到用户 token，然后原样传给下游系统。但在 MCP 场景下，这可能导致 MCP Server 获得过宽权限，甚至把一个原本只该调用单个工具的会话，扩大成可访问多个后端系统的高权限通道。
更稳妥的做法是使用令牌交换或代理授权：MCP Server 不直接拿用户的全量凭证，而是换取一个仅面向特定资源、特定工具、特定时间窗口的下游令牌。这样即使某个工具被误调用或某段链路泄露，攻击面也会被限制在较小范围内。
六、关注“混淆代理”与用户同意
MCP 官方安全最佳实践特别提到混淆代理问题：当 MCP 代理服务器连接第三方 API，并在静态 client_id、动态客户端注册、第三方授权同意 Cookie 等条件组合下处理不当时，恶意客户端可能绕过正确的用户同意流程获取授权码，相关说明见 MCP Security Best Practices。
应对这类风险，不能只依赖“用户之前同意过”。MCP Server 需要区分不同 MCP Client、不同用户、不同目标资源和不同工具动作。对外部 API 的授权跳转、回调处理和 consent 记录，应绑定具体客户端与会话上下文，避免一个客户端的同意被另一个客户端复用。
七、日志、审计与脱敏同样重要 🧾
安全不是只看调用前的授权，也要看调用后的可追溯性。每次 MCP 工具调用建议记录用户标识、客户端标识、工具名称、授权范围、目标资源、调用结果、风险等级和请求时间。但日志中不应记录完整 token、API Key、Cookie、身份证号、银行卡号或完整个人敏感信息。
审计日志还应能回答：某个工具为什么被调用、调用前是否有用户确认、使用了哪个权限范围、是否访问了超出预期的数据。对于企业系统，可将 MCP 工具调用接入 SIEM、告警平台或统一审计中心，对异常频率、异常资源、跨租户访问和高风险动作进行监控。
八、落地清单：从开发到上线逐项检查
- 凭证存储：使用密钥管理服务或安全环境变量，禁止写入 Prompt、前端代码和普通日志。
- 凭证传递：优先传递短期 token，不传递长期主密钥。
- 权限范围：为每个工具定义最小 scope，不共用管理员权限。
- 工具边界：避免万能命令、万能 SQL、万能 HTTP 请求工具。
- 用户同意：高风险操作显示清晰说明，并保留确认记录。
- 输入校验：对路径、URL、ID、金额、邮箱、SQL 条件等做白名单或结构化校验。
- 输出控制：避免把敏感字段完整返回给模型，必要时做字段级脱敏。
- 审计告警：记录调用链路，监控异常调用和权限失败事件。
一个实用判断标准：如果某个 MCP 工具被提示注入诱导后可能造成真实业务损失，那么它就不应该只依赖模型“自觉遵守规则”，而应在服务端做强制权限控制。
总结
MCP 的价值在于让 AI 更容易接入真实业务系统，但也正因为它连接了真实权限、真实数据和真实操作，鉴权凭证传递必须被严肃设计。安全的 MCP 实践不是把 token 随手传给工具，而是通过标准授权流程、短期令牌、资源限定、最小权限、用户同意、服务端校验和完整审计，把每一次工具调用都控制在可理解、可授权、可追踪的范围内。✅
