企业给工程师的权限设计，默认用户是人。高级工程师可以部署生产、查敏感数据库、撤销别人的访问——这些风险过去被两个假设限制：工程师会用人类判断力，工程师只能以人类速度行动。
AI Agent 同时打破了这两条。它的决策是非确定性的，它可以无限重复同一个动作或工具调用，不累也不需要吃午饭。一个看起来合理但实际错误的决策，可能在人注意到之前变成几千次错误操作。
Cloudflare 8 月 14 日宣布，Cloudflare One 新增了识别被检查的 MCP 流量、显示哪些用户和服务器在生成流量、以及在受管网络路径上控制直连的能力。配合 MCP Server Portals，这些控制帮管理员看清 Agent 是在用审批过的路径，还是在绕过它。
MCP 工具调用的三个控制点
同一次 MCP 工具调用在系统里有三种形式：
- 客户端内部：决定调用某个工具，传某些参数
- 网络上：一个 HTTP 事务，带着 JSON-RPC 消息
- 服务器端：调用工具处理器，可能读数据、改状态或触发其他动作
例如一个 Agent 想查奥斯汀的天气，远程 MCP 请求的关键元素包括：
- 主机名和路径标识目的地
- Authorization header 带着调用者的凭证
- MCP-Protocol-Version 标识协议版本
- Mcp-Method 和 Mcp-Name 暴露操作和工具名（新的无状态协议里）
- JSON-RPC 信封重复了 method，给请求分配 id 用于匹配响应，并在 params 里带着工具参数
参数是最敏感的部分。可能包含搜索查询、源代码、客户数据，或创建工单、改基础设施这类指令。工具名说 Agent 打算调什么；参数说它会发什么数据、想让服务器执行什么动作。
安全团队可以在三个地方观察或控制这次调用：
1. MCP 客户端内部
客户端钩子可以在模型选定工具之后、客户端序列化请求之前运行。它能看到目标服务器、工具名和参数，不需要解密网络流量。
这是请求链最早的控制阶段。客户端可以拒绝不在白名单里的服务器，要求用户确认敏感操作，或在数据离开设备前从参数里删除数据。它还能覆盖本地 stdio（即本地）MCP 服务器，这类服务器从不产生网络流量。
挑战在于标准化。安全团队要让这套控制在员工用的每个客户端里都生效。客户端控制在组织同时管理客户端和设备时效果最好，但来自单一客户端的遥测永远不是 MCP 使用的完整清单。
2. 设备的网络边界
安全 Web 网关可以在 HTTP 请求离开客户端后观察它。启用 TLS 解密后，它能把请求关联到用户和设备，检查目的地和协议头，应用策略而不依赖特定 MCP 客户端。
网络层拥有最广的视角来检测受管路径上的远程 MCP 流量。它能识别到审批 Portal 之外服务器的直连，并在请求到达目的地前拦截。在支持数据防泄漏扫描的地方，代理还能检查 JSON-RPC method 和参数里的敏感数据。但代理看不到本地 stdio 调用或不走网络的流量。
3. MCP 服务器调用工具之前
服务器拥有最丰富的执行上下文。它已经验证过调用者，解析了 MCP 消息，把 get_weather 解析到一个处理器，并根据工具的输入 schema 验证了提供的参数。这是工具运行前最后一个可以拒绝请求的点。
Agents SDK 处理器或类似的服务器中间件可以为特定工具授权调用者、应用速率限制、检查参数、记录结果。服务器应该在调用处理器之前做这些检查，尤其是对写数据或触发外部动作的工具。只在执行后记录日志可以解释发生了什么，但无法阻止它。
Cloudflare 内部的 WriteGuard 用的就是这个模式。每个工具有风险等级和启用/禁用状态。WriteGuard 可以原样放行一次读取，给允许的写入加上 Agent 归因和审计事件，或在处理器运行前拦截关键动作。因为控制在服务器端，终端用户无法通过切换客户端或禁用本地钩子来绕过。
客户端和服务器拥有最佳的请求深度，网络看到最广的远程连接集。这三者配合使用，可以在数据离开设备前拦住敏感数据，找到未受管的 MCP 流量，并在未授权操作执行前拒绝它。
协议头比 URL 更可靠
Cloudflare 第一版 MCP 流量检测用 GraphQL Analytics API 搜 Gateway HTTP 日志，找主机名包含 mcp 和常见路径如 /mcp 或 /sse 的请求。还可以为 MCP JSON-RPC method 创建 DLP 模式，比如 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 请求都带。
这不代表 header 是完整的检测器。老客户端的初始请求可能不包含它，2025-06-18 之前的协议版本没定义它，本地 stdio、自定义传输或不符合规范的流量可能永远不带它。它的存在是 MCP 的强阳性指标；它的缺失不证明请求不是 MCP。
MCP 2026-07-28 规范改变了这个模型。核心协议是无状态的；它完全移除了 initialize 握手，并把协议版本和操作放在每个请求上。Mcp-Method 和 Mcp-Name header 让普通 HTTP 基础设施不用解析 body 就能识别操作。负载均衡器可以路由请求，速率限制器可以区分 tools/list 和 tools/call，安全产品在每个请求上获得更多信息。
这些协议信号给了 Cloudflare Gateway 具体可评估的东西，不依赖一个”看起来像 MCP”的 URL 清单。
Gateway 的新检测能力
从今天开始，所有 Cloudflare Zero Trust 客户都能在 Gateway HTTP 日志里看到 MCP 流量指示，并用新的 Gateway selector 明确拦截或放行该流量：
experimental.is_mcp == true
这是个布尔值。如果 Gateway 在被 TLS 解密的请求上检测到 MCP-Protocol-Version header，值就是 true，管理员可以在 Allow 或 Block 策略里使用它，不需要维护自己的”看起来像 MCP”的域名清单。
直接加密流量必须经过 TLS 解密，Gateway 才能检查这些 header，本地 stdio 服务器、不走网络的连接、Do Not Inspect 流量和从不经过 Gateway 的请求仍在这个视野之外。
Cloudflare 还推出了专门的 MCP 流量仪表盘，显示网络里哪些主机在提供 MCP 流量、哪些用户在生成流量、请求是经过 Cloudflare MCP Portal 还是在绕过它们。
仪表盘显示：
- 可配置时间窗口内的 MCP 请求总数、唯一用户数和唯一服务器数
- 随时间变化的 MCP 服务器及每个服务器的请求计数
- 按入口分解的流量，区分 MCP Portal 流量和设备客户端直连
- Portal 外看到的 Top MCP 服务器——这是最重要的影子 MCP 流量
- 按 MCP 请求量排序的 Top 用户
管理员可以按特定服务器、用户或入口类型过滤，并直接跳转到按相关主机或用户过滤的 Gateway HTTP 日志做深度调查。
影子 MCP 和绕过审批路径是两个不同的问题
影子 MCP 是到组织未批准服务器的连接。员工在代码库、产品指南或同事消息里找到服务器，直接加到他们的 MCP 客户端。安全团队不知道它暴露了哪些工具或员工给它发了什么数据。
Portal 绕过不同：它从组织已批准并放入 MCP Portal 的服务器开始，但员工直接连到它的上游 URL，跳过了 Portal 的 Access 策略、精选工具目录、数据防泄漏和工具级审计跟踪。
Gateway 是受管网络路径上影子 MCP 的主要控制；它识别 TLS 检查过的 MCP 流量，显示目的地和用户，并能应用策略。Portal 绕过需要这个网络控制加上一个能拒绝直接请求的源，无论是 Access 策略、源 IP 限制，还是 MCP 服务器自己发起的企业授权机制。
从发现到强制执行
MCP 发现把未知流量变成管理员可以调查的清单。当组织批准其中一个服务器，可以把它放到 Cloudflare MCP Server Portal 后面。Portal 给员工一个受管端点，在上游服务器前放上 Access 身份、精选工具目录和日志。管理员可以让兼容的上游调用走 Gateway，用于 HTTP 策略、可预测的出口和数据防泄漏。工具活动还能通过 Logpush 导出。发现仪表盘然后能区分用 Portal 的请求和到同一服务器的直连。
这创造了一条从发现到治理的路径：找到服务器、决定是否批准、把批准的用途放到 Portal 后面、调查继续绕过它的流量。最后这步很重要，因为未批准的服务器和绕过批准服务器的行为是不同的问题。
Cloudflare 还给 Gateway Network 和 HTTP 策略加了 Traffic Source selector，让管理员能根据 MCP 流量是否来自 MCP Portal 来写规则控制。
当 MCP Portal 流量走 Gateway 时会带 mcp_portal Traffic Source，让策略能区分 Portal 代理的请求和员工直连。基线强制规则的逻辑是：检测到 MCP 流量且不来自 mcp_portal 入口，就拦截。
任何检测到的、没经过 Portal 的 MCP 流量都会被拦；经过 Portal 的流量不受影响。对于想先观察再强制的组织，Traffic Source 和 MCP 检测现在已存在于被解密流量的 HTTP 日志里，你可以监控代理流量的行为而不需要策略。
此外，MCP Portal 现在支持预注册的 OAuth 客户端。管理员可以配置手动 OAuth 凭证，在上游提供商那里注册仪表盘显示的回调 URL，然后输入客户端凭证。Portal 会在可用时发现标准 OAuth 元数据，管理员可以在发现不可行时提供 authorization、token、revocation 和 issuer 端点。
每个用户仍然授权访问他们自己的上游数据源，存储的 client secret 只用于获取更新的工具和提示列表。手动 OAuth 支持现在帮助覆盖 OAuth 实现的许多排列组合。