Snowflake 的 Cortex AI Gateway 让智能体控制权之争愈发激烈

Snowflake 在推出 Cortex AI Gateway 后登上 google news；此前，Model Context Protocol 连接看起来更像开发者集成，而非企业基础设施。该网关于 7 月 28 日发布，集中管理访问策略、身份验证、活动记录、模型路由和使用量控制。Snowflake 表示，其支持超过 100 个 MCP 服务器。

真正重要的变化并非又多了一份连接器目录。Snowflake 正在 AI 智能体与其可访问的模型、工具、数据和应用之间设置一层控制层。这一定位类似于企业软件早期普及时，API 网关和身份平台所占据的角色。

Snowflake 并非唯一一家。Databricks、Cloudflare、安全厂商和专业初创公司都在构建类似的控制点。竞争已不再是 Model Context Protocol 是否会获得广泛支持，而是谁将在智能体开始执行具有实质影响的操作后，掌控 MCP 流量。

Snowflake 将 Cortex AI Gateway 打造成智能体控制点

Cortex AI Gateway 将 Snowflake 的治理边界从存储的数据扩展至 AI 智能体执行的操作。

Snowflake 将该产品描述为面向第一方和第三方智能体的集中式网关。前者包括 Snowflake CoWork 和 Snowflake CoCo，后者包括 Claude Code 和 Cursor 等外部编程智能体。

Model Context Protocol，即 MCP，是一种开放协议，使 AI 应用能够通过一致的接口发现并调用外部工具。MCP 服务器可以将数据库查询、文档搜索、消息操作或业务应用以可调用工具的形式开放出来。

该协议减少了智能体使用这些资源所需的定制集成工作。但它并不会自动为企业提供一个统一位置，以审批每一项连接、监控每一次操作或分配每一笔费用。

Cortex AI Gateway 旨在填补这一运营缺口。根据网关公告，组织可利用它定义哪些智能体能够访问特定模型、MCP 服务器、应用和工具。

Snowflake 还表示，该网关会创建端到端活动记录。这些记录旨在展示智能体执行了什么操作、联系了哪些系统，以及其操作顺序。

这之所以重要，是因为一次智能体交互很少止于单次模型响应。编程智能体可能会检查代码仓库、获取一个问题、修改文件、运行测试，并联系另一项服务。每一步都可能跨越不同的安全或所有权边界。

网关可以为这些步骤提供统一的检查点。它可以验证调用方身份、评估权限、记录请求，并将获批操作传递至目标位置。

Snowflake 正在为这一检查点加入财务控制。该公司表示，Cortex AI Gateway 可以将 AI 消耗归因到团队、智能体或工作负载。管理员还可以设置支出上限，以防止智能体产生失控的模型使用量。

该网关还承诺可在获批模型之间进行请求路由。Snowflake 表示，路由决策可以考虑质量、延迟、可用性和使用成本。这使该产品不止是 MCP 代理，因为它也管理模型流量。

Snowflake 对超过 100 个 MCP 服务器的支持，提供了连接广度的早期衡量指标。不过，这一数字并不能证明其生产环境采用率、可靠性或安全质量。支持可能仅代表技术兼容性，并未说明有多少客户在关键工作流中运行这些连接。

尽管如此，此次发布改变了 Snowflake 的定位。Cortex AI 原本已经是调用模型和构建数据智能体的平台。如今，Cortex AI Gateway 寻求掌控在其他地方开发的智能体，包括主要交互界面位于 Snowflake 之外的智能体。

这正是基础设施层面的信号。即使 Snowflake 并未创建智能体，它也希望控制智能体请求与企业操作之间的路径。

为什么 Cortex AI Gateway 此时登上 Google News

Snowflake 正在回应 MCP 作为集成标准取得成功后带来的治理问题。

MCP 最初旨在让工具连接具备可移植性。开发者可以一次性开放某项能力，再让多个兼容 AI 客户端使用它。当数十个智能体跨不同团队连接数百种工具时，这种模式会变得更难管理。

该协议本身定义了消息和交互模式。其授权规范为受限远程服务器提供了基于 OAuth 标准的框架。然而，企业治理的范围超出了传输层授权。

安全团队需要了解某个智能体代表的是哪位人员或哪项服务，并决定该身份能否以特定参数调用特定工具。他们还可能需要审批规则、数据泄露控制、审计留存和紧急撤销机制。

财务团队面临着平行的问题。一个工作流在返回结果前，可能调用多个模型和工具。传统云账单能够识别被消耗的服务，却未必能说明是哪个智能体启动了这条链路，或哪个部门从中受益。

这些问题催生了对中间层的市场需求。网关会在流量抵达模型或 MCP 服务器之前看到它。这样的可见性使其能够在更接近操作发生点的位置应用策略并记录成本。

Snowflake 通过 Natoma 为这一动作做了准备。5 月 27 日，该公司签署最终协议，拟收购这家为 AI 智能体构建企业 MCP 平台的公司。Snowflake 表示，这笔交易将把治理从数据资产扩展至 AI 操作和交互。

这项Natoma 收购还承诺提供经过验证的 MCP 服务器库。Snowflake 特别指出，电子邮件、Slack 和其他已连接应用可以充实其平台中已有的数据。

从签署协议到公布 Cortex AI Gateway 的间隔很短，显示出这一战略重点。Snowflake 正将收购而来的 MCP 能力融入更广泛的平台叙事，而非将其保留为独立的连接器产品。

其发布时机也紧随 Snowflake 此前在 AI 治理方面的工作。在 2025 年峰会上，该公司介绍了用于模型访问、使用量追踪、基于角色的控制和预算执行的 AI Governance Gateway。它还单独宣布为 Cortex Analyst 和 Cortex Search 提供 MCP 服务器支持。

Cortex AI Gateway 将这些此前相邻的议题结合在一起。它通过一个拟议的控制平面管理模型选择、MCP 访问、智能体活动和消耗。

这种整合反映了企业智能体的变化。传统聊天机器人会生成文本，供用户审阅。智能体则可以在用户看到结果之前检索私密信息、调用业务系统，或发起一项变更。

这些能力使工具访问与模型访问同样重要。企业可以批准一款 LLM，却仍可能因权限范围不当的连接器而暴露风险。它也可以保护每个应用，却失去对完整智能体操作链的可见性。

Snowflake 的安全集成覆盖了这一挑战的部分环节。首批集成包括 1Password、Aembit、Linx Security、Okta、SailPoint 和 Saviynt。它们的出现表明，智能体身份与访问治理正成为共同的基础设施议题。

因此，该网关出现在 google news 结果中，与更大的转变有关。MCP 连接正在从开发者便利功能，进入身份团队、安全运营、财务和平台工程的领域。

Snowflake 和 Databricks 正在争夺同一控制平面

核心竞争在于 Snowflake 与 Databricks：现有数据平台是否应当管理每一个模型和 MCP 请求。

Databricks 也通过 Unity AI Gateway 提出了高度相关的主张。其文档将该服务描述为面向智能体、模型端点、MCP 服务器和编程工具的集中治理层。

二者的相似之处很直接。两个平台都希望路由 AI 流量、执行权限、观察使用情况，并管理跨不同提供商的消耗。它们也都将这一运行时层与已用于企业数据的治理系统相连接。

Databricks 将 Unity Catalog 置于其方法的核心。该目录管理模型、函数和 MCP 服务器等资产。随后，Unity AI Gateway 在请求穿过系统时应用这些权限和策略。

当前的AI 治理指南称，该网关可管理外部编程智能体，包括 Claude Code、Cursor、Codex 和 Gemini CLI。指南还介绍了速率限制、预算、使用量追踪和请求级服务策略。

Snowflake 在自己的公告中也提到了 Claude Code 和 Cursor。这种重叠很重要：两家公司都没有将网关局限于在自身平台内构建的智能体。

它们都试图成为由其他地方创建的智能体的中立控制点。中立性仍是相对的，因为控制层依然会增强周边数据平台的能力。

对客户而言，眼下的选择通常会遵循现有基础设施。拥有大量 Snowflake 策略、数据和运营知识的企业，可能更愿意通过 Cortex AI Gateway 扩展这些控制。Databricks 客户则可能认为基于 Unity Catalog 的路径阻力更小。

长期竞争则更难预测。智能体通常会跨越数据仓库、软件代码仓库、消息系统、客户平台和云服务开展工作。没有单一数据平台拥有所有这些目标系统。

因此，网关必须证明，它能够在不迫使所有工作流进入封闭技术栈的前提下，治理其主平台之外的资源。Snowflake 的安全集成和 Natoma 连接器旨在支持这一论点。

Databricks 也通过覆盖外部提供商和编程智能体提出类似的互操作性主张。其网关在 2026 年 7 月更新的文档中仍被标记为 beta，因此在可用性和实现方面仍可能发生变化。

两家厂商均未通过公开采用数据确立决定性领先地位。功能清单显示出战略趋同，但并未说明哪个网关处理了更多生产流量，或阻止了更多策略违规行为。

竞争也来自数据平台类别之外。Cloudflare 推出了 MCP 服务器门户，可在访问层之后聚合多个服务器。其门户文档介绍了 OAuth 支持以及单个工具请求的日志记录。

Cloudflare 从网络和访问基础设施角度切入这一问题。身份厂商则通过凭证和授权来应对。专业网关公司则专注于 MCP 发现、检查和策略执行。

这些方法可以在同一家企业中共存，但重叠的控制机制会造成运营摩擦。团队可能需要决定权威策略应存放在哪里，以及由哪个系统保留完整的审计轨迹。

重复部署的网关也可能模糊责任归属。一项请求可能依次经过智能体平台、模型网关、MCP 网关、网络代理和应用授权层。每个系统都可能记录不同的身份信息或决策。

Snowflake 的目标是通过整合这些控制机制来减少碎片化。风险在于，客户可能会用一个与单一供应商紧密绑定的控制点，取代许多彼此割裂的工具。

这种张力将影响采购决策。企业希望实现一致的治理，同时也希望能够自由切换模型、智能体和数据系统。胜出的网关必须提供集中式控制，同时不能让互操作性变成依赖关系。

网关机制让 MCP 更像基础设施

MCP 网关正逐渐成为基础设施，因为每一项有价值的智能体连接都会持续产生身份、策略、路由、可观测性和成本归属方面的需求。

一个基础的 MCP 连接回答的是技术问题：智能体如何发现并调用工具？企业网关回答的则是运营问题：在什么条件下，应当允许这种调用？

设想一名员工要求编码智能体调查生产事故。该智能体可能会搜索技术文档、检查代码仓库、查询日志、创建工单并起草变更。

每次工具调用都会继承前序步骤中的上下文。智能体还会携带某种形式的员工身份、权限和意图表示。这条链中的一个错误，就可能暴露数据，或授权执行员工从未要求的操作。

网关可以在执行前评估调用。它可以拒绝用户无权访问的工具、限制参数，或要求对写入操作进行审批。它还可以保留记录，将操作关联到发起用户和智能体。

这就是策略执行点，即抽象规则转化为允许、拒绝或审批决策的位置。这个概念在 API 管理、零信任访问和云身份系统中并不陌生。

智能体流量让决策更加复杂。请求通常以概率方式生成，而下一个工具可能取决于前一阶段检索到的不可信内容。

一份包含恶意指令的文档可能影响智能体去调用另一个工具。遭入侵的 MCP 服务器可能返回意图改变后续行为的内容。权限范围过宽的令牌随后可能让智能体访问超出原始任务范围的数据。

集中式活动记录有助于调查人员还原此类链路。它们无法阻止所有攻击。预防还需要受限凭证、安全的工具设计、输入验证、隔离以及审慎的审批流程。

路由增加了另一项基础设施功能。一个组织可能针对不同工作负载批准多种语言模型。某个模型可能适合复杂推理，另一个则可以以更低延迟处理常规提取任务。

网关可以从已批准的选项中进行选择，而无需每个应用分别实现供应商逻辑。当某个端点不可用时，它也可以重新路由流量。

这种灵活性能够降低应用耦合度。不过，路由质量取决于评估数据和清晰的工作负载策略。除非组织明确可接受的权衡取舍，否则网关无法可靠地推断业务优先级。

成本归属同样很有价值，但也很困难。对单次请求而言，计算 token 很直接。要将一个多步骤工作流的完整成本归属到某个部门、项目或用户，则要求每一跳都具有一致的身份信息。

Snowflake 表示，Cortex AI Gateway 可以将消耗归属到负责的团队、智能体或工作负载。买家应考察：当外部智能体跨多个独立系统调用数个工具和模型时，这种归属机制会如何运作。

他们还应测试预算执行是否会以安全的方式中断工作流。在中途停止智能体，可能会留下部分变更、未关闭的事务或不完整的记录。

当这些控制机制从单个应用中消失时，基础设施的类比就最为贴切。开发人员不应需要为每个新智能体重新实现认证、日志记录、路由和预算逻辑。

将这些功能标准化可以加快部署，也可能让网关成为高价值攻击目标和关键依赖项。

这就是市场正在向网关架构收敛的原因。MCP 越能让工具访问具备可移植性，企业就越需要一个一致的层来约束这种可移植性。

安全主张仍需生产环境证据

集中式网关可以改善控制能力，但它不会让 MCP 连接默认安全，也无法消除工具自身的风险。

Snowflake 的公告将安全与信任描述为智能体互操作性的基础。这是合理的目标，但该公司尚未发布足够证据，无法将这一主张视为已获独立验证的事实。

公告没有提供 Cortex AI Gateway 的生产环境采用数量，也没有量化被拦截的攻击、策略违规、路由准确性或其消耗控制带来的节省。

其对 100 多个 MCP 服务器的支持衡量的是兼容性，而非可信度。网关仍然需要掌握每台服务器、其工具、版本和所需权限的准确信息。

安全挑战延伸至网关之下。获批准的服务器可能包含存在漏洞的代码。合法工具可能暴露危险参数。智能体在处理恶意上下文后，也可能滥用获许可的能力。

政府指南强调了这些局限。NSA 于 2026 年 5 月发布的 MCP 安全指南 将 MCP 描述为事实上的通信标准，但表示其安全态势仍不均衡。

该报告指出了动态工具调用、隐式信任、上下文共享、薄弱的访问控制、提示注入和令牌生命周期缺口等问题。报告称，许多保护措施依赖于实施纪律，而非协议保障。

这一差异对于评估 Cortex AI Gateway 至关重要。网关可以集中认证和授权，但无法追溯性地让每一台已连接服务器都变得安全。

它也无法保证智能体正确理解了用户请求。获得执行某项操作的权限，并不能证明该操作符合用户意图。

审批工作流可以缩小这一差距。高风险变更应要求人员检查确切的拟议操作、其参数和预期影响。当用户无法看到智能体将执行什么操作时，笼统的权限提示几乎无法提供保护。

买家应询问 Snowflake 如何处理委托身份。代表员工行动的智能体应仅获得完成该任务所需的权限。它不应仅因为工作流跨越多个系统，就继承一个权限广泛的服务凭证。

他们还应审查撤销机制。如果用户角色发生变化或令牌遭到泄露，网关必须迅速阻止后续访问。缓存凭证和长时间运行的智能体会话可能使这一响应更加复杂。

日志记录本身也带来权衡。详细记录有助于审计和事件响应，但提示词和工具参数可能包含敏感信息。组织需要为日志本身制定保留、脱敏和访问规则。

网关的模型路由同样值得严格审视。在质量、延迟、可用性和消耗之间进行优化听起来很有用，但这些目标可能相互冲突，而自动化选择可能影响输出质量或数据处理义务。

企业应验证路由是否将数据保留在获批准的地区和供应商范围内。他们还应确定模型变更是否对应用所有者可见，并能在审计期间复现。

供应商集中化带来另一项风险。将智能体流量、工具权限、模型路由和成本控制放在一个系统中，会形成广泛的运营依赖。该层发生故障或策略出错，可能会同时中断许多工作流。

这并不否定网关模式。它意味着网关必须像身份、网络和 API 基础设施一样接受评估，而不能仅被视为便利功能。

Snowflake 的定位可能有助于已经投入其治理模式的客户。然而，买家仍需要独立测试、最小权限设计、服务器清单、隔离执行和事件处置流程。

因此，对 Google 新闻标题负责任的解读应比 Snowflake 的营销措辞更为克制。Cortex AI Gateway 表明了市场的发展方向，但并未解决单一平台能否保护完整智能体生命周期的问题。

Google 新闻读者接下来应关注什么

只有当采用情况、执行证据和跨平台表现超越发布声明时，网关论点才会具备可信度。

第一个信号是生产环境使用情况。Snowflake 应披露有多少客户通过 Cortex AI Gateway 路由活跃的第三方智能体，而不只是支持多少 MCP 服务器。

有价值的证据包括：受治理工具调用的数量、外部系统的覆盖范围，以及采用强制策略的工作流占比。客户案例研究应识别具体操作，而不是重复关于信任的笼统表述。

Meltwater 在 Snowflake 的公告中被列为有兴趣将智能体安全连接到数据和工具的组织。相关措辞将 Cortex AI Gateway 描述为迈向这一成果的一步，但并未证明已经完成了具有量化结果的部署。

这一差异值得持续追踪。设计合作伙伴可以验证产品方向，而持续的生产流量才能检验可靠性、身份映射和运营成本。

第二个信号是执行质量。Snowflake 需要证明，其策略能够跨第一方和第三方智能体发挥作用，同时不丢失用户身份或任务上下文。

买家应寻找针对单个工具和参数的细粒度控制。他们还应关注审批策略、令牌撤销、数据丢失防护，以及与现有安全监控系统的集成。

公开的事件报告将提供有价值的证据。可信的控制平面应说明它如何检测不安全行为、拦截了什么，以及管理员如何还原事件。

第三个信号是竞争响应。Databricks、Cloudflare、身份供应商和独立网关提供商将继续扩展各自的智能体控制能力。

如果这些产品在可移植策略格式和共享审计标准上趋于一致，企业便可以切换网关，而无需重建每一条规则。这一结果将巩固 MCP 作为开放基础设施的地位。

如果每个平台都创建专有身份、策略模型和日志，MCP 可能在连接层保持开放，而治理仍然碎片化。这将削弱可互换智能体工具的承诺。

开发人员应关注网关如何提供调试信息。被拒绝的请求需要一个可理解的原因，而被路由的请求需要一条追踪记录，说明哪个模型和策略对其产生了影响。

安全团队应评估一个网关是否能够看到完整的操作链。当智能体跨越未受监控的系统时，局部可见性可能造成误导性的安全感。

企业买家还应比较控制平面的故障模式。他们需要了解：网关故障时智能体是否会安全停止、读取和写入操作是否有不同表现，以及紧急访问如何运作。

知识工作者同样关乎这些选择，因为网关策略决定了其助手能够访问哪些信息。更完善的控制机制可以支持有价值的连接，而不必让每个智能体永久访问电子邮件、文档和消息系统。

构建可搜索技术上下文的团队，应将权限与源材料保持绑定。设计良好的工程知识库能减少暴露宽泛代码库的需求——当智能体只需要访问特定信息时尤其如此。

未来一到三个月应能进一步明确：Cortex AI Gateway 会成为实际可用的控制节点，还是仍停留在战略发布层面。值得关注的是具名的生产环境部署、可量化的执行效果，以及超越 Snowflake 自身环境的更深层集成。

Snowflake 已清晰表明其基础设施押注：它相信，企业将通过一个集模型路由、MCP 治理、活动记录和用量控制于一体的集中式层来管理智能体。

这一押注在方向上看似合理，因为可移植工具催生了对可移植控制能力的需求。悬而未决的问题是，谁能够赢得运营这一控制平面的资格。

Google 新闻报道捕捉到了发布时刻。更重要的考验将在企业接入能够读取敏感数据、消耗真实资源并变更生产系统的智能体时开始。在将任何 MCP 网关视为可信基础设施之前，请先确认你的组织能否识别每一个智能体、约束每一项工具，并还原每一次操作。