Cloudflare 教你识别企业网络里的 MCP 流量：影子智能体、绕过审批通道，一次看清

清风徐来AI 前沿2026-09-181198 阅读💛 64 收藏

一句话结论

Cloudflare One 新增 MCP 流量识别与管控能力：Gateway 在协议层检测 TLS 解密流量里的 MCP-Protocol-Version 头，让安全团队看见哪些用户在用哪些 MCP 服务器、流量是否走审批过的 MCP Portal，并可用一条策略直接封堵绕过 Portal 的直连。对正在铺开 AI 智能体的企业，这是从”完全盲区”到”可控可见”的第一步。

MCP 流量安全更新发布主视觉

权限模型是为人设计的，智能体打破了假设

大多数公司的资源权限设计以人类用户为原型。资深工程师可以部署生产、查询敏感库、吊销他人权限。这些特权有风险，但风险被两个假设兜住：工程师会行使人类判断，工程师只能以人类速度行动。

看到意外结果的工程师通常会停下来重新考虑。任何人一天能点击、输入、审查的量是有限的。AI 智能体的引入同时打破两个阈值：它们的决策是非确定性的，且可以无限次执行同一动作（或调用同一工具），不知疲倦也不吃午饭。一个貌似合理但错误的决策，可能在人类注意到之前变成几千个错误动作。

今天 Cloudflare 宣布 Cloudflare One 新能力：识别被检测的 MCP 流量、展示哪些用户和服务器在产生它、控制受管网络路径上的直连。配合 MCP Server Portal，这些控制帮管理员看清智能体是在用审批过的通道，还是以某种方式绕过它。

模型上下文协议（MCP）服务器给智能体提供统一方式去发现和调用由第三方 SaaS、内部应用和 API 支撑的工具。底层权限可能很熟悉；变化的是谁在做每个决策，以及一个坏决策能多快扩散。

把智能体接到这类工具只需一行配置。员工可以把 Claude Code、Codex、Cursor、OpenCode、VS Code 或任何 AI 工具指向一个 MCP 服务器，而不检查它是否获批。产生的流量没有明显形状：MCP 不用固定 hostname，也不要求路径里有 /mcp，直连看起来和任何 HTTPS API 调用一样。

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

请求里挤着几个有用信号。hostname 和路径标识目的地。authorization 头携带服务器要求时的认证凭据。MCP-Protocol-Version 标识协议版本，Mcp-Method 和 Mcp-Name 在新无状态协议中暴露操作和工具。JSON-RPC 信封重复方法、给请求一个客户端可匹配响应的 id，并在 params 里携带工具参数。

参数是最敏感的部分。它可以包含搜索查询、源代码、客户数据，或创建工单、变更基础设施之类的行动指令。工具名说明智能体打算调什么；参数说明它要发什么数据、想让服务器执行什么动作。

调用成功时，服务器返回带相同 ID 和工具结果的 JSON-RPC 响应。响应也可能含敏感数据。请求检测可以在执行前阻止不安全动作；响应检测和日志展示工具向智能体返回了什么。

控制一次 MCP 请求的三个位置

请求给安全团队三个观察或控制点。

客户端内。 客户端钩子可以在模型选定工具后、客户端序列化请求前运行。它能看到目的地服务器、工具名和参数，无需解密网络流量。这是请求链上最早的管控点：客户端可以拒绝不在白名单上的服务器、让用户确认敏感操作、或在参数离开设备前抹掉数据，还能覆盖本地 stdio（即本地）MCP 服务器——它们根本不产生网络流量。但标准化是个挑战：安全团队要在员工用的每个客户端里复制控制逻辑。客户端控制在组织同时管客户端和设备时效果最好，但单一客户端的遥测永远不是 MCP 使用的完整清单。

设备网络边界。 安全网页网关可以在 HTTP 请求离开客户端后观察它。配合 TLS 解密，可以把请求关联到用户和设备、检查目的地和协议头、应用策略，而不依赖特定 MCP 客户端。网络层是检测受管路径上远程 MCP 流量的最广镜头，能识别绕过审批 Portal 的直连并在请求到达目的地前阻断。支持数据防泄漏扫描的地方，代理还能检查 JSON-RPC 方法和参数里的敏感数据。但代理看不到本地 stdio 调用和网外流量。

MCP 服务器调工具之前。 服务器有最丰富的执行上下文：已认证调用者、已解析 MCP 消息、已把 get_weather 解析到处理器、已按工具输入 schema 校验参数。这是请求被拒前的最后关卡。Agents SDK 处理器或类似服务器中间件可以对特定工具授权调用者、限流、检查参数、记录结果。服务器应在调用处理器前做这些检查，尤其是写数据或触发外部动作的工具——只做事后日志能解释发生了什么，但不能阻止它。

Cloudflare 的 WriteGuard 在内部 MCP 服务器上就用这套模式。每个工具有风险层级和启用/禁用状态。WriteGuard 可以放行读操作、给允许的写操作加智能体归因和审计事件、或在关键动作进入处理器前拦截。控制住在服务器上，终端用户换客户端或禁本地钩子都绕不过。

服务器侧控制只保护实现了它的服务器，但客户端和服务器有最好的请求深度；网络看到最广的远程连接集合。组合使用：在敏感数据离开设备前拦住、发现未纳管的 MCP 流量、在工具执行前拒绝未授权操作。

URL 判断不了请求是不是 MCP

Cloudflare 找 MCP 流量的第一种方法用 GraphQL Analytics API 在 Gateway HTTP 日志里搜 hostname 含 mcp、常见路径如 /mcp 或 /sse 的记录。官方 MCP 流量检测教程包含该查询，也讲如何为请求体里 initialize、tools/call、resources/read 等 JSON-RPC 方法创建数据防泄漏模式。

这些信号对找旧客户端流量、提供历史可见性仍有用，但太粗糙。它们会漏掉部署在普通 URL（如 https://tools.example.com/api）下的 MCP 服务器——这不罕见。还可能误匹配碰巧在 hostname 或路径里用 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 头的 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 与绕过 Portal 是两个不同的问题

Gateway 能识别 MCP 流量后，就可以评估一条连接对安全态势意味着什么。

影子 MCP 是连接到组织未批准的服务器。员工在仓库、产品文档或同事消息里发现服务器，直接加进自己的 MCP 客户端。安全团队完全不知道它暴露哪些工具、员工往里发什么数据。

Portal 绕过不同：起点是组织已放进 MCP Portal 的获批服务器，但员工直连它的上游 URL，跳过 Portal 的 Access 策略、策展工具目录、数据防泄漏和工具级审计轨迹。

Gateway 是受管网络路径上影子 MCP 的主控制点：识别 TLS 检测过的 MCP 流量、展示目的地和用户、应用策略。Portal 绕过需要网络控制加上能拒绝直连的源站——无论是 Access 策略、源 IP 限制，还是 MCP 服务器自己发起的企业授权机制。

Gateway 里的 MCP 流量检测

对已采用 Cloudflare Gateway 和 TLS 检测的客户，Cloudflare 正在添加一个检测启发式，对每个被检测请求回答一个简单问题：这是 MCP 流量吗？

对基于会话的 Streamable HTTP 连接，MCP 客户端在初始化后发送 MCP-Protocol-Version 头。Gateway 在每个 TLS 检测请求上检查该头并相应分类流量——检测基于 Cloudflare 网络每天数百万请求中观察到的模式构建。分类识别 MCP 协商和到 hostname 的代理，无需预知具体 host 或 URL。

从今天起，所有 Cloudflare Zero Trust 客户在 Gateway HTTP 日志里看到 MCP 流量指示，并可用新的 Gateway 选择器显式封堵或放行：

experimental.is_mcp == true

选择器是布尔值。Gateway 在 TLS 检测请求上检测到 MCP-Protocol-Version 头时值为 true，管理员可在 Allow 或 Block 策略中使用，无需自维护”MCP 长相”域名列表。

直连加密流量必须先过 TLS 解密，Gateway 才能检查这些头；本地 stdio 服务器、网外连接、Do Not Inspect 流量和未经 Gateway 的请求不在视野内。

全网 MCP 流量可见性

Cloudflare 同时发布专用 MCP 流量仪表盘，展示哪些主机在你的网络里服务 MCP 流量、哪些用户在产生流量、请求走的是 Cloudflare MCP Portal 还是完全绕过。

MCP 流量仪表盘总览

仪表盘展示：可配置时间窗内的 MCP 请求总数、独立用户数、独立服务器数；按时间的 MCP 服务器及每服务器请求数；按 on-ramp 分解的流量，区分 MCP Portal 流量与设备直连；Portal 外最常见的 MCP 服务器——即最要紧的影子 MCP 流量；MCP 请求数最多的用户。

影子 MCP 服务器与用户排行

管理员可按特定服务器、用户或 on-ramp 类型过滤，并直接跳转到按相关 host 或用户过滤的 Gateway HTTP 日志深入调查。

把发现的服务器纳入 MCP Portal

MCP 发现把未知流量变成管理员可调查的清单。组织批准某个服务器后，可把它放到 Cloudflare MCP 服务器 Portal 后面。Portal 给员工一个受管端点，在上游服务器前放 Access 身份、策展工具目录和日志。管理员可通过 Gateway 路由兼容的上游调用获得 HTTP 策略、可预测出口和数据防泄漏——整个 Portal 或单服务器皆可。工具活动也可通过 Logpush 导出。发现仪表盘随后能区分使用 Portal 的请求和对同一服务器的直连。

这形成从发现到治理的路径：找到服务器、决定是否批准、把批准的使用移到 Portal 后、调查继续绕行的流量。最后一步很关键，因为未批准服务器和绕过已批准服务器是不同的问题。

强制 Portal-only 访问

Cloudflare 正在给 Gateway 网络和 HTTP 策略添加 Traffic Source 选择器，让管理员能按”是否源自 MCP Portal”写规则控制 MCP 流量。

MCP Portal 流量经 Gateway 路由时携带 mcp_portal Traffic Source，策略可区分 Portal 代理请求与员工直连。基线强制规则长这样：

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

Traffic Source 选择器与阻断规则示例

未走 Portal 的被检测 MCP 流量全被封堵；走 Portal 的不受影响。想先观察再强制的组织，Traffic Source 和 MCP 检测已存在于已解密流量的 HTTP 日志，无需策略即可监控代理流量行为。

私网 MCP 服务器纳入同一 Portal

公共 SaaS 工具只是企业 MCP 目录的一部分。企业依赖的大多数敏感信息无法从公网获取——它们在公有或私有云基础设施里，或托管在本地，只能通过对私网的连接访问。

今天 MCP Portal 必须能通过公网解析和到达上游服务器。这意味着只在私网可用的服务器——私 DNS 或私 IP 空间内——Portal 到不了。Cloudflare 正在让 MCP Portal 通过 Cloudflare Gateway 路由和其他私有应用已在用的同一张 Cloudflare One 网络连接私网服务器。

私网服务器保留私网 hostname；Portal 通过 Cloudflare 私有路由到达它，把它的工具和公共上游服务器并列展示；Access 策略、Portal 日志和工具控制继续在同一前门生效。

经 Gateway 路由的 Portal 流量同样盖上 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 服务无状态的工具、提示词、资源和启发，无需创建传输会话或 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 后。

然后，强制你能控制的边界。组合 Gateway 策略——用 MCP 检测条件加 Traffic Source 和目的地条件——封堵受管设备和站点发起的 MCP 直连，尽可能把自托管上游服务器限制到 Portal 流量。

从检测到治理的落地路径

Cloudflare 很快会为 MCP 流量的可见性和控制添加更细粒度功能，包括对特定工具使用的控制，以及对环境内所有 MCP 服务器（无论安全组织是否已知）的工具使用新报告。

官方 MCP 流量检测教程覆盖今天 Gateway 日志可用的 hostname、路径和 JSON-RPC 启发式。新信号到达正式可用时，文档会更新协议选择器细节。

落地清单：三步把智能体流量管起来

落地建议按顺序做：先在 Zero Trust 控制台开启 Gateway 的 TLS 检测并检查 HTTP 日志里的 is_mcp 字段，梳理出员工智能体实际连接的服务器清单；再为获准的服务器创建 MCP Portal 并配置 Access 策略；最后用 traffic.onramp 条件构建阻断规则，把绕过 Portal 的智能体直连全部拦下——整套工作流不用改一行业务代码。

如果你在开发内部 MCP 服务器，用 Agents SDK 的 createMcpHandler 部署无状态服务后，记得给每个写操作工具配置风险层级与审计事件：智能体调用工具前就能被放行、加注或拦截，这套控制住在服务器上，换客户端也绕不过。