Cloudflare：MCP 检测如何将影子 Agent 流量转化为安全决策

Cloudflare 已将 MCP 流量检测扩展到明显的服务器名称之外，揭示了一种安全团队过去可能忽略的冲突。如今，Cloudflare 如何检测的问题，起点是协议证据，而非已知域名列表。Gateway 可以检查受管 HTTP 流量中的 MCP 特定路径和 JSON-RPC 方法，随后区分获批的 Portal 流量与直接连接。

这一差异至关重要，因为 Model Context Protocol（MCP）让 AI Agent 能够调用外部工具并获取私有数据。单个连接可能触及源代码、客户记录、云端控制系统或消息传递系统。当员工未经审查便配置远程服务器时，由此产生的影子 MCP 活动类似影子 IT，只是其中的 Agent 还具备执行操作的能力。

Cloudflare 的解决方案将发现与执行路径结合起来。Gateway 提供网络信号，MCP server portals 则将获批服务器集中到一个端点之后。Access 策略管理身份和设备条件，数据丢失防护（DLP）则可以检查工具请求与响应。尚未解决的问题是，组织能否将足够多的流量导入这些控制措施，使该模型足够可靠。

Cloudflare 如何通过协议识别 MCP 检测

Cloudflare 的重要变化，是从猜测目标地址转向识别受检 HTTP 流量中的 MCP 行为。

最简单的检测方法是查看目标主机名。管理员可以在 Gateway 日志中搜索已知的 MCP 端点，或包含 mcp 的主机名。这种方法能够捕获通过名称表明其用途的服务，例如 mcp.example.com。

第二个信号来自请求 URI。远程服务器通常会暴露 /mcp、/sse 或 /mcp/sse 等路径。即使主机名本身看起来很普通，Gateway 也能在记录的请求中搜索这些模式。

这两种方法都适用于初步盘点，但都无法证明请求承载了 MCP。普通应用也可能使用相同路径。MCP server 同样可以隐藏在常规主机名和不起眼的 API 路径之后。

因此，Cloudflare 建议管理员进行请求体检查。MCP 使用 JSON-RPC 编码消息，这是一种结构化请求格式，包含 jsonrpc、method 和 params 等字段。标准方法名称会产生可识别的协议层证据。

示例包括 initialize、tools/list、tools/call、resources/read 和 prompts/get。即使域名和路径没有透露任何信息，DLP 配置文件仍可在 POST 请求体中搜索这些字符串。Cloudflare 在其 MCP architecture 中发布了示例正则表达式，涵盖多种常见方法和协议版本字段。

initialize 方法尤其有用，因为它开启了 MCP 客户端与服务器之间的关系。客户端会声明其协议版本、能力、名称和版本。服务器则以自身能力作出响应，并可能创建会话。

工具调用会产生更强的操作信号。包含 tools/call 的请求表明 Agent 正尝试调用某项能力，而不只是确认端点是否存在。参数还可能揭示该工具将处理哪些数据或操作。

因此，Cloudflare 的检测模型是分层的：

• 主机名模式识别已知或名称明确的 MCP servers。

• URI 模式识别常规的远程 MCP 端点。

• JSON-RPC 方法识别不那么明显端点上的 MCP 行为。

• 用户和设备字段将该行为关联到个人或受管系统。

• Gateway 操作显示请求是被允许、阻止，还是以其他方式处理。

Cloudflare 记录的工作流程使用其 GraphQL Analytics API 中的 gatewayHttpRequestsAdaptiveGroups 数据集。管理员可以按主机、URI、用户、操作和匹配的 DLP 配置文件对结果分组。根据该公司的 detection tutorial，该数据集支持最多 30 天的历史查询。

这并非最广义上的内容感知型威胁检测。匹配 tools/call 仅说明某个 MCP 工具被调用，并不能判断该工具是否可信、其指令是否恶意，或该操作是否符合用户意图。

不过，协议识别弥补了一个重要的可见性缺口。安全团队在开始调查前，不再需要了解每一家 MCP 供应商或每个端点。它们可以搜索协议本身的特征。

这就形成了本文的核心张力。检测能够揭示直接 MCP 流量，但单一信号并不能判定哪些连接应继续可用。在管理员阻止非受管路径而又不影响合法工作之前，Cloudflare 需要先提供一种可治理的替代方案。

影子 MCP 让安全团队在访问与采用之间左右为难

眼下的压力落在安全团队身上：它们必须将有用的 Agent 连接与未经审查、可访问敏感系统的连接区分开来。

MCP 规范化了 AI 应用发现工具、读取资源、获取提示词和调用操作的方式。该协议减少了自定义集成工作，同时也让员工和开发者更容易在没有集中部署项目的情况下添加服务器。

这种速度带来了熟悉的治理问题。用户可以为 MCP 客户端配置远程服务器 URL，并通过 OAuth 或其他凭证授予访问权限。安全团队可能从未在其获批软件目录中看到这一设置。

风险远不止于访问未经授权的 Web 应用。MCP server 会向 Agent 暴露工具，而这些工具可能携带重要权限。视集成情况而定，它们可能搜索文档、读取代码库、打开支持记录、修改基础设施或发送消息。

合法工具仍可能接收不恰当的数据。员工可能要求 Agent 分析客户问题，随后在不知情的情况下将受监管信息发送给外部服务器。遭入侵或具有欺骗性的服务器也可能返回旨在操纵后续 Agent 行为的指令。

这正是 Cloudflare 将非受管连接称为影子 MCP 的原因。关键不在于每个未知服务器是否都具有敌意，而在于组织尚未审查该服务器、其运营者、其请求的权限或流经其中的数据。

Gateway 日志能够将这种未知活动转化为库存清单。管理员可以识别用户、目标主机、请求量、策略操作和检测到的协议方法。随后，他们可以调查是哪一个客户端产生了流量，以及它服务于何种业务目的。

这份清单也支持更审慎的执行方式。团队可以先记录初始匹配项，审查活跃目标，并在阻止任何连接之前对每台服务器进行分类。高置信度案例，例如直连未经批准的远程工具，可以适用更严格的策略。

不过，受管网络覆盖范围界定了边界。Gateway 必须主动代理相关 HTTP 流量。如果员工使用非受管设备、独立网络路径，或组织控制范围外的客户端，这些请求就不会出现在相同日志中。

加密流量带来了另一项条件。Gateway 需要 TLS 解密，才能检查直接 MCP 连接的 HTTP 请求体。否则，管理员或许能够看到目标主机名，却会错过 JSON-RPC 方法和工具参数。

Cloudflare 对 Portal 流量的处理方式不同。Portal 会终止客户端连接，并向上游服务器创建新的连接。这一架构让 Gateway 能够检查经由 Portal 路由的流量，而无需依赖全账户范围的 TLS 解密设置。

直接流量不会获得这种自动处理。Cloudflare 的 Portal documentation 表示，Agent 通过受 WARP 管理的设备直接连接时，仍需要常规 TLS 解密配置才能进行请求体检查。

也存在将流量排除在检查之外的正当理由。隐私要求、证书固定应用或运营限制，都可能促使团队创建 Do Not Inspect 策略。这些策略具有优先级，可能令匹配的 MCP 活动无法进入 DLP 分析范围。

这些限制并不会让检测失去价值。它们界定了最终仪表板实际代表的含义。报告展示的是在受检、受管路径上可见的类 MCP 活动，而不是公司内所有 Agent 连接的完整普查。

这一差异应当塑造事件响应方式。检测到的连接值得调查，但空报告并不能证明不存在影子 MCP。安全团队还需要端点覆盖、身份数据和客户端配置控制，并将其与网络检测结合。

真正的较量是 Portal 访问与直接连接之间的较量

只有当获批的 Portal 访问在受管路径上取代直接服务器 URL 时，Cloudflare 的安全模型才能真正得到执行。

MCP server portal 将多台获批服务器聚合到一个 HTTP 端点之后。用户在其 MCP 客户端中配置该端点，通过 Cloudflare Access 进行身份验证，并只能获得策略允许的服务器和工具。

Portal 承担了直接连接分散在各个集成中的多项工作。它识别用户、评估 Access 规则、管理上游身份验证、暴露获批工具并记录请求。管理员可以组织服务器，而无需让每位员工维护单独的端点列表。

Access 策略可以使用身份组、位置和设备态势。财务 portal 可以向财务员工暴露选定的只读工具。工程 portal 则可以仅允许受管企业设备执行额外操作。

管理员还可以隐藏单个工具或提示词。这一点很重要，因为批准一台服务器并不意味着要批准它发布的每一项能力。具有代码库访问权限的服务器，可能暴露搜索和读取操作，而其写入操作仍不可用。

Cloudflare 的 Portal 设计支持未进行身份验证的上游服务器，以及受 OAuth 保护的服务器。用户可以单独向上游服务进行身份验证，某些机器对机器工作流则可以使用 Access service tokens。Portal 随后会在代理工具调用时附加适当凭证。

启用 Gateway 路由后，实时调用会先从 Portal 经过 Gateway，再到达上游服务器。Gateway 会记录这些请求，并可应用 HTTP 和 DLP 策略。出口控制还可以为这些请求提供可预测的源地址。

这形成了一种实用的允许与阻止模式。安全团队为员工提供获批的 Portal 端点，然后创建 Gateway 规则，阻止直接连接上游 MCP servers。Portal 路径保持可用，而不受治理的替代方案则受到限制。

策略必须针对正确的目标。Cloudflare 表示，针对 Portal 流量的 DLP 规则应匹配上游 MCP server 主机名，而不只是 Portal 域名。Portal 是面向客户端的入口点，但 Gateway 评估的是重新发起、正前往实际服务器的请求。

这种安排更像一个应用网关，而非简单目录。它提供了一个汇聚点，让身份、工具选择、日志记录和数据控制在此交汇。正是这个汇聚点，将发现转化为治理。

然而，直接 URL 仍然是一个核心弱点。Cloudflare 警告称，即使将服务器从 Portal 中隐藏，也无法阻止用户连接其原始地址。如果上游服务器仍可公开访问，仅靠 Portal 策略无法阻止绕过行为。

因此，组织需要在 Portal 界面之外实施控制措施。当组织控制服务器的主机名时，可以用 Access 保护服务器；也可以将入站流量限制为已知出口地址，或通过 Gateway 阻止直接访问目标。第三方服务则需要采用其部署模式所支持的控制措施。

这并不是 Cloudflare 与另一家安全厂商之间的选择。核心对立在于：受治理的 Portal 访问与用户自行配置的直接连接。每一项主要功能都服务于这场对抗。

Portal 日志识别获批活动。Gateway 发现机制寻找未走获批路径的流量。Access 确定谁可以使用 Portal。DLP 评估穿越受管路径的数据。网络策略则试图封闭直接路径。

这一模式也在实施管控后为开发者提供了可用的去处。全面禁止 MCP 会将试验活动推向官方渠道之外。经过筛选的 Portal 则允许团队继续使用获批工具，同时由安全团队审查新增服务器。

结果取决于运营纪律。必须有人负责获批服务器目录、审核工具权限、维护 Access 策略，并响应新发现的目标地址。集中化能减少分散的控制措施，但并不会消除这些决策。

协议启发式规则带来覆盖，而非确定性

Cloudflare 可以识别出强烈的 MCP 指标，但这些指标并不能证明某个连接是安全的、恶意的，或得到了正确治理。

这些检测模式本质上是启发式规则。包含 "method":"tools/call" 的请求体与 MCP 高度相似，但其他 JSON-RPC 应用也可能使用相同的方法名。自定义 MCP 实现也可能产生超出严格正则表达式范围的格式。

对空白字符的允许程度说明了这一问题。示例表达式允许 JSON 字段周围存在有限空格。当每个模式只针对一个字段时，字段顺序变化仍应能够被检测到，但不同的序列化和转义方式会使匹配复杂化。

加密或不受支持的流量会造成更大的缺口。除非 Gateway 解密，否则 DLP 无法检查直接 HTTPS 请求体。本地 MCP 服务器通过标准输入和输出通信，则根本不会经过 HTTP 网关。

在 Cloudflare 当前设计中，Streamable HTTP 是最重要的远程传输方式。MCP transport specification 定义了携带 JSON-RPC 消息及可选会话标识符的 HTTP 请求。这些规则化结构有助于 Gateway 识别协议。

Cloudflare 的经路由 Portal 路径支持 Streamable HTTP。如果上游服务器仅支持较旧的 Server-Sent Events 传输方式，Gateway 路由将无法为该服务器工作。启用路由时，Portal 会尝试使用 Streamable HTTP，但上游服务必须支持它。

后台同步是另一项例外。Portal 会定期从上游服务器获取工具和提示词，但 Cloudflare 表示，这些同步请求不会经过 Gateway。只有实时用户工具调用才能获得文档中所述的经路由检查。

DLP 覆盖范围也存在产品特定限制。Cloudflare 表示，其 AI 提示词配置文件不适用于 MCP Portal 流量，因为这些配置文件预期的是不同的 API 路径和格式。管理员必须使用标准 DLP 配置文件。

“不检查”规则对 Portal 流量仍然有效。尽管 Portal 路由允许自动解密，但明确的豁免会阻止对载荷进行检查。因此，范围过宽的例外规则可能会取消对已获批上游服务器的 DLP 保护。

身份策略同样存在注意事项。Cloudflare 文档指出，对于通过 Portal 获得授权的服务器，独立 MFA、用途说明和临时身份验证不会得到强制执行。电子邮件、群组、国家/地区和设备状态选择器仍然适用。

这些限制很重要，因为 Portal 看起来可能比其实际策略路径更严格。管理员可能会为服务器配置某项要求，并假定用户在通过 Portal 授权时会遇到它。Cloudflare 文档称，多项逐级加强控制并不会以这种方式生效。

安全团队还应将协议检测与语义安全区分开来。某个请求可能经过获批 Portal、未匹配任何 DLP 规则，却仍触发不安全操作。DLP 查找的是定义好的数据模式，而不是删除项目是否符合用户意图。

工具注入带来了相关问题。上游服务器可以返回会影响代理下一步决策的内容。网络检查或许能够记录或阻止敏感字符串，但不一定能识别隐藏在其他有效内容中的操纵性指令。

反过来也一样。影子 MCP 连接并不自动构成安全事件。开发者可能只是在测试无害的公共数据源。该连接仍未受到治理，但其业务和安全影响需要结合上下文判断。

因此，误报与漏报应成为运营模式的一部分。团队应将主机名和 URI 匹配视为线索，再利用请求体信号、用户归因、客户端数据和服务器审查作出决策。高影响力的阻断规则不应仅依赖通用路径匹配。

分阶段部署可以减少干扰。管理员可以先从日志记录开始，建立对预期 Portal 流量的认知，并识别常见直接目标地址。随后，他们可以阻止高置信度的影子连接，同时为新服务器建立审批流程。

最强的方案会结合网络和端点控制。Gateway 可以看到穿越受管路径的远程流量。端点管理可以控制用户安装哪些客户端和配置。Access 与上游限制则会在已存在获批路径后增加绕过难度。

Cloudflare 已为这种架构提供了组成部分，但并没有消除设计它的必要性。

三项信号将显示 Cloudflare 的 MCP 模式是否站得住脚

下一项考验在于，企业能否将 MCP 可见性转化为一致的路由、有意义的阻断和可衡量的工具治理。

第一项信号是：检测到的流量中，有多少转而通过获批 Portal 域名。初始 Gateway 搜索很可能会发现已知服务、试验项目和误报的混合体。当获批替代方案上线后，直接 MCP 活动下降，这一模式才会更具可信度。

安全团队应将此衡量为路由结果，而不仅是阻断数量。被阻断请求数量上升可能说明策略有效，但也可能表明用户仍在尝试绕过获批路径。成功迁移意味着合法活动持续通过 Portal 进行。

第二项信号是工具和数据层面的策略质量。若 Portal 暴露了每个获批服务器的所有能力，那么它只是集中化了访问，而没有施加多少约束。更强的部署会筛选工具、使用身份条件，并对请求和响应都应用 DLP 配置文件。

当出站内容匹配标准 DLP 配置文件时，Cloudflare 的 Gateway 可以阻止工具请求。当上游服务器返回匹配的敏感数据时，它也可以阻止响应。MCP 客户端将收到错误，而非受保护内容。

当组织针对实际工作流调整这些控制措施时，它们会更有价值。凭据、财务信息、客户标识符和专有文档承载着不同风险。阻止一切的策略会令用户受挫，而从不触发的策略则几乎无法提供保护。

安全团队应跟踪被阻断的工具方法、匹配的数据类别、受影响的服务器以及用户结果。他们还应审查代理是否反复重试被阻断的请求。重复尝试可能反映出不佳的客户端行为，或某个工作流需要更安全的获批设计。

第三项信号是 Cloudflare 与 MCP 生态系统弥补已知覆盖缺口的速度。Streamable HTTP 的采用应减少无法使用 Gateway 路由的上游服务器数量。更完善的端点控制可以提高对本地和未受管理配置的可见性。

协议变化同样重要。围绕当前 JSON-RPC 方法构建的检测模式，必须随着规范演进而更新。稳定的请求头或其他标准化传输信号可能使分类更容易，但安全团队不应假定每个客户端都会立即采用新字段。

竞争对手的行为会提供另一条线索，但不会改变核心对立。安全 Web 网关和端点厂商很可能加入各自的 MCP 分类、服务器清单或代理控制能力。这种压力能够改进检测方法，也会暴露纯网络方案的不足之处。

Cloudflare 的优势在于架构集成。其 Portal、Access、Gateway、DLP、出口和应用控制可参与同一条策略路径。其挑战在于证明客户能够配置这些组件，而不会留下实质性的绕过途径。

因此，Cloudflare 的实现故事并不关乎单一检测器，而是一个反馈循环：发现直接 MCP 流量、调查、批准必要服务器、通过 Portal 对其路由，并阻止未受管理的路径。随后随着用户采用新工具而重复这一过程。

考虑这一模式的组织应从一个实际问题开始：如今，他们的安全团队究竟能够观察到哪些受管网络路径和代理客户端？

在此基础上，他们可以盘点 MCP 信号，将其与获批 Portal 流量进行比较，并选择具备足够置信度的执行位置。目标并非将每个 MCP 连接都标记为危险，而是确保代理通过组织能够进行身份验证、检查和审计的路径访问敏感工具。