Cloudflare 识别并保护 MCP 流量
Cloudflare AI··作者 Kenny Johnson
关键信息
Cloudflare 解释说，MCP 流量之所以难以识别，是因为它不要求固定主机名，也不要求使用特殊的 /mcp 路径，所以外观看起来可能像普通的 HTTPS API 调用。文章指出，Cloudflare Gateway 会利用协议信号，比如 MCP-Protocol-Version、Mcp-Method 和 Mcp-Name 这些头部，来分类经过检查的请求，并强制只允许通过 Portal 访问受信任的 MCP 服务器。
资讯摘要
Cloudflare 认为，许多企业权限体系原本是围绕人类用户设计的，而人类会受判断力和操作速度限制。AI 代理改变了这个假设，因为它们可以不停重复同样的动作，不会疲劳，因此一次错误判断可能在被发现之前就演变成成千上万次错误操作。为此，Cloudflare 为 Cloudflare One 增加了新能力，可以识别经过检查的 MCP 流量，展示这些流量由哪些用户和服务器生成，并控制受管网络路径上的直接连接。公司表示，这些控制与 MCP Server Portals 配合后，可以帮助管理员判断代理是否走的是批准路径，还是绕过了这些路径。文章把 MCP，也就是 Model Context Protocol，描述为代理发现并调用工具的一种通用方式，这些工具可以来自 SaaS 产品、内部应用和 API。
文章还指出，员工只需很少的配置，就能把 Claude Code、Codex、Cursor、OpenCode 或 VS Code 等工具接到 MCP 服务器上。Cloudflare 强调，MCP 流量很难识别，因为该协议不要求唯一的主机名，也不要求使用 /mcp 路径，所以它看起来可能只是普通的 HTTPS 请求。文章随后解释了一个 MCP 工具调用在客户端、网络和服务器端分别是什么样子，并指出最敏感的部分是发给工具的参数。这些参数可能包含查询、源代码、客户数据，或者创建工单、修改基础设施之类的指令。Cloudflare 表示，Gateway 可以利用协议信号发现影子 MCP 流量，并对受信任的 MCP 服务器强制实施基于 Portal 的访问边界。
资讯正文
大多数公司在设计资源权限时，考虑的都是人类用户。高级工程师可能有权限将代码部署到生产环境、查询敏感数据库，或者撤销其他用户的访问权限。这些特权伴随着风险，但传统上，这种风险一直受两个假设所限制：工程师会运用人的判断力，而且工程师只能以人的速度行事。
一名看到意外结果的工程师通常会停下来，重新考虑自己的操作。任何人一天之内都只能点击、输入和审阅有限的内容。AI 智能体的出现改变了这两个阈值。它们的决策是非确定性的，而且可以无限次执行同样的操作（或调用同样的工具），不会疲倦，也不会因为吃午饭而停下。一个看似合理、但实际上错误的决定，可能在被人类注意到之前，就已经演变成成千上万次错误操作。
今天，我们宣布了新的 Cloudflare One 能力，用于识别经过检测的 MCP 流量，显示是哪些用户和服务器在生成这些流量，并在受管网络路径上控制直连。与 MCP Server Portals 结合后，这些控制措施可以帮助管理员判断智能体是否在使用被批准的路径，还是在以某种方式绕过它。
Model Context Protocol（MCP）服务器为智能体提供了一种通用方式，用来发现并调用由第三方 SaaS 产品、内部应用和 API 支持的工具。底层权限大概率是熟悉的；真正改变的是由谁来做每个决定，以及一个错误决定传播得有多快。
将智能体连接到这些工具中的任意一个，可能只需要一行配置。员工可以把 Claude Code、Codex、Cursor、OpenCode、VS Code，或者任何 AI 运行环境指向某个 MCP 服务器，而无需检查它是否经过批准。由此产生的流量没有明显特征。Model Context Protocol 不使用固定主机名，也不要求路径中包含 /mcp，因此一次直连看起来可能就像其他任何 HTTPS API 调用一样。
为了解释这些控制如何协同工作，我们先从一次工具调用的结构以及它暴露的信息开始。然后我们会比较安全团队可以采取行动的三个位置：客户端内部、网络层，以及 MCP 服务器端。接下来，我们将展示 Cloudflare Gateway 如何利用协议信号来发现影子 MCP 流量，并强制只能通过 MCP Portal 访问受信任的 MCP 服务器。
MCP 工具调用的结构
同一次 MCP 工具调用在系统中流转时，会呈现三种形态。在客户端内部，它是一次使用一组参数调用工具的决定。在网络上，它是一个承载 JSON-RPC 消息的 HTTP 事务。在服务器端，它会变成对工具处理程序的一次调用，后者可能读取数据、修改状态，或完成其他某种操作。
设想一个智能体想知道奥斯汀的天气。一个远程 MCP 请求可能看起来像这样：
POST /mcp HTTP/1.1
Host: tools.example.com
Authorization: Bearer <access-token>
Content-Type: application/json
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: get_weather
{
"jsonrpc": "2.0",
"id": 42,
"method": "tools/call",
"params": {
"name": "get_weather",
"arguments": {
"city": "Austin"
}
这个请求中包含了几个有用的信号。主机名和路径标识了目标地址。authorization 头携带了在服务器需要时用于认证调用方的凭据。MCP-Protocol-Version 头标识协议版本，而 Mcp-Method 和 Mcp-Name 在这种新的无状态协议中公开了操作和工具。JSON-RPC 信封重复了 method，为请求提供了一个客户端可以与响应匹配的 id，并在 params 中携带工具参数。
参数是最敏感的部分。它们可能包含搜索查询、源代码、客户数据，或用于某项操作的指令，例如创建工单或更改基础设施。工具名称说明代理打算调用什么；参数则说明它会发送哪些数据，以及它希望服务器执行什么操作。
如果调用成功，服务器会返回一个 JSON-RPC 响应，其中包含相同的 id 和工具结果。该响应也可能包含敏感数据。请求检查可以在执行前阻止不安全操作，而响应检查和日志记录则显示工具向代理返回了什么。
控制 MCP 请求的三个位置
该请求为安全团队提供了三个可以观察或控制调用的位置。
在 MCP 客户端内部
在模型选择工具之后、客户端序列化请求之前，可以运行一个客户端钩子。从那里，它可以在不解密网络流量的情况下看到目标服务器、工具名称和参数。
这是在请求链中施加控制的最早阶段。客户端可以拒绝不在允许列表中的服务器，要求用户确认敏感操作，或在数据离开设备之前从参数中移除数据。它还可以覆盖本地 stdio（即本地）MCP 服务器，这类服务器不会产生任何网络流量。
这带来了标准化挑战。为了让安全团队从中受益，他们需要在员工使用的每一个客户端上复现这些控制。只有当组织同时管理客户端和设备时，客户端侧控制才最有效，但来自某一个客户端的遥测从来都不是 MCP 使用情况的完整清单。
在设备的网络边界上
安全 Web 网关可以在 HTTP 请求离开客户端后对其进行观察。借助 TLS 解密，它可以将请求关联到用户和设备，检查目标和协议头，并在不依赖特定 MCP 客户端的情况下应用策略。
网络层拥有最广的视角，可以在受管路径上检测远程 MCP 流量。它可以识别到已批准 Portal 之外的服务器的直接连接，并在请求到达目标之前将其阻止。在支持数据丢失防护扫描的地方，代理还可以检查 JSON-RPC method 和参数中的敏感数据。不过，代理无法看到本地 stdio 调用或非网络流量。
在 MCP 服务器调用工具之前
服务器拥有最丰富的执行上下文。它已经对调用方完成了身份验证，解析了 MCP 消息，将 get_weather 解析到一个处理程序，并根据工具的输入模式验证了所提供的参数。这是请求在工具运行之前仍可被拒绝的最后一个节点。
Agents SDK 的处理程序或类似的服务器中间件可以针对特定工具对调用方进行授权、应用速率限制、检查参数并记录结果。服务器应当在调用处理程序之前执行这些检查，尤其是对于会写入数据或触发外部操作的工具。仅在执行后记录日志可以解释发生了什么，但无法阻止它发生。
Cloudflare 的 WriteGuard 在我们的内部 MCP 服务器上采用了这种模式。每个工具都有一个风险等级以及启用或禁用状态。WriteGuard 可以让只读请求直接通过，为允许的写操作添加 agent 归因和审计事件，或者在其处理程序运行之前阻止一项关键操作。由于控制措施位于服务器端，最终用户无法通过切换客户端或禁用本地钩子来绕过它。
虽然服务器端控制只能保护那些实现了它们的服务器，但客户端和服务器拥有最好的请求深度。网络看到的是最广泛的远程连接集合。将这些控制结合起来使用，可以在敏感数据离开设备之前将其拦截，发现未受管理的 MCP 流量，并在工具执行之前拒绝未授权操作。
网络控制点拥有最广泛的覆盖范围，但它首先必须将 MCP 与普通 HTTPS 流量区分开来，用户必须正在运行代理，而且 MCP Server（或 Portal）必须验证连接中确实使用了该代理。
Cloudflare One 提供了这条链路中的网络组件。Cloudflare One Client 会将来自受管设备的流量通过 Gateway 发送。Gateway 可以在协议层对 MCP 请求进行分类，并区分流量是由 MCP Portal 发起，还是在绕过已批准的控制措施。管理员随后可以对不遵循批准路径的连接进行报告或阻止。这个过程首先要可靠地识别请求。
URL 并不能告诉你某个请求使用了 MCP
我们最初寻找 MCP 流量的方法，是使用 GraphQL Analytics API 在 Gateway 的 HTTP 日志中搜索主机名里包含 mcp 的条目，以及 /mcp 或 /sse 之类的常见路径。我们的 MCP 流量检测教程中包含了这条查询。它还解释了如何为 MCP 的 JSON-RPC 方法（如 initialize、tools/call 和 resources/read）在请求体中创建数据泄露防护模式。
这些信号对于发现来自旧版客户端的流量以及提供历史可见性仍然有用，但它们非常基础。它们会漏掉位于普通 URL 的 MCP 服务器，比如 https://tools.example.com/api，而这并不少见。
而且，它们也可能匹配到一个碰巧在主机名或路径中使用了 mcp 的无关服务（虽然不太可能，但我们确实见过）。对于符合规范的 Streamable HTTP 客户端来说，协议头是更具体的信号。MCP 2025-11-25 规范指出，客户端在初始化之后的每个 HTTP 请求中都必须包含 MCP-Protocol-Version。MCP 2026-07-28 规范更进一步，要求在每个 POST 请求中都包含它。
这并不意味着这个头部字段就是一个完整的检测器。来自旧版客户端的初始请求可能不包含它，2025-06-18 之前的协议版本并未定义它，而本地 stdio、自定义传输或不合规流量也可能永远不会携带它。它的存在是 MCP 的一个强阳性信号；但它的缺失并不能证明某个请求不是 MCP。
该协议在网络上变得更容易识别了
传统的 MCP 流程始于一个不包含 MCP-Protocol-Version HTTP 头部的 initialize 请求，因此网络控制仅凭头部信息，可能无法将发往此前未知端点的首个请求归类为 MCP。该信号会在客户端和服务器完成初始化之后出现。
后续的工具调用看起来是这样的：
POST /api HTTP/1.1
MCP-Protocol-Version: 2025-11-25
{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"get_weather"}}MCP 2026-07-28 规范对这一模型做了很大改变。核心协议是无状态的；它彻底移除了 initialize 握手，并将协议版本和操作放到每一次请求中：
{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"get_weather"}}Mcp-Method 和 Mcp-Name 头部让普通的 HTTP 基础设施无需解析正文即可识别操作。负载均衡器可以据此路由请求，限流器可以将 tools/list 与 tools/call 分开，而安全产品则能在每一次请求中获得更多信息。
这些协议信号让 Cloudflare Gateway 能够评估一些具体内容，而不必依赖一份看起来像 MCP 的 URL 列表。
Shadow MCP 和已批准路径绕过是两个不同的问题
一旦 Gateway 能识别 MCP 流量，你就可以进一步评估某个连接对你的安全态势意味着什么。
Shadow MCP 指的是连接到组织未批准的服务器。员工可能会在代码仓库、产品指南或同事发来的消息中找到该服务器，并直接把它添加到自己的 MCP 客户端里。安全团队并不知道它暴露了哪些工具，也不知道员工向它发送了什么数据。
Portal 绕过则不同：它起点是组织已经放入 MCP Portal 的一个已批准服务器，但员工却直接连接其上游 URL，跳过了 Portal 的 Access policy、整理过的工具目录、数据丢失防护以及工具级审计轨迹。
对于受管网络路径上的 shadow MCP，Gateway 是主要控制点；它可以识别经过 TLS 检查的 MCP 流量，显示目的地和用户，并应用策略。Portal 绕过则需要这种网络控制，再加上一个能够拒绝直接请求的源站，这可以是 Access policy、源 IP 限制，或者由 MCP 服务器自身发起的企业授权机制。
在 Gateway 中检测 MCP 流量
对于已经在 TLS 检查下采用 Cloudflare Gateway 的客户，我们正在加入一种检测启发式方法，用来回答每一条经过检查的请求所对应的一个简单问题：这是不是 MCP 流量？
对于基于会话的 Streamable HTTP 连接，MCP 客户端会在初始化后发送一个 MCP-Protocol-Version 标头。Gateway 会在每个经过 TLS 检查的请求上检查该标头，并据此对流量进行分类；这一检测基于我们对每天穿过 Cloudflare 网络的数百万个请求中观察到的模式构建而成。该分类能够识别 MCP 的协商和对某个主机名的代理，而无需事先知道具体的主机或 URL。
从今天开始，所有 Cloudflare Zero Trust 客户都能在其 Gateway HTTP 日志中看到 MCP 流量的指示，并且可以使用一个新的 Gateway 选择器明确阻止或允许这类流量：
experimental.is_mcp == true
该选择器是一个布尔值。如果 Gateway 在一个经过 TLS 检查的请求中检测到 MCP-Protocol-Version 标头，其值就是 true，管理员无需维护自己的 MCP 外观域名列表，就可以在 Allow 或 Block 策略中使用它。
直接的加密流量必须先经过 TLS 解密，Gateway 才能检查这些标头；而本地 stdio 服务器、网外连接、Do Not Inspect 流量，以及那些根本不会经过 Gateway 的请求，都会被排除在这一视图之外。
跨整个网络查看 MCP 流量
今天，我们推出了一个专门的 MCP 流量仪表板，用来显示网络中哪些主机正在提供 MCP 流量、哪些用户正在生成这些流量，以及请求是通过你的 Cloudflare MCP Portals 还是完全绕过它们。
该仪表板显示：
- 在可配置的时间窗口内的 MCP 请求总数、唯一用户数和唯一服务器数
- 随时间变化的 MCP 服务器及每台服务器的请求计数
- 按 on-ramp 划分的流量分布，区分 MCP Portal 流量与直接设备客户端连接
- 在你的 Portals 之外发现的、流量最多的 MCP 服务器，也就是最值得关注的 shadow MCP 流量
- 按 MCP 请求量排序的顶级用户
管理员可以按特定服务器、用户或 on-ramp 类型进行筛选，并直接跳转到按相关主机或用户过滤后的 Gateway HTTP 日志，以便进一步调查。
将已发现的服务器纳入 MCP Portal
MCP 发现会把未知流量变成管理员可以调查的列表。当某个组织批准了其中一台服务器后，就可以把该服务器放到 Cloudflare MCP server portal 之后。Portal 会为员工提供一个受管理的端点，并在上游服务器前加入 Access 身份、精心策划的工具目录和日志记录。管理员可以通过 Gateway 将兼容的上游调用路由过去，以实施 HTTP 策略、获得可预测的出口流量并进行数据泄露防护，无论是在 Portal 内部，还是针对单个服务器。工具活动也可以通过 Logpush 导出。随后，发现仪表板就能区分通过 Portal 的请求与直接连接到同一服务器的请求。
这就形成了一条从发现到治理的路径：找到服务器，决定是否批准，把已批准的使用迁移到 Portal 后面，并调查那些仍然绕过它的流量。最后这一步很重要，因为未批准的服务器和绕过已批准服务器是两类不同的问题。
强制仅通过 Portal 访问
我们正在为 Gateway 网络和 HTTP 策略新增 Traffic Source 选择器，以便让管理员能够更精细地编写规则，根据流量是否来自你的 MCP Portals 来控制 MCP 流量。
当 MCP Portal 流量经由 Gateway 路由时，它会带有 mcp_portal Traffic Source，这使得策略可以区分经由 Portal 代理的请求和员工的直接连接。一个基础的强制执行规则如下：
experimental.is_mcp == true and not traffic.onramp in ("mcp_portal")
Action: BlockAny 未通过 Portal 到达的、检测到的 MCP 流量都会被阻止；通过 Portal 到达的流量不受影响。对于希望先观察再强制执行的组织来说，Traffic Source 和 MCP 检测现在已经出现在已解密流量的 HTTP 日志中，因此你可以在无需制定策略的情况下监控经由代理的流量行为。
更多 MCP 服务器现在可以使用受管路径
只有当一条获准路径能够连接到员工实际需要的大量服务器时，它才真正有用。
早期的 MCP 规范建议使用 Dynamic Client Registration，即客户端在没有 OAuth 应用的情况下向授权服务器自行注册。许多常见的 OAuth 提供商采用不同的模型：它们要求管理员注册一个具有固定 client ID、client secret、callback URL 和一组 scopes 的应用。MCP 2026-07-28 最近也废弃了 dynamic registration。
为缓解这一问题，MCP Portals 现在支持预注册的 OAuth 客户端。管理员可以配置手动 OAuth 凭证，将仪表板中显示的 callback URL 在上游提供商处完成注册，并输入客户端凭证。Portal 会在可用时发现标准的 OAuth 元数据；如果无法进行发现，管理员可以手动提供 authorization、token、revocation 和 issuer 端点。
每个用户仍然是在为自己上游的数据源授权访问，而存储的 client secret 只用于获取更新后的 tool 和 prompt 列表。
现在，手动 OAuth 支持有助于覆盖 OAuth 实现的诸多变化组合。有些提供商要求自定义 headers、personal access tokens，或者显式的 client allowlist，而这些属于不同的兼容性问题。未来几个月，我们将继续扩展 MCP portals 的 OAuth 支持。
将私有 MCP 服务器纳入同一个 Portal
公共 SaaS 工具只是企业 MCP 目录的一部分。企业所依赖的大多数关键敏感信息并不在公共互联网中可用；它们存在于公有或私有云基础设施中，或者托管在本地（on-premise），并且只能通过连接到私有网络来访问。
如今，MCP Portal 必须能够通过公共互联网解析并访问上游服务器。这意味着那些只在私有网络中可用的服务器——无论是通过私有 DNS，还是位于私有 IP 空间内——都无法被 Portals 访问。我们正在努力让 MCP Portals 能够通过 Cloudflare Gateway 路由以及已经用于其他私有应用的同一 Cloudflare One 网络连接到私有服务器。
私有服务器会保留其私有主机名；Portal 通过 Cloudflare 的私有路由访问它，并在公共上游服务器旁边展示其工具；而 Access 策略、Portal 日志记录和工具控制仍然会在同一个入口处继续生效。
将 Portal 流量通过 Gateway 转发，还会为其打上 mcp_portal Traffic Source 标记，因此 Gateway 策略可以区分来自 Portal 的请求和员工直接连接。MCP 服务器的私有连接能力正在积极开发中；请关注 Changelog 以获取更多信息。
Agents SDK 支持新的无状态模型
几周前，MCP 项目发布了 2026-07-28 规范，这是一次重大修订，用无状态、按请求的模型取代了基于连接范围的初始化。我们在《MCP 的下一代》中介绍了这一协议变化和迁移路径。
Cloudflare Agents SDK v0.20.0 既作为客户端也作为服务器支持 MCP 2026-07-28。对于每个连接，客户端会先通过 server/discover 探测新的无状态协议；如果服务器不支持，它就会在同一连接上继续使用旧版的 initialize 握手。现有的 addMcpServer 调用不需要单独的协议设置或单独的客户端。
在服务器端，createMcpHandler 可以从 Worker 中提供无状态工具、prompts、resources 和 elicitation，而无需创建传输会话或 Durable Object：
import { McpServer } from "@modelcontextprotocol/server";
import { createMcpHandler } from "agents/mcp/server";
function createServer() {
return new McpServer({ name: "example", version: "1.0.0" });
export default {
fetch(request, env, ctx) {
return createMcpHandler(createServer)(request, env, ctx);
},
} satisfies ExportedHandler;回退机制之所以重要，是因为协议迁移很少会一次性完成。新的客户端仍然需要连接到现有服务器，而新的服务器也仍然需要处理那些尚未迁移的客户端。Agents SDK 在生态系统过渡期间同时支持这两条路径。
先建立可见性，再关闭不应存在的路径
一个可行的 MCP 安全计划，应当从理解用户的流量特征、MCP 使用情况开始，并就一套经批准的工具和访问方法达成一致。
首先，检查穿过 Gateway 的 MCP 流量，并将其目的地与贵组织已批准的服务器进行比较。把更多已批准的服务器迁移到 MCP Portals 后面。
然后，落实你能够控制的边界。组合使用 Gateway 策略，将 MCP 检测条件与 Traffic Source 和 Destination 条件结合起来，阻止受管设备和站点发起直接 MCP 连接，并在可能的情况下将自托管上游服务器限制为仅接受 Portal 流量。
我们很快还会为 MCP 流量的可见性和控制添加更细粒度的功能，包括对特定工具使用的控制，以及针对你环境中所有 MCP 服务器的工具使用情况提供新的报告——无论这些服务器是否已被你的安全团队知晓。
我们的 MCP 流量检测教程涵盖了当前 Gateway 日志可用的主机名、路径和 JSON-RPC 启发式规则。随着这一新信号进入全面可用阶段，我们将用协议选择器的详细信息更新文档。
来源与参考
收录于 2026-08-15