更新日期：2026-08-31
MCP（Model Context Protocol）把 AI 客户端与文件、数据库、工单、代码仓库和内部 API 连接起来，也把传统 SaaS 管理问题放大了一层：员工可以在桌面客户端里自行添加远程 MCP server，Agent 则可能在一次对话里读取敏感数据、调用高风险工具，再把结果发送到另一个服务。没有资产清单、统一身份和网络策略的组织，很快就会出现 Shadow MCP。
Cloudflare 在 2026 年 8 月为 Gateway 加入 MCP 流量检测与 AI Security Dashboard，并扩展 MCP Portal 的治理能力；Agents SDK 也开始支持 2026-07-28 版 MCP 规范。它们能帮助企业从“看见远程 MCP”走向“只允许受控入口”，但不能单独解决本地 stdio、未经过 Cloudflare 的连接、工具级授权和提示注入。
本文给出一条可渐进上线的路径：先建立威胁模型和可见性基线，再用 Portal 统一远程入口，最后才启用 Gateway 阻断；同时在 MCP server 内保留身份、最小权限、参数校验、审批与审计，避免把网络层识别误当成应用层授权。
先理解 2026-07-28 版 MCP 发生了什么
MCP 2026-07-28 规范对远程交互做了明显简化：核心协议变为无状态，不再要求 initialize 握手与持久 session；请求通过 Mcp-Method、Mcp-Name 等头部表达意图，并可使用 server/discover、列表缓存提示、授权强化和扩展机制。官方 Tier 1 TypeScript、Python、Go、C# SDK 已更新。
这对治理有两个直接影响。
第一，不能继续把“看到了初始化调用或某条固定路径”作为唯一发现方式。新版协议减少会话状态，网络检测要依赖协议头、流量上下文和目标服务等多种信号。
第二，新旧客户端会长期并存。Cloudflare Agents SDK 0.20.0 支持 2026-07-28 无状态规范，并为旧版本保留兼容回退；企业迁移策略也应允许受控 Portal 同时服务新版与 2025 Streamable HTTP 客户端，而不是一刀切地把所有旧流量都判为恶意。
Shadow MCP 的风险不只是“多了一个 SaaS”
一个远程 MCP server 往往同时具备三个能力：读取上下文、返回不受信任内容、执行工具调用。风险因此跨越多层：
- 数据泄露：Agent 把工单、代码、客户资料或访问令牌发送给未审批 server；
- 权限混淆：用户以个人身份连接，server 却用共享管理员凭据访问后端；
- 提示注入：工具返回内容诱导 Agent 调用其他工具或泄露上下文；
- 工具滥用：看似只读的工具实际支持任意查询、文件路径或 shell 参数；
- 供应链变化：相同域名上的 server 更新工具定义，能力超出最初审批范围；
- 审计断层：只能看到 HTTPS 目标，无法回答哪个用户调用了哪个 MCP 方法；
- 本地旁路：stdio server 在终端本机运行，完全不经过远程 HTTP 检测面。
所以治理对象不能只有域名。至少要记录“用户—客户端—Portal—server—工具—后端资源”这条链路，并区分网络可见、身份允许与工具实际授权三个不同判断。
三个控制点：客户端、网络、服务端
Cloudflare 官方把 MCP 安全分为三个控制点，这个模型很适合用于责任划分：
| 控制点 | 能解决什么 | 不能单独解决什么 |
|---|---|---|
| 客户端 | 限制可配置 server、展示工具确认、保护本地凭据 | 无法验证服务端是否越权访问后端 |
| 网络/Gateway | 发现远程 MCP、限制目标、DLP、统一 Portal 入口 | 看不到本地 stdio、离网和 Do Not Inspect 流量 |
| MCP server | OAuth、工具授权、参数校验、速率限制、审计 | 无法发现员工连接的其他 Shadow MCP |
成熟设计会同时使用三层。网络层适合回答“是否绕过批准入口”，服务端适合回答“这个人能不能调用这个工具”，客户端则负责在高风险动作前让用户理解即将发生什么。
第一步：先观察，不要第一天就全量阻断
Cloudflare Gateway 当前可以识别经过 TLS 检查的 MCP 请求，并在 AI Security Dashboard 聚合 MCP 流量、用户、server 与接入路径。检测会利用 MCP-Protocol-Version 等特征；如果请求没有该头部，不代表它一定不是 MCP。
开始前先确认范围：
- 目标用户和设备流量确实通过 Cloudflare One；
- 对相关 HTTPS 流量启用了合规的 TLS inspection；
- 隐私、员工告知、证书部署和地区法规已经评审；
- Do Not Inspect 域名、非公司设备和离网流量已单独列为盲区；
- 本地 stdio server 由端点管理、应用控制或开发机基线覆盖。
第一阶段只观察 7 至 14 天，不配置阻断。为每个发现的目标补充：
- 域名与 server 所有者；
- 使用人群和业务目的；
- 身份方式与 token 存储位置；
- 可见工具及其读写能力；
- 处理的数据等级；
- 后端权限与日志保留；
- 是否已有批准的 Portal 替代入口。
不要仅凭流量次数判断风险。一个每天调用数千次的只读文档 server，可能比一个每月调用一次但能删除生产数据库的工具风险更低。
第二步：建立 MCP 资产与工具目录
建议用两个层级记录资产。
server 级字段包括：
- 业务名称、远程 URL、协议版本和 transport；
- 业务 owner、安全 owner、供应商与数据处理地区；
- OAuth issuer、audience、scope 与 token 生命周期；
- Portal 名称、Gateway 策略和 DLP profile；
- 上次安全评审时间、到期日与退出方案。
工具级字段包括：
- Mcp-Name 或工具名、说明和版本；
- 输入 schema、输出数据等级与副作用；
- 只读、可逆写、不可逆写或管理员操作；
- 所需后端权限；
- 是否需要用户确认、二人审批或变更单；
- 速率上限、幂等键和审计字段。
资产目录不能只抓一次 tools/list 就永久有效。新版规范包含列表缓存提示，server 也可能随发布改变能力。治理系统应在缓存失效、server 版本变化或固定周期重新抓取，并对新增的高风险工具自动暂停批准状态。
第三步：用 MCP Portal 统一远程入口
Cloudflare MCP Portal 为远程 HTTP MCP server 提供统一 endpoint。客户端只配置 Portal，Portal 再按已配置 server 路由请求，并能结合 Gateway、DLP 与出口控制。它支持 2026-07-28 无状态规范，也兼容较早的 2025 Streamable HTTP。
实施顺序建议如下：
- 先选择一组低风险、只读 server 作为试点；
- 为 Portal 定义允许用户或群组，以及设备姿态、国家/地区等条件；
- 配置上游 server 与各自 OAuth/管理员凭据；
- 让试点客户端只连接 Portal endpoint；
- 验证身份映射、DLP、server 选择、审计和故障行为；
- 再逐步迁移写操作与更多团队。
Portal 不是“把任意 URL 填进去就自动安全”。当前文档列出多项限制：
- 只代理远程 HTTP MCP；本地 stdio 要先由组织自建受控 HTTP 层，且要重新评估暴露风险；
- 某些上游会拒绝代理请求并返回 403，需要兼容性验证；
- 手工 OAuth 能力同步存在限制；
- 管理员 token 可能静默过期，目前没有到期通知；
- 默认每个 Portal 最多配置 40 个 server；
- 使用 Portal 身份时，独立 MFA、用途说明、临时授权等部分 Access 条件当前不受支持。
因此应为管理员 token 建立外部到期监控和轮换日历，为 403/401 设置告警，并预留直连关闭前的兼容窗口。Portal 限制是架构输入，不能等生产流量切换后才发现。
第四步：从可见性过渡到 Gateway 策略
Cloudflare 于 2026-08-12 提供 experimental.is_mcp Gateway selector。顾名思义，它目前仍是 Beta，字段名与行为可能变化；上线前应重新核对 changelog 和 dashboard 实际 schema，基础设施即代码也要允许安全升级。
一个实用的策略分层是：
- Allow approved portal：批准人群可以访问组织 Portal；
- Observe direct MCP：识别 MCP 但流量来源不是 Portal 时记录事件；
- Block direct MCP：观察期确认误报与业务例外后，阻止绕过 Portal 的远程 MCP；
- Restrict unknown destinations：结合域名类别、应用控制与 DLP 处理未识别 AI 工具；
- Break glass：限时、实名、审批的紧急例外，自动到期并复盘。
Cloudflare 官方示例的核心逻辑是“Is MCP 为 true，并且 Traffic Source 不是 MCP Portal”时阻断。实际部署应在 dashboard 中选用当前可用字段，不要把 Beta selector 复制进长期 Terraform 模块后无人维护。
策略上线先使用 Audit/Do not block 类观察动作，核对：
- 合法 Portal 请求是否被正确标记来源；
- 旧客户端是否缺少检测头而形成漏报；
- 普通 API 是否被误判为 MCP；
- TLS inspection 例外是否覆盖关键用户；
- IPv6、移动网络和远程办公路径是否与预期一致。
确认以后再按部门逐步阻断。一次全公司切换容易把插件升级、客户演示和应急运维同时打断，也难以判断具体兼容问题来自客户端、Portal、OAuth 还是 Gateway。
第五步：DLP 只能减少泄露，不能理解工具意图
Portal 与 Gateway 可以对经过的请求应用 DLP，适合识别 API key、个人信息、源代码标记或组织自定义敏感模式。但 DLP 并不理解“把这段普通文本写入生产公告”是否符合业务授权，也无法保证经过模型改写后的秘密仍能被正则识别。
建议区分三类动作：
- 阻断型：明确凭据、私钥、支付卡数据等不应发送到外部 server；
- 审计型：源代码、工单、客户标识等需要结合业务上下文；
- 工具级审批型：删除、付款、发信、部署等必须由 server 授权与用户确认控制。
高风险工具不要只依赖“模型会先问用户”。server 应拒绝未授权 scope，校验资源 owner，限制目标集合，并对不可逆操作要求业务幂等键或审批 token。提示注入可以影响 Agent 的选择，但不能改变服务端最终授权结果。
第六步：MCP server 必须做真正的应用层授权
即使请求只能从 Portal 到达，server 仍应把每次工具调用当作不可信输入：
- 验证 issuer、audience、签名、过期时间和授权 scope；
- 将最终用户身份映射到后端资源，不使用共享超级管理员身份代替用户授权；
- 按工具和资源做授权，而不是“能连 server 就能调所有工具”；
- 使用 JSON Schema 做类型、长度、枚举和格式校验；
- 文件路径、SQL、URL、shell 参数采用允许列表，不拼接原始输入；
- 写操作支持幂等键，避免 Agent 重试造成重复副作用；
- 对删除、付款、发布、权限修改等不可逆动作增加显式确认；
- 记录调用者、client、server、工具、资源、结果与关联 ID，但避免记录秘密全文。
对网络访问工具，还应阻止 SSRF：限制 scheme、解析后的 IP 范围、重定向次数和 DNS rebinding，拒绝 link-local、loopback、云 metadata 和内部管理网段。Portal 能统一入口，却不会自动让一个接受任意 URL 的抓取工具变安全。
第七步：处理网络层看不到的 stdio MCP
本地 stdio server 通过进程标准输入输出与客户端通信，不经过 Cloudflare Gateway 的远程 HTTP 检测。治理它要靠端点而不是假装网络日志里能看到：
- 使用设备管理限制可安装的 AI 客户端和扩展；
- 对客户端配置目录设置基线、允许列表和变更监控；
- 限制 npx、包管理器、脚本解释器的任意执行；
- 开发机凭据使用短期身份和最小 scope，不把生产 token 放入全局环境；
- 对本地 server 的代码来源、版本、hash 和更新机制建立清单；
- 通过 EDR/应用控制观察新进程、网络子进程和持久化行为。
如果为了纳入 Portal 而把 stdio server 包装成 HTTP 服务，必须新增 OAuth、网络边界、并发、速率限制和租户隔离。把本地监听端口直接暴露到公司网络会扩大攻击面，并不是“治理升级”。
日志、告警与事件响应
一条可调查的 MCP 审计记录至少需要：
- 时间、用户、设备、client 与请求关联 ID；
- Portal、上游 server、协议版本、MCP method/name；
- 工具风险等级与目标资源标识；
- Gateway/DLP/server 授权决定；
- 状态码、延迟、重试和副作用结果；
- 策略版本与例外单号。
不要记录 OAuth token、完整 prompt、客户数据或工具返回全文来“提高可观察性”。日志字段应按数据最小化设计，敏感内容用分类标签、hash 或受限取证存储代替。
优先告警以下事件：
- 用户首次连接未知 MCP server；
- 直接 MCP 绕过 Portal；
- Portal 管理员凭据出现 401/403 或临近轮换日期；
- server 突然新增高风险工具；
- 同一用户短时间跨多个 server 读取再外发；
- 高风险工具重复调用、异常参数或大量拒绝；
- DLP 命中后继续尝试编码、拆分或更换目标。
事件响应时可先关闭单个 server 或工具、撤销上游 token、暂停相关用户，再判断是否需要全局阻断 Portal。保留策略版本和关联 ID，才能把 Gateway 事件、Portal 路由、server 日志与后端变更串起来。
推荐的分阶段上线方案
阶段 A：发现
启用合规的 TLS inspection 与 Dashboard 观察，盘点远程 MCP、Do Not Inspect 和本地 stdio 盲区。只记录，不阻断。
阶段 B：试点 Portal
迁移少量只读 server，验证身份、DLP、OAuth 续期、旧/新协议兼容和故障降级。建立 token 到期外部提醒。
阶段 C：限制直连
使用 Beta MCP selector 建立观察策略，确认误报后按团队逐步阻断“是 MCP 且来源不是 Portal”的流量。紧急例外必须自动到期。
阶段 D：工具级治理
把资产目录推进到工具级，按读写风险设置 scope、审批、速率、幂等和日志。新增/变更工具触发重新评审。
阶段 E：持续验证
定期测试本地旁路、无检测头请求、Do Not Inspect 路径、管理员 token 过期、Portal 403、DLP 绕过和高风险工具越权。Cloudflare Beta 字段或 MCP 规范升级时重新验证策略。
回滚不应恢复不受控直连。某个 Portal 兼容性故障时，可以临时只允许确切用户、设备和目标域名的限时例外，同时保留日志；修复后自动收回。对不可逆工具，网络异常不能触发 fail-open。
上线检查清单
- 已区分远程 HTTP、Do Not Inspect、离网与本地 stdio 覆盖面；
- 已完成用户、client、server、工具、后端资源的资产映射；
- TLS inspection、隐私与员工告知已通过组织评审；
- Portal 先从只读 server 试点，且验证新旧 MCP 版本；
- 已处理 Portal 40-server、OAuth、403 与 token 到期限制；
- Gateway Beta selector 先观察后阻断；
- direct MCP 例外实名、限时、自动到期；
- MCP server 按最终用户和工具执行授权；
- 高风险写操作具有确认、幂等和审计；
- stdio MCP 由端点管理覆盖；
- 日志不保存 token 与无必要的 prompt 全文；
- 已演练 Portal 故障、凭据过期、策略误报与撤销流程。
Cloudflare 提供的是一组很有价值的控制面：Gateway 让 Shadow MCP 从不可见变为可调查，Portal 把分散的远程入口集中起来，DLP 和身份策略降低数据外流风险。但最终安全边界仍然是组合式的。只有网络检测、端点治理和 server 工具授权同时落地，MCP 才能从“每个员工自己连插件”变成组织可以持续运营的基础设施。
