Snowflake’s Cortex AI Gateway Puts Agent Control Up for Grabs

Snowflake entered google news after launching Cortex AI Gateway, despite Model Context Protocol connections previously looking more like developer integrations than enterprise infrastructure. Announced on July 28, the gateway centralizes access policies, authentication, activity records, model routing, and consumption controls. Snowflake says it supports more than 100 MCP servers.

The significant change is not another connector catalog. Snowflake is placing a control layer between AI agents and the models, tools, data, and applications those agents can reach. That position resembles the role API gateways and identity platforms claimed during earlier waves of enterprise software adoption.

Snowflake is not alone. Databricks, Cloudflare, security vendors, and specialized startups are building similar control points. The contest is no longer about whether Model Context Protocol becomes widely supported. It is about which platform governs MCP traffic once agents begin taking consequential actions.

Snowflake Turns Cortex AI Gateway Into an Agent Control Point

Cortex AI Gateway expands Snowflake’s governance boundary from stored data to the actions performed by AI agents.

Snowflake describes the product as a centralized gateway for first-party and third-party agents. The first group includes Snowflake CoWork and Snowflake CoCo. The second includes external coding agents such as Claude Code and Cursor.

Model Context Protocol, or MCP, is an open protocol that lets AI applications discover and invoke external tools through a consistent interface. An MCP server can expose a database query, document search, messaging action, or business application as a callable tool.

The protocol reduces the custom integration work required for agents to use those resources. It does not automatically give an enterprise one place to approve every connection, monitor every action, or assign every expense.

Cortex AI Gateway is designed to fill that operational gap. According to the gateway announcement, organizations can use it to define which agents access particular models, MCP servers, applications, and tools.

Snowflake also says the gateway creates an end-to-end activity record. That record is intended to show what an agent did, which systems it contacted, and the sequence of its actions.

This matters because an agent interaction rarely ends with one model response. A coding agent might inspect a repository, retrieve an issue, modify a file, run a test, and contact another service. Each step can cross a different security or ownership boundary.

A gateway can provide a common checkpoint for those steps. It can authenticate the caller, evaluate permissions, log the request, and pass the approved action to its destination.

Snowflake is adding financial controls to that checkpoint. The company says Cortex AI Gateway can attribute AI consumption to teams, agents, or workloads. Administrators can also set spending limits intended to stop an agent from generating uncontrolled model usage.

The gateway further promises request routing across approved models. Snowflake says routing decisions can consider quality, latency, availability, and consumption cost. That makes the product broader than an MCP proxy because it also governs model traffic.

Snowflake’s support for more than 100 MCP servers provides an early measure of connection breadth. However, the number does not establish production adoption, reliability, or security quality. Support can describe technical compatibility without revealing how many customers run those connections in important workflows.

The launch nevertheless changes Snowflake’s posture. Cortex AI was already a place to call models and build data agents. Cortex AI Gateway now seeks authority over agents developed elsewhere, including agents whose primary interface sits outside Snowflake.

That is the infrastructure signal. Snowflake wants to control the route between an agent’s request and an enterprise action, even when Snowflake did not create the agent.

Why the Cortex AI Gateway Reached Google News Now

Snowflake is responding to a governance problem created by MCP’s success as an integration standard.

MCP began as a way to make tool connections portable. A developer could expose a capability once and let multiple compatible AI clients use it. That model becomes harder to manage when dozens of agents connect to hundreds of tools across separate teams.

The protocol itself defines messages and interaction patterns. Its authorization specification provides a framework based on OAuth standards for restricted remote servers. However, enterprise governance extends beyond transport authorization.

A security team needs to know which human or service an agent represents. It must decide whether that identity can invoke a particular tool with particular parameters. It may also need approval rules, data-loss controls, audit retention, and emergency revocation.

Finance teams face a parallel problem. One workflow can invoke several models and tools before returning a result. Conventional cloud billing identifies the consumed service, but it may not explain which agent initiated the chain or which department received the benefit.

These problems create a market for an intermediary. The gateway sees traffic before it reaches models or MCP servers. That visibility lets it apply policies and record costs closer to the point of action.

Snowflake prepared for this move through Natoma. On May 27, it signed a definitive agreement to acquire the company, which built an enterprise MCP platform for AI agents. Snowflake said the deal would extend governance from data assets to AI actions and interactions.

The Natoma acquisition also promised a verified library of MCP servers. Snowflake specifically identified email, Slack, and other connected applications as sources that could enrich data already held in its platform.

The short gap between that agreement and the Cortex AI Gateway announcement shows the strategic priority. Snowflake is integrating the acquired MCP capabilities into its wider platform story rather than keeping them as an isolated connector product.

Its timing also follows Snowflake’s earlier work on AI governance. At its 2025 summit, the company described an AI Governance Gateway for model access, usage tracking, role-based control, and budget enforcement. It separately announced MCP server support for Cortex Analyst and Cortex Search.

Cortex AI Gateway combines those previously adjacent concerns. It governs model selection, MCP access, agent activity, and consumption through one proposed control plane.

That consolidation reflects how enterprise agents are changing. A conventional chatbot produces text for a user to review. An agent can retrieve private information, call a business system, or initiate a change before the user sees the outcome.

Those abilities make tool access as important as model access. A company can approve an LLM while still exposing itself through an improperly scoped connector. It can secure each application while losing visibility across the complete chain of agent actions.

Snowflake’s security integrations address parts of this challenge. The initial group includes 1Password, Aembit, Linx Security, Okta, SailPoint, and Saviynt. Their presence suggests that agent identity and access governance are becoming shared infrastructure concerns.

The gateway’s appearance across google news results is therefore tied to a larger shift. MCP connectivity is moving from developer convenience into the domains of identity teams, security operations, finance, and platform engineering.

Snowflake and Databricks Are Competing for the Same Control Plane

The central contest is Snowflake versus Databricks over whether the existing data platform should govern every model and MCP request.

Databricks has made a closely related claim with Unity AI Gateway. Its documentation describes the service as a central governance layer for agents, model endpoints, MCP servers, and coding tools.

The similarities are direct. Both platforms want to route AI traffic, enforce permissions, observe usage, and manage consumption across different providers. Both also connect this runtime layer to governance systems already used for enterprise data.

Databricks places Unity Catalog at the center of its approach. The catalog governs assets such as models, functions, and MCP servers. Unity AI Gateway then applies those permissions and policies while requests are moving through the system.

The current AI governance guide says the gateway can govern external coding agents, including Claude Code, Cursor, Codex, and Gemini CLI. It also describes rate limits, budgets, usage tracking, and request-level service policies.

Snowflake names Claude Code and Cursor in its own announcement. That overlap is important. Neither company is limiting the gateway to agents built inside its platform.

Each is trying to become the neutral control point for agents created elsewhere. Neutrality remains relative because the control layer still strengthens the surrounding data platform.

For customers, the immediate decision will often follow existing infrastructure. A company with extensive Snowflake policies, data, and operational knowledge may prefer to extend those controls through Cortex AI Gateway. A Databricks customer may see less friction in a Unity Catalog-backed path.

The longer contest is less predictable. Agents routinely work across data warehouses, software repositories, messaging systems, customer platforms, and cloud services. No single data platform owns all those destinations.

A gateway must therefore prove that it can govern resources beyond its home platform without forcing every workflow into a closed stack. Snowflake’s security integrations and Natoma connectors are meant to support that argument.

Databricks makes a similar interoperability case by covering external providers and coding agents. Its gateway remained labeled beta in documentation updated during July 2026, which leaves room for changes in availability and implementation.

Neither vendor has established a decisive lead through public adoption data. Feature lists reveal strategic convergence, but they do not show which gateway handles more production traffic or stops more policy violations.

Competition also comes from outside the data-platform category. Cloudflare has introduced MCP server portals that aggregate multiple servers behind an access layer. Its portal documentation describes OAuth support and logs for individual tool requests.

Cloudflare approaches the problem from network and access infrastructure. Identity vendors approach it through credentials and authorization. Specialized gateway companies focus on MCP discovery, inspection, and policy enforcement.

These approaches can coexist inside one enterprise, but overlapping controls create operational friction. Teams may need to decide where the authoritative policy lives and which system keeps the complete audit trail.

Duplicated gateways can also obscure responsibility. A request might pass through an agent platform, a model gateway, an MCP gateway, a network proxy, and an application authorization layer. Each system can record a different identity or decision.

Snowflake’s ambition is to reduce that fragmentation by combining the controls. The risk is that customers replace many disconnected tools with a control point closely tied to one vendor.

That tension will shape purchasing decisions. Enterprises want consistent governance, yet they also want the freedom to switch models, agents, and data systems. The winning gateway must provide centralized control without turning interoperability into dependency.

The Gateway Mechanism Makes MCP Look Like Infrastructure

MCP gateways are crystallizing as infrastructure because every useful agent connection creates recurring needs for identity, policy, routing, observability, and cost attribution.

A bare MCP connection answers a technical question: how can an agent discover and invoke a tool? An enterprise gateway answers an operational question: under what conditions should that invocation be allowed?

Consider an employee asking a coding agent to investigate a production incident. The agent might search technical documents, inspect a repository, query logs, open a ticket, and draft a change.

Each tool call inherits context from earlier steps. The agent also carries some representation of the employee’s identity, permissions, and intent. A mistake in that chain can expose data or authorize an action the employee never requested.

A gateway can evaluate the call before execution. It can reject a tool that the user cannot access, restrict parameters, or require approval for a write operation. It can also preserve a record linking the action to the initiating user and agent.

This is the policy enforcement point, meaning the place where an abstract rule becomes an allow, deny, or approval decision. The concept is familiar from API management, zero-trust access, and cloud identity systems.

Agent traffic makes the decision more complicated. Requests are often generated probabilistically, and the next tool may depend on untrusted content retrieved during an earlier step.

A document containing malicious instructions could influence an agent to invoke another tool. A compromised MCP server could return content intended to alter later behavior. A broadly scoped token could then let the agent reach data beyond the original task.

Centralized activity records help investigators reconstruct such chains. They do not prevent every attack. Prevention also requires constrained credentials, safe tool design, input validation, isolation, and careful approval workflows.

Routing adds another infrastructure function. An organization may approve several language models for different workloads. One model may suit complex reasoning, while another handles routine extraction with lower latency.

A gateway can select from approved options without requiring each application to implement separate provider logic. It can also reroute traffic when an endpoint becomes unavailable.

That flexibility can reduce application coupling. However, routing quality depends on evaluation data and clear workload policies. A gateway cannot infer business priorities reliably unless the organization defines acceptable tradeoffs.

Cost attribution is similarly valuable but difficult. Counting tokens is straightforward for a single request. Assigning the full cost of a multistep workflow to a department, project, or user requires consistent identity across every hop.

Snowflake says Cortex AI Gateway can attribute consumption to the teams, agents, or workloads responsible. Buyers should examine how that attribution behaves when an external agent calls several tools and models across separate systems.

They should also test whether budget enforcement interrupts a workflow safely. Stopping an agent midway can leave partial changes, open transactions, or incomplete records.

The infrastructure analogy becomes strongest when these controls disappear from individual applications. Developers should not need to recreate authentication, logging, routing, and budget logic for every new agent.

Standardizing those functions can accelerate deployment. It can also make the gateway a high-value target and a critical dependency.

That is why the market is converging on gateway architecture. The more portable MCP makes tool access, the more enterprises need a consistent layer to constrain that portability.

Security Claims Still Need Production Evidence

A centralized gateway improves control, but it does not make MCP connections secure by default or eliminate risks inside the tools themselves.

Snowflake’s announcement presents security and trust as the basis for agent interoperability. That is a reasonable objective, but the company has not published enough evidence to treat the claim as independently established.

The announcement does not provide production adoption counts for Cortex AI Gateway. It does not quantify blocked attacks, policy violations, routing accuracy, or savings from its consumption controls.

Its support for more than 100 MCP servers measures compatibility rather than trustworthiness. A gateway still needs accurate information about each server, its tools, its version, and its required privileges.

The security challenge extends below the gateway. An approved server can contain vulnerable code. A legitimate tool can expose dangerous parameters. An agent can also misuse a permitted capability after processing malicious context.

Government guidance underlines those limits. The NSA’s May 2026 MCP security guidance describes MCP as a de facto communication standard, but says its security posture remains uneven.

The report identifies dynamic tool invocation, implicit trust, context sharing, weak access controls, prompt injection, and token-lifecycle gaps. It says many protections depend on implementation discipline rather than protocol guarantees.

That distinction matters for evaluating Cortex AI Gateway. A gateway can centralize authentication and authorization, but it cannot retroactively make every connected server safe.

It also cannot guarantee that an agent interpreted a user’s request correctly. Permission to perform an action does not prove that the action matches the user’s intent.

Approval workflows can reduce that gap. High-risk changes should require a person to inspect the exact proposed action, its parameters, and its expected effect. Generic permission prompts offer little protection when users cannot see what an agent will do.

Buyers should ask how Snowflake handles delegated identity. An agent acting for an employee should receive only the permissions needed for that task. It should not inherit a broad service credential merely because the workflow spans several systems.

They should also examine revocation. If a user changes roles or a token is compromised, the gateway must stop further access quickly. Cached credentials and long-running agent sessions can complicate that response.

Logging creates its own tradeoff. Detailed records help with auditing and incident response, but prompts and tool parameters can contain sensitive information. Organizations need retention, redaction, and access rules for the logs themselves.

The gateway’s model routing deserves equal scrutiny. Optimizing across quality, latency, availability, and consumption sounds useful. Those goals can conflict, and an automated choice can affect output quality or data-handling obligations.

Enterprises should verify whether routing keeps data within approved regions and providers. They should also determine whether model changes are visible to application owners and reproducible during audits.

Vendor concentration presents another risk. Placing agent traffic, tool permissions, model routing, and cost controls in one system creates a broad operational dependency. An outage or policy error at that layer can interrupt many workflows simultaneously.

This does not invalidate the gateway model. It means the gateway must be assessed like identity, network, and API infrastructure rather than like a convenience feature.

Snowflake’s position may help customers already invested in its governance model. Yet buyers still need independent tests, least-privilege design, server inventories, isolated execution, and incident procedures.

The responsible reading of the google news headline is therefore narrower than Snowflake’s marketing language. Cortex AI Gateway signals where the market is heading, but it does not settle whether one platform can secure the full agent lifecycle.

What Google News Readers Should Watch Next

The gateway thesis will become credible only when adoption, enforcement evidence, and cross-platform behavior move beyond launch claims.

The first signal is production usage. Snowflake should disclose how many customers route active third-party agents through Cortex AI Gateway, not merely how many MCP servers it supports.

Useful evidence would include the number of governed tool calls, the range of external systems, and the share of workflows using enforced policies. Customer case studies should identify concrete actions rather than repeat general statements about trust.

Meltwater appeared in Snowflake’s announcement as an organization interested in securely connecting agents to data and tools. The language described Cortex AI Gateway as a step toward that result. It did not establish a completed deployment with measured outcomes.

That difference is worth tracking. Design partners can validate a product direction, while sustained production traffic tests reliability, identity mapping, and operational cost.

The second signal is enforcement quality. Snowflake needs to show that policies work across first-party and third-party agents without losing user identity or task context.

Buyers should look for granular controls over individual tools and parameters. They should also watch for approval policies, token revocation, data-loss prevention, and integrations with existing security monitoring systems.

Published incident reports would offer valuable evidence. A credible control plane should explain how it detected unsafe behavior, what it blocked, and how administrators reconstructed the event.

The third signal is competitive response. Databricks, Cloudflare, identity vendors, and independent gateway providers will keep expanding their own agent controls.

If these products converge on portable policy formats and shared audit standards, enterprises could switch gateways without rebuilding every rule. That outcome would strengthen MCP as open infrastructure.

If each platform creates proprietary identities, policy models, and logs, MCP may remain open at the connection layer while governance becomes fragmented. That would weaken the promise of interchangeable agent tooling.

Developers should follow how gateways expose debugging information. A denied request needs an understandable reason, and a routed request needs a trace showing which model and policy affected it.

Security teams should evaluate whether one gateway can see the complete action chain. Partial visibility can produce misleading assurance when an agent crosses an unmonitored system.

Enterprise buyers should also compare control-plane failure modes. They need to know whether agents stop safely when a gateway fails, whether read and write actions behave differently, and how emergency access works.

Knowledge workers have a stake in these choices because gateway policies determine which information their assistants can reach. Better controls can support useful connections without granting every agent permanent access to email, documents, and messaging systems.

Teams building searchable technical context should keep permissions attached to the source material. A well-designed engineering knowledge base reduces the need to expose broad repositories when an agent only needs selected information.

The next one to three months should clarify whether Cortex AI Gateway becomes a working control point or remains a strategic announcement. Watch for named production deployments, measurable enforcement results, and deeper integrations beyond Snowflake’s own environment.

Snowflake has made the infrastructure wager clearly. It believes enterprises will manage agents through a centralized layer that combines model routing, MCP governance, activity records, and consumption controls.

That wager looks directionally sound because portable tools create a need for portable control. The unresolved question is who earns the right to operate that control plane.

Google news coverage has captured the launch moment. The more important test begins when enterprises connect agents that can read sensitive data, spend real resources, and change production systems. Ask whether your organization can identify every agent, constrain every tool, and reconstruct every action before treating any MCP gateway as trusted infrastructure.