MCP为何重要？又该如何保障其安全？

最新推荐文章于 2025-12-12 14:04:07 发布

原创最新推荐文章于 2025-12-12 14:04:07 发布 · 779 阅读

21 ·

CC 4.0 BY-SA版权

文章标签：

#安全 #人工智能 #深度学习

作为一种通用协议，MCP能够将智能体应用与现实世界的数据和工具连通，成功解决上述局限。但既然我们已经拥有一众安全且高性能的API，那为什么还要引入新的协议？

译者 | 核子可乐

审校 | 重楼

每种新协议都会带来相应的复杂性，因此若无必要、勿增新协议。但模型上下文协议（MCP）无疑很有必要。

ChatGPT等AI工具已然掀起一波智能体应用浪潮，这些由大模型驱动的智能体擅长摘要、内容创作与图像处理，但也存在一些根本性的局限：

无法访问实时数据；
无法访问私有数据；
无法使用工具。

答案并不复杂，虽然各类强大的API能够接入智能体应用，但由于自身种类繁多、身份验证机制又各不相同，意味着每次集成都存在大量定制化成分。开发者必须逐一阅读文档、构建流程才能接入API。

WSO2

这种静态集成模型虽然成熟，但与智能体应用的动态特性并不匹配。MCP定义了清晰的客户端-服务器角色、标准协议格式和生命周期，本质上成为大模型与外部系统间的通用连接器，因此不少从业者将MCP视为API领域的USB端口。

MCP工作原理

MCP定义了三大核心角色——主机、客户端与服务器：

主机：管理客户端生命周期，并具备强制安全保障的智能体应用。
客户端：主机内的轻量级连接器，用于同MCP服务器建立一对一会话。
服务器：将MCP客户端连接至本地或远程数据源及工具的程序。

WSO2

各角色提供相应的功能。MCP服务器负责公开资源（如日历事件等上下文数据）、提示词（用于引导用户输入以改进大模型输出的结构化模板）及工具（可执行函数）。MCP客户端则接入MCP服务器以请求数据、操作工具并编排智能体。

MCP使用JSON-RPG（一种轻量级结构化协议）以处理请求及响应，并定义了两种用于客户端-服务器通信的标准传输机制：标准输入输出（STDIO）及可流式传输的HTTP。

保护本地MCP服务器

当MCP服务器运行在本地时，应使用STDIO传输。实际上，这意味着智能体应用将MCP服务器作为子进程启动，并通过其标准输入输出流进行通信。由于此通信完全在本地系统内进行，因此本质上符合安全原理且MCP身份验证规范无需借助额外安全措施。

WSO2

然而，当MCP服务器与后端API通信（大多通过互联网）时，安全性要求成为首要任务、并超出了MCP身份验证机制的范畴。尽管如此，这里仍不需要引入新机制：现有API安全实践已经足以提供保障，常见方法包括：

长效令牌：有效期为数天或数月的API密钥及令牌，通过带外通道获取并在MCP服务器中配置。
短效令牌：短效信息的有效期在一小时以内，无法手动设置。相反，MCP服务器必须在运行时动态请求并获得用户批准。典型例子包括OAuth2访问令牌及JWT。

保护远程MCP服务器

MCP客户端通过向其端点URL发起请求，通过HTTP接入远程MCP服务器。根据MCP身份验证规范的规定，此端点必须受到OAuth 2.1保护，并要求客户端提供有效访问令牌。

WSO2

MCP身份验证规范概述了令牌的获取流程，旨在支持动态智能体集成。具体交互包括以下步骤：

WSO2

服务器元数据发现

在为MCP服务器提供URL配置参数之后，客户端会移除所有路径组件并附加/well-known/oauth-authorization-server路径以构建服务器元数据端点。之后，客户端从此端点处检索JSON格式的服务器元数据文档。端点及文档都必须符合OAuth 2.0授权服务器元数据规范，且此元数据可帮助客户端在后续步骤中发现以下所需信息：

注册端点；
授权与令牌端点；
支持的授权类型与范围。

从MCP服务器URL获取服务器元数据端点的初衷，是让客户端使用单一配置参数进行操作。但这样的设计会令授权与资源服务器角色紧密耦合，限制了现有OAuth 2.0基础设施与专用身份解决方案的使用。为了解决这个问题，即将发布的MCP身份验证规范将转而采用OAuth 2.0受保护资源元数据规范。

客户端注册

根据从服务器元数据文档中检索到的信息，客户端应用向客户端注册端点发送注册请求。MCP身份验证规范采用OAuth 2.0动态客户端注册（DCR）协议将客户端注册为OAuth 2.1客户端。在DCR响应中，客户端应用会收到一个client_id；对于机密客户端，还会收到一个client_secret。这两项参数将在下一步操作中用到。

尽管DCR得到广泛采用，但人们对于开放注册的评判并不一致，而且该规范本身允许使用OAuth 2.0保护注册端点。同样，为了支持单参数配置，MCP身份验证规范建议采用开放注册，未来如何发展仍有待观察。

访问令牌检索

在此阶段，客户端已经做好了请求访问令牌的所有准备。根据用例，客户端将使用以下OAuth 2.1授权类型之一：

客户端凭证：若客户端应用直接访问MCP服务器，则使用客户端凭证授权，其中包含注册期间获得的client_id与client_secret，以及从服务器元数据中发现的令牌端点及范围。
授权码：若客户端代表最终用户访问MCP服务器，则使用授权码授权。此流程需要注册时获取的client_id与client_secret，以及从服务器元数据中获取的授权端点、令牌端点及范围。此外，根据OAuth 2.1的要求，客户端必须使用码交换证明密钥（PKCE）以进一步增强安全性。