MCP 治理面成型：ServiceNow、Rubrik、Microsoft 三家企业的协议层 enforcement 实践
2026 年 9 月 10 日至 17 日，一周内三家重量级企业相继发布了 MCP 层的策略 enforcement 产品：
- 9 月 10 日：ServiceNow AI Gateway v3.4，MCP 运行时强制 + 服务器生命周期管理
- 9 月 15 日：Rubrik MCP，与 Anthropic 联合工程，OWASP MCP Top 10 对齐的护栏 + 按工具调用 mint 的短期令牌
- 9 月 17 日：Microsoft Entra Agent ID 扩展 MCP Firewall，网络层发现、拦截、细粒度策略
这不是巧合。MCP 正在从"连接协议"进化为"企业治理控制面"。
一、为什么治理必须在协议层
1.1 三层 enforcement 的对比
┌─────────────────────────────────────────────────────────────────┐
│ AI Agent 治理层级对比 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ 模型层（Model Layer） │ │
│ │ 控制：AI 说什么、生成什么内容 │ │
│ │ 工具：内容过滤、输出审核、RLHF │ │
│ │ 局限：无法控制 Agent 实际执行的操作 │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ 应用层（Application Layer） │ │
│ │ 控制：UI 显示什么、用户能点什么 │ │
│ │ 工具：权限检查、操作确认、审计日志 │ │
│ │ 局限：绕过 UI 的直接 API 调用不受控 │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ 协议层（Protocol Layer）★ MCP 治理面 │ │
│ │ 控制：Agent 能调用什么工具、访问什么资源 │ │
│ │ 工具：服务器发现拦截、工具级策略、令牌生命周期 │ │
│ │ 优势：无论哪个模型、哪个 UI，Agent 的实际能力被硬限制 │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘关键洞察：当 enforcement 住在协议层时，Agent 的实际能力被硬限制——无论它背后跑的是 GPT-5、Claude 4 还是本地 Llama 模型，无论用户用的是 Cursor、Claude Code 还是自研界面。
1.2 企业面临的"影子 AI"问题
Okta 2026 年调查数据：
- 67% 的员工使用未经批准的 AI 工具
- 92% 的高管报告自主 Agent 已广泛部署
- 47.1% 的 Agent 实际受到监控或安全保护
这意味着超过一半的 Agent 在"裸奔"。Microsoft 将这个问题称为 "shadow AI"——未经授权的 MCP 服务器被集成到企业工作流中，IT 部门毫无 visibility。
二、三家方案深度对比
2.1 架构总览
| 维度 | ServiceNow AI Gateway v3.4 | Rubrik MCP | Microsoft MCP Firewall |
|---|---|---|---|
| 发布日期 | 2026-09-10 | 2026-09-15 | 2026-09-17 |
| 治理域 | 服务器生命周期 + 工具访问 | 数据安全 + 身份 + 凭证 | 网络发现 + 流量控制 |
| enforcement 点 | Gateway 层 | MCP 协议层 | 网络层（Global Secure Access） |
| 身份集成 | ServiceNow 原生 | Okta + Microsoft Entra ID | Microsoft Entra Agent ID |
| 令牌模型 | 传统 OAuth / API Key | per-tool-call JIT Token | Entra 条件访问令牌 |
| 策略粒度 | 服务器级 + 工具级 | 工具级 + 资源级 | 服务器级 + 工具级 + 资源级 + 协议版本 |
| 默认策略 | 可配置 | 最小权限 | 默认拒绝（default-deny） |
| shadow AI 检测 | 有限 | 通过 Agent Identity 可见性 | 主动发现 + 拦截 |
| OWASP 对齐 | 部分 | 完整 Top 10 护栏 | 通过 Agent Governance Toolkit |
2.2 ServiceNow AI Gateway v3.4
定位：企业工作流中的 MCP 治理入口
┌─────────────────────────────────────────────────────────────┐
│ ServiceNow AI Gateway v3.4 架构 │
├─────────────────────────────────────────────────────────────┤
│ │
│ Agent (Cursor/Claude Code/自定义) │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────┐ │
│ │ ServiceNow AI Gateway │ │
│ │ ┌─────────────────────────────┐ │ │
│ │ │ Unified Catalog │ │ MCP 服务器目录 │
│ │ │ (哪些服务器可被使用) │ │ │
│ │ └─────────────────────────────┘ │ │
│ │ ┌─────────────────────────────┐ │ │
│ │ │ Real-time Access Policies │ │ 工具调用时强制 │
│ │ │ (能调用什么工具/资源) │ │ │
│ │ └─────────────────────────────┘ │ │
│ │ ┌─────────────────────────────┐ │ │
│ │ │ Operational Visibility │ │ 审计与监控 │
│ │ │ (谁调用了什么、何时) │ │ │
│ │ └─────────────────────────────┘ │ │
│ └─────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ 被允许的 MCP 服务器 │
│ (Slack/GitHub/Jira/数据库等) │
│ │
└─────────────────────────────────────────────────────────────┘核心能力：
- 统一目录（Unified Catalog）：企业可以定义哪些 MCP 服务器被允许注册到 Agent 的可用工具列表中
- 实时访问策略：在工具调用发生的瞬间进行权限检查，而非仅在初始化时
- 操作可见性：完整的调用审计日志，包括谁、何时、调用了什么工具、传了什么参数
适用场景：已经在使用 ServiceNow 作为 ITSM 平台的企业，希望将 AI Agent 的治理纳入现有工作流。
2.3 Rubrik MCP
定位：数据安全优先的 MCP 治理
Rubrik 与 Anthropic 联合工程，核心创新是 Agent Identity 和 per-tool-call JIT Token：
┌─────────────────────────────────────────────────────────────┐
│ Rubrik MCP 架构 │
├─────────────────────────────────────────────────────────────┤
│ │
│ Agent 发起工具调用 │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────┐ │
│ │ Rubrik MCP Gateway │ │
│ │ │ │
│ │ ┌─────────────────────────────┐ │ │
│ │ │ OWASP MCP Top 10 护栏 │ │ │
│ │ │ - 注入检测 │ │ │
│ │ │ - 敏感数据泄露防护 │ │ │
│ │ │ - 过度权限检测 │ │ │
│ │ └─────────────────────────────┘ │ │
│ │ │ │
│ │ ┌─────────────────────────────┐ │ │
│ │ │ Per-Tool-Call JIT Token │ │ │
│ │ │ │ │ │
│ │ │ 传统模型：静态 API Key │ │ │
│ │ │ ┌─────────┐ 长期有效 │ │ │
│ │ │ │ API Key │ ─────────────► │ │ │
│ │ │ └─────────┘ 泄露=灾难 │ │ │
│ │ │ │ │ │
│ │ │ Rubrik 模型：每次调用 mint │ │ │
│ │ │ ┌─────┐ ┌─────┐ ┌─────┐ │ │ │
│ │ │ │Token│ │Token│ │Token│ │ │ 每个调用独立 │
│ │ │ │ #1 │ │ #2 │ │ #3 │ │ │ 15 分钟过期 │
│ │ │ └──┬──┘ └──┬──┘ └──┬──┘ │ │ 最小权限范围 │
│ │ │ │ │ │ │ │ │
│ │ └─────┴──────┴──────┴──────┘ │ │
│ │ │ │
│ │ ┌─────────────────────────────┐ │ │
│ │ │ Agent Identity Federation │ │ │
│ │ │ - Okta 集成 │ │ │
│ │ │ - Microsoft Entra ID │ │ │
│ │ │ - RBAC 与人类用户权限对齐 │ │ │
│ │ └─────────────────────────────┘ │ │
│ └─────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘核心创新：
OWASP MCP Top 10 对齐护栏：
- MCP01: 工具调用注入
- MCP02: 敏感数据泄露
- MCP03: 过度权限委托
- MCP04: 不安全的令牌处理
- ...（完整 Top 10 覆盖）
Per-Tool-Call JIT Token：
- 每个工具调用独立 mint 一个短期令牌（通常 15 分钟有效期）
- 令牌范围精确到单个工具 + 特定资源
- 即使令牌泄露，影响范围和时间窗口都被严格限制
Agent Identity Federation：
- Agent 的身份与人类用户的 RBAC 权限对齐
- 通过 Okta 或 Microsoft Entra ID 进行身份断言
- 实现"Agent 不能访问人类用户无权访问的资源"
关键数据（Rubrik Zero Labs）：
- 86% 的 IT 和安全负责人预计 AI Agent 将在未来一年内超越组织的安全防护能力
- 仅 23% 的组织对其环境中运行的 Agent 有完整可见性
- 88% 的领导者担心在 Agent 威胁规模扩大时无法满足恢复时间目标
2.4 Microsoft MCP Firewall
定位：网络层的 MCP 流量控制
Microsoft 的 MCP Firewall 是 Global Secure Access 套件的新组件，核心能力是协议感知的网络 enforcement：
┌─────────────────────────────────────────────────────────────┐
│ Microsoft MCP Firewall 架构 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 企业网络 / 远程设备 │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────┐ │
│ │ Global Secure Access │ │
│ │ ( forwarding client ) │ │
│ │ │ │
│ │ ┌─────────────────────────────┐ │ │
│ │ │ TLS Inspection │ │ 解密 MCP 流量 │
│ │ │ (需要目录加入设备) │ │ │
│ │ └─────────────────────────────┘ │ │
│ │ │ │ │
│ │ ▼ │ │
│ │ ┌─────────────────────────────┐ │ │
│ │ │ MCP Protocol Parser │ │ 解析 JSON-RPC │
│ │ │ (协议感知，非通用过滤) │ │ │
│ │ └─────────────────────────────┘ │ │
│ │ │ │ │
│ │ ▼ │ │
│ │ ┌─────────────────────────────┐ │ │
│ │ │ Policy Engine │ │ │
│ │ │ - 服务器白名单/黑名单 │ │ │
│ │ │ - 工具级允许/拒绝 │ │ │
│ │ │ - 资源级访问控制 │ │ │
│ │ │ - 协议版本检查 │ │ │
│ │ │ - Prompt 模板过滤 │ │ │
│ │ └─────────────────────────────┘ │ │
│ │ │ │ │
│ │ ▼ │ │
│ │ ┌─────────────────────────────┐ │ │
│ │ │ Generative AI Insights │ │ 发现与监控 │
│ │ │ (shadow AI 检测) │ │ │
│ │ └─────────────────────────────┘ │ │
│ └─────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ 允许的 MCP 服务器流量 │
│ │
└─────────────────────────────────────────────────────────────┘核心能力：
- 协议感知过滤：不是通用的 HTTP 过滤，而是理解 MCP 的 JSON-RPC 结构——知道这是一个
tools/call请求，知道它在调用什么工具、访问什么资源 - Shadow AI 发现：主动扫描网络中的 MCP 流量，发现未经授权的 MCP 服务器
- 默认拒绝（Default-Deny）：可以配置为拦截所有 MCP 流量，直到显式批准
- 细粒度策略：允许某个服务器但拒绝其中的特定工具；拒绝过时的协议版本
覆盖范围限制（Microsoft 官方文档明确声明）：
| 流量类型 | 是否覆盖 | 说明 |
|---|---|---|
| HTTP MCP 远程服务器 | ✅ | 主要覆盖场景 |
| Server-Sent Events | ✅ | 流式响应 |
| stdio 本地服务器 | ❌ | 本地进程间通信不可见 |
| 非 HTTP 传输 | ❌ | 如 WebSocket 自定义实现 |
| JSON-RPC 批处理 | ❌ | 当前版本不检查 |
| 未加入目录的设备 | ❌ | 需要 forwarding client |
三、四层治理栈的形成
这三家企业的产品，加上之前发布的工具，正在形成一个四层 Agent 治理栈：
┌─────────────────────────────────────────────────────────────────┐
│ 企业 Agent 治理四层栈 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ 第四层：网络层（Network） │ │
│ │ Microsoft MCP Firewall │ │
│ │ 控制：哪些 MCP 服务器可以被访问、哪些流量可以通过 │ │
│ │ 特点：协议感知的网络过滤，shadow AI 发现 │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ 第三层：数据安全层（Data Security） │ │
│ │ Rubrik MCP + Agent Identity │ │
│ │ 控制：Agent 能访问什么数据、用什么凭证 │ │
│ │ 特点：per-tool-call JIT Token，最小权限原则 │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ 第二层：运行时层（Runtime） │ │
│ │ ServiceNow AI Gateway + NVIDIA OpenShell + WSO2 │ │
│ │ 控制：工具调用的实时策略 enforcement │ │
│ │ 特点：调用时检查、审计日志、生命周期管理 │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ 第一层：构建时层（Build-time） │ │
│ │ Cisco Agent Runtime SDK + Microsoft Agent Governance │ │
│ │ Toolkit │ │
│ │ 控制：Agent 在部署前就被植入安全约束 │ │
│ │ 特点：策略编译进 Agent，运行时不可绕过 │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘关键洞察：没有单一厂商拥有全部四层。企业需要组装多个产品，而 MCP 协议正在成为四层汇聚的公共表面。
四、覆盖盲区：MCP Firewall 看不到什么
Microsoft 的文档 unusually honest 地声明了覆盖限制。结合 2026 年 7 月的 MCP 互联网测量研究（Padilla, arXiv:2608.00150v1），我们可以画出真实的覆盖盲区：
4.1 六类流量组合，仅一类完全覆盖
┌─────────────────────────────────────────────────────────────────┐
│ MCP 流量覆盖矩阵（基于 Microsoft 文档） │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 远程服务器 本地服务器 │
│ ┌─────────────┐ ┌─────────────┐ │
│ HTTP/SSE │ ✅ 覆盖 │ │ ❌ 不覆盖 │ │
│ │ (主要场景) │ │ (stdio等) │ │
│ └─────────────┘ └─────────────┘ │
│ │
│ ┌─────────────┐ ┌─────────────┐ │
│ 非 HTTP 传输 │ ❌ 不覆盖 │ │ ❌ 不覆盖 │ │
│ (WebSocket等) │ │ │ │ │
│ └─────────────┘ └─────────────┘ │
│ │
│ 关键发现（2026-07 测量研究）： │
│ - 91.8% 的公开 MCP 服务器缺乏 OAuth 认证 │
│ - 687 个工具实例暴露无访问控制的 shell 执行 │
│ - 41.6% 的确认服务器在 3 天内消失 │
│ - 最高风险的工具类集中在网络控制看不到的路径 │
│ │
└─────────────────────────────────────────────────────────────────┘4.2 企业应对盲区的策略
| 盲区 | 风险 | 缓解策略 |
|---|---|---|
| 本地 stdio 服务器 | 绕过网络监控 | 端点 EDR + 进程白名单 |
| 非 HTTP 传输 | 协议无法解析 | 网络分段 + 异常流量检测 |
| 未管理设备 | 不受 forwarding client 保护 | MDM 强制 + 设备合规检查 |
| JSON-RPC 批处理 | 当前不检查 | 升级 firewall 版本 / 应用层网关 |
| 91.8% 无 OAuth 服务器 | 凭证泄露、未授权访问 | 强制 OAuth + 令牌生命周期管理 |
五、落地建议：企业 MCP 治理路线图
5.1 第一阶段：可见性（1-2 周）
bash
# 1. 盘点当前环境中的 MCP 服务器
# - 询问开发团队使用了哪些 MCP 工具
# - 检查浏览器扩展、IDE 插件中的 MCP 配置
# - 扫描网络流量中的 MCP 特征（JSON-RPC + MCP 方法名）
# 2. 建立 MCP 资产清单
# 服务器名称 | 用途 | 负责人 | 认证方式 | 数据敏感度
# -----------|------|--------|----------|------------
# github-mcp | 代码访问 | 开发团队 | OAuth | 高
# slack-mcp | 消息发送 | 运维团队 | API Key | 中
# ...5.2 第二阶段：基础控制（2-4 周）
- 强制认证：所有 MCP 服务器必须启用 OAuth，禁用长期 API Key
- 最小权限：每个 Agent 只授予必要的工具访问权限
- 审计日志：记录所有工具调用，保留至少 90 天
- 网络分段：将 MCP 服务器放置在受限网络区域
5.3 第三阶段：运行时 enforcement（1-3 个月）
评估并部署 MCP Gateway：
- 已有 ServiceNow 环境 → AI Gateway v3.4
- 数据安全优先 → Rubrik MCP
- Microsoft 生态深度用户 → MCP Firewall
实施分层策略：
- 网络层：拦截未知 MCP 服务器
- 网关层：工具级访问控制
- 数据层：per-call 短期令牌
5.4 第四阶段：持续运营
- 定期审查 MCP 资产清单
- 监控 KEV 和 MCP 安全公告
- 演练 MCP 供应链攻击响应
- 评估新兴治理工具
六、总结：MCP 治理的拐点
2026 年 9 月的这一周，标志着 MCP 治理从"讨论"进入"产品化"。
三个关键信号：
- 协议层成为共识：三家不同背景的企业（ITSM、数据安全、云基础设施）不约而同选择 MCP 作为 enforcement 表面
- 从身份到行为：治理焦点从"谁在使用 Agent"转向"Agent 在做什么"
- 分层组装成为现实：没有单一产品能解决所有问题，企业需要组装四层治理栈
对企业的核心建议：
- 不要等待"完美方案"：从可见性和基础控制开始，逐步增强
- 假设 shadow AI 已存在：67% 的员工使用未经批准的工具，你的环境很可能已经有"隐形"Agent
- MCP 治理是安全团队的新职责：这不是"AI 创新"的问题，这是"访问控制"的问题——安全团队最熟悉的领域
MCP 正在从连接协议进化为控制平面。这个转变的速度，比大多数人预期的更快。
参考资源
- Web Pulse: MCP Is Becoming the Governance Surface — https://wpnews.pro/news/mcp-is-becoming-the-governance-surface-three-enterprise-vendors-shipped-policy
- Forkast: Runtime Enforcement Crystallizes — https://forkast.news/this-week-in-agent-infrastructure-runtime-enforcement-crystallizes-as-a-mandatory-layer
- Ariana Digital: MCP Firewall Coverage Gap — https://ariana.digital/insights/mcp-firewall-coverage-gap-agent-tool-calls-2026-09-02
- Microsoft: Global Secure Access MCP Firewall — https://learn.microsoft.com/en-us/entra/global-secure-access/mcp-firewall
- Microsoft Entra Agent ID — https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/agent-id
- Rubrik Agent Identity — https://www.rubrik.com/blog/agent-identity-black-hat-2026
- ServiceNow AI Gateway — https://www.servicenow.com/products/ai-gateway.html
- OWASP MCP Top 10 (草案) — https://owasp.org/www-project-mcp-top-10/
- Padilla et al.: MCP Internet Measurement Study (arXiv:2608.00150v1)