AICloudflare OneMCPSASEZero Trust产品新闻

Cloudflare 如何检测 MCP 流量并助力安全防护

AJ Gerstenhaber和Kenny Johnson

阅读时间：14 分钟

本文另有 English和繁體中文.

大多数企业在设计资源权限时，考虑的对象是人类用户。一位高级工程师可能拥有部署到生产环境、查询敏感数据库或撤销其他用户访问权限的权限。这些权限本身存在风险，但传统上该风险受到两个前提的约束：工程师会运用人类判断力，且工程师每天的操作速度有其上限。

工程师看到异常结果时，通常会停下来重新审视自己的操作。任何人每天能够点击、输入和审阅的内容都是有限的。AI 智能体的引入改变了这两个阈值。它们的决策具有不确定性，且可以无限次执行同一操作（或调用同一工具），既不会疲倦，也不需要休息。一个看似合理却错误的决策，可能在人类察觉之前已演变为数以千计的错误操作。

今天，我们宣布推出全新 Cloudflare One 功能，用于识别经过检测的 MCP 流量、显示流量的生成用户和服务器，以及管控受管网络路径上的直接连接请求。结合 MCP Server Portals，这些管控机制帮助管理员判断智能体是否正在使用已批准的访问路径，还是以某种方式绕过了它。

模型上下文协议 (MCP) 服务器为智能体提供了一种通用方式，用于发现和调用由第三方 SaaS 产品、内部应用程序及 API 支撑的工具。底层权限逻辑大多并不陌生；真正改变的是谁在做每个决策，以及错误决策扩散的速度。

将智能体连接到其中某个工具，可能只需一行配置。员工可以将 Claude Code、Codex、Cursor、OpenCode、VS Code 或任何 AI 工具指向某个 MCP 服务器，而无需检查该服务器是否已获批准。由此产生的流量没有明显特征。模型上下文协议不使用固定主机名，也不要求路径中包含 /mcp，因此，直接连接看起来可能与任何其他 HTTPS API 调用相似。

为了说明这些管控机制如何协同运作，我们将从工具调用的结构及其暴露的信息入手，然后比较安全团队可采取行动的三个位置：客户端内部、网络层和 MCP 服务器。在此基础上，我们将展示 Cloudflare Gateway 如何利用协议信号发现影子 MCP 流量，并对受信任的 MCP 服务器强制执行仅限 MCP Portal 的访问。

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 信封重复了方法信息，通过 id 字段让客户端能够将请求与响应匹配，并在 params 中携带工具参数。

参数是最敏感的部分，可能包含搜索查询、源代码、客户数据，或创建工单、变更基础设施等操作指令。工具名称说明了智能体打算调用什么；参数则揭示了它将发送哪些数据，以及希望服务器执行什么操作。

调用成功后，服务器返回携带相同 ID 和工具结果的 JSON-RPC 响应。该响应同样可能包含敏感数据。请求检测可以在执行前阻止不安全的操作，而响应检测和日志记录则记录工具向智能体返回了什么内容。

管控 MCP 请求的三个位置

该请求为安全团队提供了三个可观测或管控调用的位置。

MCP 客户端内部

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

这是请求链中最早可施加管控的阶段。客户端可以拒绝不在允许列表中的服务器、要求用户确认敏感操作，或在数据离开设备之前将其从参数中移除。客户端钩子还可以覆盖本地 stdio（即本地）MCP 服务器，这类服务器不产生任何网络流量。

这一方式存在标准化挑战。要使安全团队从中受益，需要在员工使用的每个客户端上复现相同的管控逻辑。客户端侧的管控在组织同时管理客户端和设备时效果最佳，但来自单个客户端的遥测数据永远无法完整呈现 MCP 的使用全貌。

设备的网络边界

安全 Web 网关可在请求离开客户端后对 HTTP 请求进行观测。借助 TLS 解密，它可以将请求与用户和设备关联，检测目标及协议标头，并在不依赖特定 MCP 客户端的情况下应用策略。

网络层具有最广泛的视角，能够检测受管路径上的远程 MCP 流量。它可以识别直接连接至已批准 Portal 之外服务器的请求，并在请求到达目标之前予以阻止。在支持数据丢失防护扫描的场景下，代理还可以检查请求体中的 JSON-RPC 方法和参数是否含有敏感数据。然而，代理无法查看本地 stdio 调用或网络外流量。

MCP 服务器调用工具之前

服务器拥有最丰富的执行上下文：它已完成调用方的身份验证、解析了 MCP 消息、将 get_weather 解析到对应的处理程序，并针对工具输入 schema 验证了所提供的参数。这是工具运行前最后一个可以拒绝请求的位置。

Agents SDK 处理程序或类似的服务器中间件可以针对特定工具对调用方进行授权、应用速率限制、检测参数，并记录执行结果。服务器应在调用处理程序之前完成这些检查，尤其是针对写入数据或触发外部操作的工具。仅在执行后记录日志只能解释已发生的事情，但无法加以阻止。

Cloudflare 的 WriteGuard 正是在我们内部的 MCP 服务器中采用了这一模式。每个工具都有对应的风险等级和启用/禁用状态。WriteGuard 可以放行读取操作、为允许的写入操作添加智能体归因信息和审计事件，或在关键操作的处理程序运行之前予以阻止。由于管控逻辑位于服务器端，终端用户无法通过切换客户端或禁用本地钩子来绕过它。

服务器端管控仅能保护已实现该机制的服务器，而客户端和服务器拥有最深的请求可见性；网络层则覆盖最广泛的远程连接范围。三者协同使用，可以在敏感数据离开设备前予以拦截、发现未受管的 MCP 流量，并在工具执行前阻止未经授权的操作。

网络管控点覆盖范围最广，但首先需要将 MCP 流量与普通 HTTPS 流量区分开来，用户还必须运行代理，且 MCP 服务器（或 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（例如 https://tools.example.com/api）中的 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 标头的 initialize 请求开始，因此网络管控可能无法仅凭该标头对首次请求到未知端点的流量进行分类。该信号在客户端和服务器完成初始化之后才会出现。

后续的工具调用形式如下：

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"}}

MCP 2026-07-28 规范对此模型进行了重大更改。核心协议变为无状态，完全移除了 initialize 握手，而是将协议版本和操作信息添加到每个请求中：

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 客户端。安全团队对该服务器暴露了哪些工具、员工向其发送了哪些数据一无所知。

Portal 绕过则不同：它始于一个已获批准并被纳入 MCP Portal 的服务器，但员工直接连接其上游 URL，跳过了 Portal 的 Access 策略、精选工具目录、数据丢失防护和工具级审计追踪。

Gateway 是受管网络路径上针对影子 MCP 的主要管控手段——它识别经 TLS 检测的 MCP 流量，显示目标和用户，并可应用策略。应对 Portal 绕过则需要在网络管控的基础上，辅以能够拒绝直接连接请求的源站——无论是通过 Access 策略、源 IP 限制，还是由 MCP 服务器本身发起的企业级授权机制。

检测 Gateway 中的 MCP 流量

对于已采用 Cloudflare Gateway 并启用 TLS 检测的客户，我们正在新增一项检测启发式机制，针对每个经过检测的请求回答一个简单问题：这是 MCP 流量吗？

对于基于会话的 Streamable HTTP 连接，MCP 客户端在初始化之后会发送 MCP-Protocol-Version 标头。Gateway 对每个经过 TLS 检测的请求检查该标头并据此对流量进行分类，其检测机制基于我们从每天穿越 Cloudflare 网络的数百万请求中观测到的模式构建而成。该分类能够在不预先掌握特定主机或 URL 的情况下识别 MCP 协商和代理请求。

即日起，所有 Cloudflare Zero Trust 客户均可在 Gateway HTTP 日志中查看 MCP 流量标记，并且可以使用以下新增 Gateway 选择器明确地阻止或允许该流量：

experimental.is_mcp == true

该选择器为布尔值。若 Gateway 在经过 TLS 检测的请求中检测到 MCP-Protocol-Version 标头，则值为 true，管理员可以在允许或阻止策略中使用它，而无需自行维护 MCP 域名列表。

直接加密的流量必须先通过 TLS 解密，Gateway 才能检测这些标头；本地 stdio 服务器、网络外连接、Do Not Inspect 流量以及未经 Gateway 传输的请求，均不在此检测范围之内。

全网 MCP 流量可见性

今天，我们推出专属 MCP 流量仪表板，展示网络内哪些主机正在提供 MCP 服务、哪些用户正在产生流量，以及请求是通过 Cloudflare MCP Portals 传输还是完全绕过了它们。

image4.png

仪表板显示：

  • 可配置时间窗口内的 MCP 请求总量、唯一用户数及唯一服务器数
  • 各服务器随时间变化的 MCP 请求量及逐服务器请求计数
  • 按流量来源（on-ramp）分类的流量明细，区分 MCP Portal 流量与设备客户端直接连接请求
  • Portal 之外访问量最高的 MCP 服务器——即最需要关注的影子 MCP 流量
  • 按 MCP 请求量排名的活跃用户
image2.png

管理员可按特定服务器、用户或流量来源类型进行筛选，并可直接跳转至按相关主机或用户过滤的 Gateway HTTP 日志，以便深入调查。

image1.png

将已发现的服务器纳入 MCP Portal

MCP 发现功能将未知流量转化为管理员可供调查的清单。当组织批准其中某个服务器时，可将其置于 Cloudflare MCP 服务器 Portal 之后。Portal 为员工提供统一的受管端点，并在上游服务器前置 Access 身份验证、精选工具目录和日志记录。管理员可将兼容的上游调用通过 Gateway 路由，以实现 HTTP 策略、可预测的出站流量和数据丢失防护，范围覆盖整个 Portal 或单个服务器。工具活动还可以通过 Logpush 导出。发现仪表板随后可以区分经由 Portal 传输的请求与直接连接到同一服务器的请求。

这构建了一条从发现到治理的完整路径：发现服务器、决定是否批准、将已批准的使用迁移至 Portal，并调查持续绕过 Portal 的流量。最后一步尤为重要，因为未经批准的服务器与已批准服务器被绕过，是两个性质不同的问题。

强制执行仅限 Portal 的访问

我们正在 Gateway 网络和 HTTP 策略中新增流量来源选择器，让管理员能够根据 MCP 流量是否源自 MCP Portal 来编写规则，以控制 MCP 流量。

当 MCP Portal 流量通过 Gateway 路由时，会携带 mcp_portal 流量来源标记，从而使策略能够区分经由 Portal 代理的请求与员工直接连接请求。一条基础的强制执行规则如下：

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

所有检测到的 MCP 流量，凡未经由 Portal 传入的均予以阻止；经由 Portal 传入的流量则不受影响。对于希望先观察再执行的组织，流量来源和 MCP 检测结果现已出现在已解密流量的 HTTP 日志中，无需创建策略即可监控代理流量的行为。

更多 MCP 服务器现可使用受管路径

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

早期 MCP 规范推荐使用动态客户端注册，允许客户端在无需 OAuth 应用的情况下向授权服务器注册自身。然而，许多常见的 OAuth 提供商采用不同的模型：要求管理员使用固定的客户端 ID、客户端密钥、回调 URL 和权限范围注册应用程序。MCP 2026-07-28 规范近期也已弃用动态注册。

为帮助解决这一问题，MCP Portal 现已支持预注册的 OAuth 客户端。管理员可以配置手动 OAuth 凭据，在上游提供商处注册仪表板中显示的回调 URL，并输入客户端凭据。Portal 在可用时会自动发现标准 OAuth 元数据；当发现功能不可用时，管理员可手动提供授权、令牌、撤销和颁发者端点。

每位用户仍需自行授权访问其上游数据源，存储的客户端密钥仅用于获取更新的工具和提示列表。

手动 OAuth 支持现已帮助覆盖众多 OAuth 实现的排列组合。部分提供商要求自定义标头、个人访问令牌或明确的客户端允许列表，这些属于独立的兼容性问题。我们将在未来数月持续扩展 MCP Portals 的 OAuth 支持。

将专用 MCP 服务器纳入统一 Portal

公共 SaaS 工具只是企业 MCP 目录的一部分。企业依赖的大多数安全信息并非来自公共互联网；它们存在于公有云或私有云基础设施中，或托管于本地，只能通过接入专用网络才可访问。

目前，MCP Portal 必须能够通过公共互联网解析并访问上游服务器。这意味着仅在专用网络中可用的服务器——通过私有 DNS 或私有 IP 空间访问的服务器——尚无法被 Portal 访问。我们正在推进让 MCP Portals 通过 Cloudflare Gateway 路由和 Cloudflare One 网络连接专用服务器，该网络已被广泛用于其他专用应用程序。

专用服务器保留其私有主机名；Portal 通过 Cloudflare 的私有路由访问它，并将其工具与公共上游服务器并列呈现；Access 策略、Portal 日志记录和工具管控在同一入口处继续生效。

将 Portal 流量通过 Gateway 路由，还会为其打上 mcp_portal 流量来源标记，使 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 无状态地提供工具、提示、资源和 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 Portal。

随后，在可管控边界上执行策略。结合 MCP 检测条件、流量来源和目标条件，构建 Gateway 策略，阻止受管设备和站点上的 MCP 直接连接请求，并尽可能将自托管上游服务器限制为仅接受 Portal 流量。

我们即将推出更细粒度的 MCP 流量可见性与管控功能，包括对特定工具使用的管控，以及对您环境中所有 MCP 服务器工具使用情况的全新报告——无论这些服务器是否已被您的安全团队掌握。

我们的 MCP 流量检测教程涵盖了 Gateway 日志目前可用的主机名、路径和 JSON-RPC 启发式方法。新信号正式发布后，我们将更新文档，介绍协议选择器的详细信息。