如何识别并管控 MCP 流量

AI Agent 正在改变企业权限管理面临的风险边界。

过去，企业通常围绕人工用户设计资源权限。工程师可能拥有生产部署、敏感数据库查询或撤销用户权限等能力，但操作速度和人工复核能力限制了风险扩散。AI Agent 则可能以非确定性的方式做出决策，并持续重复调用同一工具。一个看似合理但实际错误的判断，可能在人工发现之前演变成数千次错误操作。

Model Context Protocol（MCP）为 Agent 提供了发现和调用工具的通用方式。这些工具可能连接第三方 SaaS、内部应用和各种 API。问题在于，将 Agent 连接到 MCP 服务器通常只需修改一行配置，员工可以让 Claude Code、Codex、Cursor、OpenCode、VS Code 或其他 AI 工具直接连接未经审批的服务器。

为什么 MCP 流量难以识别

MCP 不要求服务器使用固定主机名，也不强制 URL 路径包含 /mcp。因此，直接连接到 MCP 服务器的请求，外观上可能与普通 HTTPS API 调用没有明显区别。

早期的识别方式主要依赖主机名和路径，例如搜索包含 mcp 的域名，或匹配 /mcp、/sse 等常见路径。这些信号仍可用于发现旧客户端产生的流量和回溯历史记录，但存在两个问题：

使用普通地址的 MCP 服务器可能被漏检，例如 https://tools.example.com/api。
非 MCP 服务也可能因为主机名或路径中包含 mcp 而被误判。

对于符合规范的 Streamable HTTP 客户端，协议请求头是更精确的识别信号。MCP 请求可以通过 MCP-Protocol-Version 等协议级信息进行判断；请求中的 Mcp-Method 和 Mcp-Name 还可以暴露具体操作和工具名称。

一次工具调用包含哪些信息

同一个 MCP 工具调用，在系统中通常表现为三种形式：

在客户端，它是 Agent 决定调用某个工具并传入参数。
在网络中，它是承载 JSON-RPC 消息的 HTTP 事务。
在服务器端，它会被解析并交给具体的工具处理器执行。

请求中可能包含以下信息：

目标主机名和路径
用于身份认证的授权凭证
MCP 协议版本
请求的方法和工具名称
JSON-RPC 请求 ID
params 中的工具参数

其中，工具参数往往最敏感。它们可能包含搜索内容、源代码、客户数据，也可能包含创建工单、修改基础设施等操作指令。工具名称体现 Agent 想做什么，参数则说明它准备发送哪些数据、执行什么动作。

如果调用成功，服务器会返回带有相同请求 ID 的 JSON-RPC 响应，其中可能包含敏感结果。因此，检查请求可以在操作执行前阻止风险，检查响应和记录日志则有助于了解工具返回了什么。

三个控制位置

1. MCP 客户端

客户端钩子可以在模型选定工具、客户端序列化请求之前运行。此时可以直接看到目标服务器、工具名称和调用参数，而不必解密网络流量。

客户端侧可以执行以下控制：

拒绝不在允许列表中的服务器
对敏感操作请求用户确认
在数据离开设备前移除部分参数
覆盖本地 stdio MCP 服务器

本地 stdio 服务器不会产生网络流量，因此网络层无法观察这类调用。

客户端控制的难点在于标准化。企业需要在员工使用的每一种客户端上重复部署控制策略，而且单个客户端提供的遥测信息无法形成完整的 MCP 使用清单。客户端和设备都由企业统一管理时，这类控制更容易发挥作用。

2. 设备网络边界

安全 Web 网关可以在请求离开客户端后观察 HTTP 流量。结合 TLS 解密，网关能够将请求关联到用户和设备，检查目标地址及协议请求头，并在不依赖特定 MCP 客户端的情况下执行策略。

网络层的优势是覆盖面更广，可以识别受管网络路径上的远程 MCP 流量，并在请求到达目标服务器前阻止未经批准的直接连接。支持数据防泄漏扫描时，代理还可以检查 JSON-RPC 方法和参数中的敏感数据。

但网络代理也有边界：

无法看到本地 stdio 调用
无法覆盖设备处于受管网络之外时产生的流量
设备必须实际运行代理或网络客户端
MCP 服务器或门户需要验证连接是否经过了规定的代理路径

3. MCP 服务器执行工具前

服务器拥有最完整的执行上下文。它已经完成调用方认证，解析了 MCP 消息，将 get_weather 等名称映射到具体处理器，并根据工具输入模式验证参数。

这也是工具真正执行前的最后一个拒绝点。服务器中间件可以：

针对具体工具授权调用方
限制调用频率
检查请求参数
记录执行结果
在处理器运行前拒绝请求

对于会写入数据或触发外部动作的工具，这些检查应当在调用处理器之前完成。只在执行后记录日志可以解释发生了什么，但无法阻止已经发生的操作。

服务器侧控制的优势是难以被终端用户通过更换客户端或关闭本地钩子绕过。它的局限是只能保护实现了相应控制的服务器。

组合使用控制措施

三层控制各有侧重：

客户端最早看到工具决策和参数，适合在数据离开设备前控制调用。
网络层覆盖面最广，适合发现远程 MCP 流量和未经批准的连接。
服务器端拥有最丰富的执行上下文，适合在工具运行前执行细粒度授权和风险检查。

Cloudflare One 的相关能力包括：通过受管设备客户端将流量发送到 Gateway，在协议层对 MCP 请求进行分类，并区分流量是否来自获批的 MCP Server Portal。管理员可以据此发现未纳入管理的 MCP 流量，报告违规连接，或阻止未经过批准路径的直接访问。

这种组合方式可以覆盖不同位置的风险：在数据离开设备前进行检查，发现未登记的远程 MCP 使用情况，并在工具执行前拒绝未授权操作。不过，任何一层都不能单独覆盖所有场景，尤其是本地 stdio 调用和离线网络流量。

对企业管理的启示

MCP 安全管理不能只依赖 URL、域名或单个客户端的日志。更可靠的识别方式需要结合协议级信号、用户和设备身份，以及服务器端的执行控制。

对于企业而言，较完整的治理路径包括：

盘点员工使用的 MCP 客户端、服务器和工具。
通过协议请求头和 JSON-RPC 内容识别远程 MCP 流量。
为批准的 MCP 服务器建立统一访问路径。
在网络边界阻止绕过门户或代理的直接连接。
在服务器端对工具、参数和操作风险进行授权。
对敏感读取、写入操作和外部动作保留审计记录。

最终，MCP 的风险不只取决于工具本身拥有的权限，也取决于谁在作出调用决策、调用可以多快重复，以及企业能否在执行前看到并控制这些请求。