Source: Snowflake Blog — 2026-07-28
Summary
Announced at Black Hat 2026, Snowflake's Cortex AI Gateway is a centralized control layer, built on Snowflake's May 2026 acquisition of Natoma, that governs which tools, models, and data each AI agent can reach across more than 100 MCP servers. It enforces identity, policy, and audit checks at the level of each individual tool call rather than just at session start, with real-time spend tracking and rate limiting built in.
Key Takeaways
- Cortex AI Gateway sits centrally in front of 100+ connected MCP servers, acting as a single control point instead of leaving access decisions scattered across individual agent configurations.
- It checks identity and policy per tool call, not once at session start — so an agent that was fine to call one tool can still be blocked from calling a different one moments later.
- It builds on Snowflake's May 2026 acquisition of Natoma, folding that acquired technology into Snowflake's own Cortex stack.
- Real-time spend tracking and rate limiting are built into the same layer, so cost control and access control are enforced by the same checkpoint rather than separate systems.
Reel Script
Hook (~15-20s, 35-45 words) Most companies giving AI agents access to tools right now are trusting the agent's own config to decide what it's allowed to touch. Snowflake just built the thing that should have existed from day one: a single checkpoint every tool call has to pass through.
Core Concept (~45-90s, 105-200 words) Here's the problem this solves. An agent connected to MCP servers — the protocol that lets AI agents call external tools and data sources — typically gets its permissions baked in at setup time. Session starts, agent gets a set of allowed tools, and after that, it's basically trusted. That's fine until an agent is compromised, misconfigured, or just does something you didn't anticipate mid-session. Snowflake's Cortex AI Gateway, built on their Natoma acquisition from earlier this year, moves that trust decision from "once at the start" to "every single time." Every tool call — not every session, every call — gets checked against identity and policy before it's allowed to execute. It sits in front of over 100 MCP servers as one governance layer, so instead of each agent's own config being the source of truth for what it can access, there's one external checkpoint that actually enforces it.
Hands-On (~45-150s, 105-350 words) Picture the flow. An agent wants to call a tool — say, query a database or hit an internal API — and that tool lives on one of the 100-plus MCP servers Cortex AI Gateway sits in front of. Instead of the agent just calling it directly, the request routes through the gateway first. The gateway checks three things: who is this agent, actually — its verified identity, not just a config flag; is this specific tool call allowed under policy for this agent right now; and is this agent within its spend and rate limits for the period. If all three pass, the call goes through and gets logged. If any one fails, it's blocked and logged. Same audit trail either way. Compare that to the old model, where the agent's own configuration was effectively the security boundary — if that config was wrong, overly permissive, or the agent got compromised, there was no external layer catching it before damage was done. Here, the check happens outside the agent, on every call, so a compromised or misbehaving agent can't just talk its way past a rule it was supposed to follow.
Takeaway (~20-30s, 45-70 words) Per-call enforcement instead of per-session trust is the right instinct as agents get access to more tools and more data. If you're running agents against MCP servers today, ask whether you have anything checking each individual call, or whether you're still trusting the agent's own setup. This is the pattern to copy either way.