How Cloudflare detects MCP traffic and helps secure it

Cloudflare如何检测MCP流量并帮助保护它 | Cloudflare博客

post

产品动态

SASE

零信任

AI

Cloudflare One

MCP

2026年8月14日

Cloudflare如何检测MCP流量并帮助保护它

AJ Gerstenhaber 和 Kenny Johnson

17分钟阅读时间

复制链接

大多数公司设计资源权限时都以人类用户为中心。高级工程师可能能够部署到生产环境、查询敏感数据库或撤销其他用户的访问权限。这些权限伴随着风险，但传统上这种风险受到两个假设的限制：工程师将使用人类判断，且工程师只能以人类的速度行动。

当工程师看到意外结果时，通常会停下来重新考虑自己的操作。任何人类每天只能点击、输入和审查有限的内容。AI代理的引入改变了这两个阈值。它们的决策是非确定性的，可以无限次执行相同的操作（或调用相同的工具），而不会感到疲劳或停下来吃午饭。一个看似合理但错误的决策可能在人类注意到之前就演变为数千次错误操作。

今天，我们宣布Cloudflare One新增功能，用于识别经过检查的MCP流量，显示哪些用户和服务器正在生成该流量，并控制托管网络路径上的直接连接。结合MCP服务器门户，这些控制措施帮助管理员查看代理是否使用了批准的路径，或者是否以某种方式绕过了该路径。

模型上下文协议（MCP）服务器为代理提供了一种通用方式，用于发现和调用由第三方SaaS产品、内部应用和API支持的工具。底层权限可能已经很熟悉；发生变化的是谁做出每个决策，以及错误决策传播的速度有多快。

将代理连接到这些工具只需一行配置。员工可以将Claude Code、Codex、Cursor、OpenCode、VS Code或任何AI框架指向MCP服务器，而无需检查它是否获得批准。生成的流量没有明显特征。模型上下文协议不使用保证的主机名，也不需要路径中包含/mcp，因此直接连接看起来就像其他任何HTTPS API调用。

为了说明这些控制措施如何协同工作，我们将从工具调用的结构及其暴露的信息开始。然后，我们将比较安全团队可以采取行动的三个位置：客户端内部、网络上和MCP服务器上。从那里，我们将展示Cloudflare Gateway如何利用协议信号发现影子MCP流量，并强制要求受信任的MCP服务器仅通过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"
}
}
}

该请求中包含多个有用的信息信号。主机名和路径标识了目标地址。授权头携带了用于在服务器要求时验证调用者的凭证。MCP-Protocol-Version 头标识了协议版本，而 Mcp-Method 和 Mcp-Name 则在新的无状态协议中暴露了操作和工具名称。JSON-RPC 封装体重复了方法名，为客户端匹配响应提供唯一 ID，并在 params 中携带工具参数。

参数是最敏感的部分。它们可能包含搜索查询、源代码、客户数据，或执行操作的指令（如创建工单或更改基础设施）。工具名称说明代理意图调用的接口；参数说明代理将发送的数据以及希望服务器执行的操作。

如果调用成功，服务器会返回包含相同 ID 和工具执行结果的 JSON-RPC 响应。该响应也可能包含敏感数据。请求检查可以在执行前阻止危险操作，而响应检查和日志记录则能显示工具向代理返回了什么内容。

控制 MCP 请求的三个关键位置

该请求为安全团队提供了三个观察或控制调用的切入点。

在 MCP 客户端内部

模型选择工具后、客户端序列化请求前，客户端钩子可以运行。在此阶段，无需解密网络流量即可查看目标服务器、工具名称和参数。

这是请求链中最早可以实施控制的阶段。客户端可以阻止不在白名单中的服务器，要求用户确认敏感操作，或在数据离开设备前从参数中移除敏感信息。它还可以覆盖本地 stdio（即本地）MCP 服务器，这些服务器永远不会生成网络流量。

这带来了标准化挑战。为了使安全团队受益，需要在员工使用的每个客户端上重复部署控制措施。当组织同时管理客户端和设备时，客户端控制效果最佳，但单一客户端的遥测数据永远无法完整反映 MCP 使用情况。

在设备的网络边界

安全网关可以在请求离开客户端后观察 HTTP 请求。通过 TLS 解密，它可以将请求与用户和设备关联，检查目标地址和协议头，并在不依赖特定 MCP 客户端的情况下应用策略。

网络层能以最宽广的视角检测受管路径上的远程 MCP 流量。它可以识别连接到非授权门户外服务器的直接连接，并在请求到达目标前阻止它们。在支持数据防泄漏扫描时，代理还可以检查 JSON-RPC 方法和参数中的敏感数据。然而，代理无法查看本地 stdio 调用或离线网络流量。

在 MCP 服务器调用工具之前

服务器拥有最丰富的执行上下文。它已验证调用者身份，解析了 MCP 消息，将 get_weather 映射到处理程序，并根据工具的输入模式验证了提供的参数。这是在工具运行前最后一次可以拒绝请求的检查点。

一个 Agents SDK 处理器或类似的服务器中间件可以对调用者进行特定工具的授权，应用速率限制，检查参数并记录结果。服务器应在调用处理器之前执行这些检查，尤其是对于会写入数据或触发外部操作的工具。仅在执行后记录日志可以解释发生了什么，但无法阻止其发生。

Cloudflare 的 WriteGuard 在我们的内部 MCP 服务器上广泛采用这种模式。每个工具都有一个风险等级和启用或禁用状态。WriteGuard 可以让读取操作直接通过而不做任何修改，为允许的写入操作添加代理归属信息和审计事件，或在处理器运行之前阻止关键操作。由于控制逻辑位于服务器端，终端用户无法通过切换客户端或禁用本地钩子来绕过它。

虽然服务器端控制只能保护实现了这些控制的服务器，但客户端和服务器拥有最佳的请求深度。网络能够看到最广泛的远程连接。将这些控制结合使用，可以在数据离开设备之前阻止敏感数据，发现未管理的 MCP 流量，并在工具执行之前拒绝未经授权的操作。

网络控制点拥有最广泛的覆盖范围，但首先需要区分 MCP 和普通 HTTPS 流量，用户必须运行代理，MCP 服务器（或门户）必须验证连接中使用了代理。

Cloudflare One 提供了这条链路的网络部分。Cloudflare One 客户端通过 Gateway 将管理设备的流量发送出去。Gateway 可以在协议层分类 MCP 请求，并区分流量是否来自 MCP 门户或是否正在访问未经批准的控制之外的资源。管理员随后可以报告或阻止未遵循批准路径的连接。该过程从可靠地识别请求开始。

URL 无法告诉你请求是否使用了 MCP

我们最初寻找 MCP 流量的方法是使用 GraphQL Analytics API 在 Gateway HTTP 日志中搜索包含 mcp 的主机名和常见路径（如 /mcp 或 /sse）。我们的 MCP 流量检测教程包含该查询。它还解释了如何为 MCP JSON-RPC 方法（如 initialize、tools/call 和 resources/read）在请求体中创建数据防泄漏模式。

这些信号对于发现旧客户端的流量和提供历史可见性仍然有用，但它们非常基础。它们会遗漏像 https://tools.example.com/api 这样普通 URL 上的 MCP 服务器，这种情况并不少见。

此外，它们可能会匹配到恰好在主机名或路径中使用了 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 头的初始化请求开始，因此网络控制可能无法仅凭头部信息将首次请求分类为对未知端点的访问。信号在客户端和服务器完成初始化后才会出现。

后续的工具调用示例如下：

POST /api HTTP/
1.1
Host: tools.example.com
Content-Type: application/json
MCP-Protocol-Version:
2025-11-25
{
"jsonrpc"
:
"2.0"
,
"id"
:
2
,
"method"
:
"tools/call"
,
"params"
:{
"name"
:
"get_weather"
}}

2026-07-28 版本的 MCP 规范对这一模型进行了重大修改。核心协议变为无状态设计，完全移除了初始化握手流程，将协议版本和操作信息直接放在每个请求中：

POST /mcp HTTP/
1.1
Host: tools.example.com
Content-Type: application/json
MCP-Protocol-Version:
2026-07-28
Mcp-Method: tools/call
Mcp-Name: get_weather
{
"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 清单。

阴影 MCP 与已批准路径绕过是两个独立问题

一旦 Gateway 能够识别 MCP 流量，就可以评估特定连接对安全态势的影响。

阴影 MCP 是连接到组织未批准的服务器。员工可能在代码库、产品指南或同事消息中发现该服务器，并直接将其添加到自己的 MCP 客户端。安全团队无法得知该服务器暴露了哪些工具，员工向其发送了哪些数据。

门户绕过则不同：它始于组织已放入 MCP 门户的已批准服务器，但员工直接连接到其上游 URL，绕过了门户的访问策略、精选工具目录、数据防泄漏和工具级审计跟踪。

Gateway 是管理网络路径上阴影 MCP 的主要控制点；它能识别经过 TLS 检查的 MCP 流量，显示目标和用户，并可应用策略。门户绕过需要网络控制加上能够拒绝直接请求的源点，无论是访问策略、源 IP 限制，还是由 MCP 服务器本身启动的企业授权机制。

在 Gateway 中检测 MCP 流量

对于已采用 Cloudflare Gateway 并启用 TLS 检查的客户，我们新增了一种检测启发式方法，为每个检查的请求回答一个简单问题：这是 MCP 流量吗？

对于基于会话的可流式 HTTP 连接，MCP 客户端在初始化后会发送 MCP-Protocol-Version 头。Gateway 会检查每个经过 TLS 检查的请求中的该头部，并根据观察到的数百万请求模式进行分类。分类能够识别 MCP 协商和代理到主机名的操作，而无需提前知道具体主机或 URL。

从今天起，所有 Cloudflare Zero Trust 客户都可以在 Gateway HTTP 日志中看到 MCP 流量的迹象，并可通过新 Gateway 选择器明确阻止或允许该流量：

experimental.is_mcp == true

选择器是一个布尔值。如果 Gateway 在经过 TLS 检查的请求中检测到 MCP-Protocol-Version 请求头，其值为 true，管理员无需维护自己的 MCP 域名列表，即可在允许或阻止策略中使用该值。

所有直接加密的流量必须经过 TLS 解密后，Gateway 才能检查这些请求头，而本地 stdio 服务器、离网连接、"不检查"流量以及从未经过 Gateway 的请求将无法被纳入此视图。

网络中 MCP 流量的可视化

今天，我们推出了一款专门的 MCP 流量仪表板，可显示网络中哪些主机正在处理 MCP 流量、哪些用户正在生成这些流量，以及请求是通过您的 Cloudflare MCP 门户传输还是完全绕过门户。

该仪表板显示以下信息：

• 可配置时间窗口内的总 MCP 请求量、唯一用户数和唯一服务器数
• 随时间变化的 MCP 服务器列表及每台服务器的请求数
• 按接入点划分的流量分布，将 MCP 门户流量与直接设备客户端连接区分开
• 在门户外部观察到的顶级 MCP 服务器列表，这些是最重要的影子 MCP 流量
• 按 MCP 请求数排序的顶级用户列表

管理员可通过特定服务器、用户或接入点类型进行筛选，并直接导航至经过相关主机或用户过滤的 Gateway HTTP 日志，进行更深入的调查。

将发现的服务器纳入 MCP 门户

MCP 发现功能将未知流量转换为管理员可调查的列表。当组织批准其中某个服务器时，可以将该服务器部署在 Cloudflare MCP 服务器门户后。门户为员工提供一个托管端点，并在上游服务器前设置访问身份、精选工具目录和日志记录。管理员可通过 Gateway 将兼容的上游调用路由至 HTTP 策略、可预测的出站连接和数据防泄漏策略，无论是在门户层面还是针对单个服务器。工具活动也可以通过 Logpush 导出。随后，发现仪表板可以区分使用门户的请求和直接连接到同一服务器的请求。

这为从发现到治理创造了路径：找到服务器，决定是否批准，将批准的使用场景移至门户后，并调查继续绕过门户的流量。最后一步至关重要，因为未经批准的服务器和绕过已批准服务器的情况是两种不同的问题。

强制门户唯一访问

我们正在向 Gateway 网络和 HTTP 策略添加流量来源选择器，使管理员能够根据流量是否来自 MCP 门户来编写规则，从而精确控制 MCP 流量。

当 MCP 门户流量通过 Gateway 时，会携带一个 mcp_portal 流量来源标识，使策略能够区分门户代理请求和直接员工连接。一个基础的强制规则如下：

experimental.is_mcp == true and not traffic.onramp in ("mcp_portal")
Action: Block

任何未通过门户检测到的 MCP 流量都会被阻止；通过门户传输的流量不受影响。对于希望先观察再实施强制措施的组织，现在 HTTP 日志中已包含流量来源和 MCP 检测信息（针对已解密流量），因此无需策略即可监控代理流量的行为。

更多 MCP 服务器现在可以使用受控路径

只有在能够连接到员工实际需要的大量关键服务器时，批准的路径才有价值。

将私有 MCP 服务器纳入同一 Portal

公共 SaaS 工具只是企业 MCP 目录的一部分。企业依赖的大多数安全信息无法通过公共互联网获取；它们存在于公共或私有云基础设施中，或部署在本地，并且只能通过连接到私有网络才能访问。

目前，MCP Portal 必须能够通过公共互联网解析并连接到上游服务器。这意味着仅通过私有网络（如私有 DNS 或私有 IP 空间）访问的服务器无法被 Portal 连接。我们正在努力让 MCP Portal 通过 Cloudflare Gateway 路由和已用于其他私有应用的 Cloudflare One 网络连接到私有服务器。

私有服务器保留其私有主机名；Portal 通过 Cloudflare 的私有路由访问它，并将工具与公共上游服务器并列展示；访问策略、Portal 日志和工具控制继续在同一个入口点生效。

通过 Gateway 路由 Portal 流量时，会为其打上 mcp_portal 流量来源标识，这样 Gateway 策略可以区分 Portal 请求和员工的直接连接。MCP 服务器的私有连接功能正在积极开发中；请关注更新日志以获取更多信息。

Agents SDK 支持新的无状态模型

几周前，MCP 项目发布了 2026-07-28 规范，这是一个重大修订，用无状态的按需模型取代了基于连接的作用域初始化。我们在《MCP 的下一代》中已经介绍了协议变更和迁移路径。

Cloudflare Agents SDK v0.20.0 作为客户端和服务器均支持 MCP 2026-07-28。对于每个连接，客户端会首先通过 server/discover 探测新的无状态协议；如果服务器不支持该协议，客户端将继续在相同连接上使用传统的 initialize 握手。现有的 addMcpServer 调用无需单独的协议设置或单独的客户端。

在服务器端，createMcpHandler 可以在不创建传输会话或 Durable Object 的情况下，从 Worker 提供无状态工具、提示、资源和引导：

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 门户后方。

然后，实施你能够控制的边界。组合 Gateway 策略，将 MCP 检测条件与流量源和目标条件结合使用，以阻止来自受管设备和站点的直接 MCP 连接，并尽可能将自托管上游服务器限制为门户流量。

我们很快将添加更多粒度功能来增强对 MCP 流量的可见性和控制，包括对特定工具使用的控制，以及在你环境中所有 MCP 服务器（无论是安全组织已知还是未知的）的工具使用情况的新报告。

我们的 MCP 流量检测教程涵盖了当前 Gateway 日志可用的主机名、路径和 JSON-RPC 启发式方法。随着新信号达到通用可用性，我们将更新文档以包含协议选择器的详细信息。

目录列

讨论列

相关标签和社交媒体链接

相关标签

在社交媒体上关注

• Cloudflare

• Kenny Johnson

电子邮件订阅