Snowflake Launches Cortex AI Gateway to Put Agentic AI Behind a Control Plane
Snowflake has launched Cortex AI Gateway, moving agent access, model routing, audit trails, and spending controls behind one centralized checkpoint. The shift targets a conflict that enterprises can no longer ignore. AI agents need broad access to work effectively, yet every additional connection increases security exposure and financial uncertainty.
Announced on July 28, 2026, the gateway covers Snowflake agents such as CoWork and CoCo. It also targets external tools, including Claude Code, Cursor, ChatGPT, Amazon Bedrock, Azure AI Foundry, LangChain, and LlamaIndex applications. Snowflake says the gateway will control how these agents reach models, enterprise data, applications, and Model Context Protocol servers.
The launch places Snowflake in a contest already involving AWS, Microsoft, Google Cloud, identity vendors, and specialist gateway providers. The main battle is not over which company offers the smartest agent. It concerns which platform becomes the trusted control point between agents and the systems where business actions occur.
Cortex AI Gateway Moves Agent Control Closer to Enterprise Data
Snowflake is turning its existing position around enterprise data into a bid for control over agent activity.
Cortex AI Gateway is designed as an intermediary between agents and the resources they request. Those resources include language models, databases, business applications, tools, and Model Context Protocol servers. MCP is a connection standard that lets AI applications discover and call external tools through a consistent interface.
Snowflake says the gateway will support more than 100 MCP servers. Administrators can use a central endpoint to assign authentication, permissions, access policies, and tool restrictions. This replaces separate configurations for every agent framework or application, at least within the systems the gateway can reach.
The gateway also records the sequence of an agent’s actions. That record can show which tool the agent called, which system it contacted, and who authorized the request. Security teams need this sequence because an apparently harmless request can become risky through several connected actions.
For example, a research agent might read customer records, summarize them, and then send its summary to another application. Each individual operation can look legitimate. The combined sequence can expose sensitive information outside its approved boundary.
Snowflake’s gateway announcement also connects governance with model routing and spending. The system is intended to route requests according to cost, latency, capability, availability, and data residency requirements.
IT and finance teams can attribute consumption to a team, agent, or workload. They can also apply spending limits before usage crosses an approved boundary. This matters because an agent can generate many model requests while completing one visible task.
Cortex AI Gateway builds on Snowflake’s acquisition of Natoma in May 2026. Natoma developed an enterprise MCP gateway that applied identity, policy, and auditing at the tool-call level. Snowflake is now incorporating that approach into its wider data and AI platform.
However, the launch is not a single, finished product release. Snowflake says Cortex AI Gateway will enter public preview soon. Several related capabilities, including intelligent model routing and access governance, remain in private preview.
That release status defines the central tension. Snowflake has presented a broad control-plane architecture, but customers still need to validate its coverage, reliability, and operating burden in production.
Why Agentic AI Creates a Different Security Problem
An AI agent is not merely another user, because it can chain actions faster and across more systems than a person.
Traditional identity systems usually decide whether a human user can access an application or dataset. Agentic systems complicate that model. An agent can act for a user, call another agent, select a tool, and transform data before sending a result elsewhere.
Using the person’s full permissions creates an obvious risk. A user might have broad access because their job involves several responsibilities. A temporary agent task rarely needs that entire permission set.
Snowflake’s answer is task-scoped access. An agent working on a read-only analysis should remain unable to modify records, even when its human sponsor has modification rights. This follows least privilege, meaning each identity receives only the access required for a specific operation.
The company has also made Agent Identity generally available. This capability marks agent activity separately within Snowflake’s account usage records. Policies can respond differently when an agent, rather than a person, participates in a session.
That distinction supports both investigations and preventive controls. A security team can identify whether a request came from an employee, a Snowflake-native agent, or an external agent. It can then apply different limits and review requirements.
Restricted Session Scope adds another boundary by limiting what a particular session can do. Snowflake says that feature is approaching general availability. Context-aware access policies, which evaluate identity, network, and client information together, remain in private preview.
These controls address risks that prompt instructions cannot reliably solve. Telling an agent not to reveal confidential information is not equivalent to blocking the underlying data transfer. Deterministic authorization must operate outside the model’s reasoning process.
The same principle appears in the OWASP risk framework. Its guidance covers excessive agency, sensitive information disclosure, prompt injection, and unsafe handling of model outputs. These risks often emerge when systems trust model-generated decisions without separate enforcement.
Prompt injection is especially relevant for agents. A malicious instruction can arrive through a document, website, message, or tool response. If the agent treats that material as authoritative, it might attempt actions its user never requested.
A gateway can inspect and restrict the resulting tool call, even when it cannot determine exactly why the model produced it. This does not eliminate prompt injection. It limits what a compromised reasoning process can reach and records what happened afterward.
Snowflake is also adding AI security posture management through its Trust Center. The company says this generally available feature scans for risky configurations and supports programmatic remediation. Its Data Exfiltration Prevention package is in preview and targets unauthorized data movement.
These layers show why agent governance is becoming infrastructure rather than a policy document. Organizations need identity, permissions, runtime enforcement, logging, and incident evidence. A model safety statement cannot replace those controls.
The Real Contest Is Over the Agent Control Plane
Snowflake is competing to govern agent connections, not simply to supply another agent development environment.
AWS, Microsoft, and Google Cloud are building comparable layers around identity, tools, observability, and runtime policy. Each vendor starts from a different strategic position. AWS controls cloud infrastructure, Microsoft has enterprise identity and workplace distribution, while Google combines models, cloud services, and agent protocols.
AWS Bedrock AgentCore Gateway converts APIs and functions into tools that agents can call. It also supports MCP-based access and authorization. The AgentCore gateway gives AWS customers a managed entry point between agents and enterprise services.
Microsoft is placing agent identities inside its broader Entra security model. That direction treats an agent as a governed digital identity with ownership, credentials, and lifecycle controls. It aligns agent oversight with security systems that many enterprises already use for employees and applications.
Google Cloud has emphasized agent interoperability, infrastructure, and visibility across connected workloads. Its advantage comes from Gemini, cloud infrastructure, and protocols such as Agent2Agent. Those assets give Google several possible control points beyond the data platform itself.
Snowflake’s counterargument is based on data gravity. Many enterprise agents ultimately need governed business data, semantic context, or analytical results. Snowflake wants organizations to enforce agent policy where that information already has roles, classifications, masking rules, and audit records.
This position can reduce duplicated policy work. If an agent accesses a protected table, existing row and column controls can continue to apply. Security teams do not need to recreate every data rule inside each agent framework.
Yet data governance and agent governance are not identical. An agent can act outside the data platform by sending messages, changing application settings, opening support tickets, or running code. Snowflake must therefore extend its control beyond queries without weakening its data-centered advantage.
Its security partnerships address that requirement. Snowflake announced integrations with 1Password, Aembit, Linx Security, Okta, SailPoint, and Saviynt. These vendors contribute credential management, workload identity, access governance, and runtime authorization.
Okta’s planned integration is intended to bring third-party agents inside centralized identity policies. Snowflake says it is scheduled for private preview in the fourth quarter of 2026. Integrations with several other partners are also expected to enter private preview.
The Black Hat overview describes support for external environments including ChatGPT, Claude Code, Cursor, Amazon Bedrock, and Azure AI Foundry. That breadth is strategically important because large organizations rarely standardize on one agent platform.
The open question is whether enterprises will accept one central gateway. Security teams value consistent policy, but application teams often resist bottlenecks that add latency or delay deployment. Different business units may also choose gateways native to their existing cloud platforms.
A company running most workloads on AWS can favor AgentCore. A Microsoft-centered organization may prefer Entra-based identities and Azure controls. Snowflake becomes more compelling when governed data access is the dominant requirement across those environments.
The contest will therefore be decided through integration quality rather than feature lists. A control plane must recognize identities, preserve user context, enforce policies, and create usable audit records across heterogeneous systems. Missing one connection can create a path around the central gate.
Centralized Governance Adds Its Own Tradeoffs
A gateway reduces fragmented controls, but it also creates a sensitive enforcement point that must remain available and correctly configured.
Centralization makes policy easier to see. It can also concentrate failure. An outage, configuration error, or compromised administrative account can affect many agents at once.
Enterprises will need clear answers about failure behavior. A gateway should not silently grant access when policy services become unavailable. However, failing closed can interrupt business workflows that depend on agents.
Latency presents another issue. Each agent task can involve several model requests and tool calls. Policy evaluation, tracing, and model routing add work to each step. Small delays can accumulate across a long chain of actions.
Snowflake has not published independent performance comparisons for these new gateway functions. Buyers should therefore treat routing and efficiency claims as product objectives until production benchmarks become available. Preview deployments need measurements across ordinary and peak workloads.
Policy complexity can also move rather than disappear. A central console may replace dozens of scattered configurations, yet administrators still need to define task scopes and exceptions. Poorly designed rules can block useful work or preserve excessive access.
Tool descriptions deserve particular attention. Agents choose MCP tools partly from machine-readable names and instructions. An inaccurate, compromised, or ambiguous description can cause the model to select the wrong operation.
Authorization should evaluate the actual operation, not only the tool’s label. High-impact actions may require additional confirmation, approval, or transaction limits. Deleting records and initiating payments require tighter treatment than retrieving public documentation.
Audit records also need context. A log showing that an agent called a tool does not automatically explain why the action was reasonable. Investigators need the requesting identity, delegated authority, policy decision, parameters, output destination, and sequence of preceding actions.
That creates a data-management challenge of its own. Detailed traces can include prompts, business records, personal information, or secrets. Organizations must protect the evidence they collect for security purposes.
Retention policies will differ across industries and jurisdictions. Keeping every trace indefinitely can increase privacy and legal exposure. Deleting evidence too quickly can undermine investigations and compliance reviews.
Model routing introduces another tradeoff. Sending simple tasks to less expensive models can control consumption. However, a routing system must prevent sensitive prompts from reaching models or regions that lack approval.
Snowflake says routing can consider data residency and capability alongside cost and latency. Customers should verify those decisions through logs and tests. They should not assume that automatic optimization always matches internal risk classifications.
The product’s preview status makes this testing essential. Cortex AI Gateway itself is expected in public preview, while many gateway capabilities remain private. The supporting partner integrations also have different delivery schedules.
Snowflake explicitly warns that forward-looking product statements are not commitments. Availability, functionality, and timing can change. Enterprises should separate generally available controls from planned architecture when designing production safeguards.
The gateway also cannot govern connections that bypass it. Developers may use unmanaged credentials, direct model APIs, local MCP servers, or personal AI tools. Discovery of shadow agents and shadow MCP servers is therefore as important as enforcement for known systems.
Snowflake says automatic discovery and monitoring are part of its roadmap. Their effectiveness will depend on network coverage, identity integration, and customer configuration. No single vendor can detect every local or external path without broad operational access.
This is the main skeptical test for Snowflake’s control-plane claim. The platform can offer a strong gate for traffic that passes through it. It must still prove that enterprises can identify and redirect enough agent activity to make the gate authoritative.
What Cortex AI Gateway Changes for Enterprise Buyers
The launch gives buyers a clearer architecture for agent governance, but it also raises the standard for product evaluation.
Enterprises should begin with a complete agent inventory. That inventory needs to include native agents, third-party assistants, custom frameworks, MCP servers, model providers, service accounts, and business applications. Unknown agents cannot be governed consistently.
Each agent also needs an owner. Ownership determines who approves access, reviews incidents, and retires unused credentials. Treating agents as temporary experiments often leaves identities and connections active after their original project ends.
Teams should then map actions rather than applications. One agent can perform low-risk research and high-risk system changes through the same interface. Policies should distinguish those operations and apply stronger checks to consequential actions.
A useful evaluation should test at least four boundaries. First, can the gateway preserve the human user’s identity through every delegated step? Second, can it reduce permissions to the task’s actual scope?
Third, can administrators reconstruct a multi-tool sequence after an incident? Fourth, can the system stop or constrain an action before execution? Monitoring without enforcement leaves the most important risk unresolved.
Buyers should also compare how competing platforms handle portability. A policy tied to one cloud, model provider, or agent framework can create operational lock-in. MCP support improves connection portability, but it does not standardize every authorization decision.
Identity mappings can differ across Snowflake, AWS, Microsoft, Google Cloud, and SaaS applications. A role recognized in one system may not carry the same meaning elsewhere. Cross-platform governance must preserve both identity and policy intent.
Snowflake’s partnership approach acknowledges this gap. Identity and security vendors can translate external context into controls that Snowflake understands. The success of those integrations will depend on how much information survives each handoff.
Cost governance should receive equal attention. Agents can call models repeatedly, retry failed steps, and generate background activity that users never see. Attribution by team, agent, and workload helps finance teams connect consumption with business value.
Spending limits are useful, but they need careful failure behavior. An agent should not abandon a critical process midway without producing a clear status. Workflows may need fallback models, approval paths, or safe stopping points.
Organizations should also test route quality. A lower-cost model may perform adequately on classification but fail on specialized reasoning. Automatic routing needs task-specific evaluation rather than a general assumption that simpler prompts are interchangeable.
Security teams can use adversarial tests to examine tool misuse. Test cases should include malicious instructions inside documents, unexpected tool outputs, privilege escalation attempts, and requests that cross data-residency boundaries. Every denied action should create an understandable record.
Knowledge workers need transparency as well. Users should know when an agent acts under their authority and which permissions it receives. They should have a practical way to review, correct, or stop delegated activity.
That requirement connects governance with daily workflow design. A secure agent system cannot depend on security administrators reviewing every harmless action. It needs graduated controls that reserve human approval for sensitive or irreversible operations.
For teams organizing the supporting evidence behind agent decisions, a searchable technical knowledge base can preserve requirements, policy notes, and incident context. It does not replace runtime authorization, but it can improve review and accountability.
The strongest buying approach is incremental. Start with bounded, reversible tasks and measure denial rates, latency, trace quality, and operating effort. Expand access only after the control layer behaves predictably under ordinary failures and adversarial inputs.
Three Signals Will Show Whether Snowflake Can Own the Gateway
Snowflake’s control-plane strategy will become credible through adoption and operational evidence, not through announcement breadth.
The first signal is the public preview of Cortex AI Gateway. Buyers should watch which advertised capabilities actually arrive together. Central policy, tracing, spending controls, and model routing create more value as an integrated system than as separate previews.
Preview documentation should clarify supported agents, MCP transports, authentication methods, regional availability, and failure behavior. It should also explain how customers export audit data into existing security operations platforms.
Performance evidence matters at this stage. Snowflake should publish or enable repeatable measurements for routing latency, policy evaluation, trace completeness, and gateway availability. Customer testing will reveal whether the control layer remains practical for multi-step workloads.
The second signal is delivery of the identity partnerships. Okta’s integration is planned for private preview in the fourth quarter of 2026. Other announced integrations are also expected to enter private preview.
These connections will test Snowflake’s claim that external agents can operate under consistent identity rules. Successful integration should preserve the requesting user, the agent identity, the delegated task, and the final policy decision.
A weak implementation might identify the external application but lose task-level context. That would improve visibility without delivering true least-privilege control. Buyers should ask whether authorization is evaluated for every action or only when a session begins.
The third signal is evidence of production adoption across mixed environments. Snowflake named Meltwater, BlackRock, and Thomson Reuters while discussing its broader AI security strategy. Public case studies should eventually show which gateway functions those customers deploy.
The most useful evidence will include operational outcomes. Buyers need to know whether customers reduced unmanaged connections, contained excessive permissions, detected suspicious tool calls, or attributed model consumption more accurately.
Snowflake should also disclose how customers handle exceptions and outages. A governance platform proves itself when policies conflict, integrations fail, or an agent attempts an unexpected action. Perfect demonstrations reveal little about those conditions.
Competitor responses will provide another useful comparison. AWS, Microsoft, and Google Cloud are unlikely to leave agent governance to an independent data platform. They can bundle control features with infrastructure, identity, models, and developer tools.
Snowflake does not need to replace those platforms to succeed. It needs to become the trusted policy point for agent interactions involving enterprise data and connected tools. That is a narrower claim, but still a significant one.
Its advantage is strongest where organizations already rely on Snowflake governance and need several agent ecosystems to share that context. Its advantage weakens when most actions remain inside another cloud’s tightly integrated stack.
Cortex AI Gateway therefore represents more than a security feature. It is Snowflake’s attempt to define where enterprise authority should sit when software begins taking actions for people.
The architectural idea is sound. Agents need distinct identities, limited permissions, enforceable tool policies, traceable actions, and spending boundaries. The unresolved question is whether Snowflake can apply those controls broadly without becoming another isolated layer.
Enterprise buyers should watch the public preview, partner integrations, and production evidence in that order. Those signals will show whether Cortex AI Gateway becomes a genuine cross-platform control plane or remains strongest within Snowflake’s own orbit.
For now, organizations should not wait for one vendor to solve every governance problem. They can inventory agents, narrow permissions, isolate sensitive actions, and demand complete audit trails today. The next wave of agent adoption should be measured by controllability, not by how many autonomous tasks a demonstration can complete.
