The Snowflake MCP server lets Claude, Cursor, ChatGPT, and AI agents query your warehouse in plain English via Cortex. Here's the official setup, the NL→SQL blast radius, and how to deploy it with column-level redaction at the MCP layer.
The Snowflake MCP server is a Model Context Protocol implementation that exposes your Snowflake account's Cortex AI surface and SQL engine as a standardized set of tools to external AI agents. Once connected, an agent like Claude can translate a plain-English question into SQL, run it against governed data, search unstructured documents semantically, and execute direct queries — all on the authenticated user's behalf.
Refer to the official Snowflake-managed MCP server documentation and the Snowflake managed MCP announcement for the current tool catalog, OAuth setup, and RBAC model. The managed server bundles four capabilities: Cortex Analyst (natural-language-to-SQL over semantic views), Cortex Search (semantic retrieval across unstructured data), Cortex Agents (invoke an agent as a tool), and SQL execution (direct queries, with an optional read-only mode). Authentication runs through Snowflake's built-in OAuth, and each session operates under the user's default role.
From the user's perspective, the AI agent suddenly understands the warehouse — ask in English, get an answer. From the security perspective, the agent now has query reach across every database, schema, and table that default role can touch.
That's the value. It's also exactly where security teams need a control layer.
Connect the Snowflake MCP server and your warehouse gains a conversational analyst. Scoped to the role it runs as, an agent like Claude or Cursor reaches the databases, schemas, and tables that role can see — and answers in plain English instead of SQL. Day to day, it can:
.webp)
SALES, FINANCE, and PRODUCT schemas in a single prompt and have the agent assemble the narrative and the numbers together.Every one of those actions runs through Snowflake's own RBAC and Cortex services — which is what makes it genuinely powerful, and exactly why the regulated rows it can pull back need an inspection layer in the tool-call path before they reach the model.
The warehouse is the single largest concentration of regulated data most companies own. Pointing an AI agent at it through MCP creates four distinct exposures every healthcare, fintech, and enterprise security team should price in.
1. One question has an enormous blast radius. A human analyst writes a careful WHERE clause and LIMIT. A natural-language query through Cortex Analyst can resolve to a SQL statement that scans and returns millions of rows. There is no WHERE not_regulated = true — a single English sentence can pull an entire customer table into the model's context.
2. Analyst roles are broad by design. Snowflake RBAC is real, but the roles that make Cortex Analyst useful — the ones with SELECT across the analytics schemas — are usually wide. The MCP session runs under the user's default role, so the agent inherits whatever that role can see, which in most warehouses is a lot.
3. Sensitive columns come back raw. SSN, MRN, PAN, DOB, EMAIL — if those columns sit in tables the role can read, an NL→SQL or direct SQL call returns them in cleartext. Snowflake's own dynamic data masking only fires if every sensitive column is already tagged and policied, which in practice is rarely complete across hundreds of tables.
4. Bulk export is a single tool call away. SQL execution and large result sets mean an agent can pull thousands or millions of regulated rows out of the warehouse and into an external model context in one invocation — a data movement no traditional egress DLP ever sees.
The DLP a company already runs — at the network edge, on the SaaS app, inside the warehouse's own masking policies — does not sit in the MCP path. The result set goes straight from Snowflake into the AI agent's context window. That reach is precisely why each agent's access and actions in Snowflake must be governed: controlled (what it can query and export), the rows it touches protected down to the column, and every call audited. That is where Strac Snowflake MCP DLP lives. The same ingress problem shows up across every data store an agent can reach — see the MCP DLP pillar and AI DLP for the full pattern.
Strac's Snowflake MCP DLP is the governance layer that sits between AI agents and the Snowflake MCP server. It follows a simple model — See, Control, Protect, Prove:
SSN, MRN, or card-number column is protected while the rest of the row stays usable.What this looks like in practice:
The same Strac MCP DLP layer covers sibling warehouses and stores — see Databricks MCP, BigQuery MCP, and Postgres MCP — one control plane across every place AI agents touch your regulated data.
MCP DLP protects the AI-agent surface. Strac's native Snowflake DLP protects the data store itself — continuously scanning and classifying which columns across your databases hold SSNs, card numbers, health data, and financial identifiers, before any agent ever asks. This is classic DSPM: you can't govern at the MCP layer what you haven't first discovered in the warehouse. Most enterprises run both — native scanning to build the sensitive-data map, MCP DLP to enforce it in the agent path.
What Strac's native Snowflake DLP includes:
For the broader data-store posture this sits inside, see DSPM for AI. For the full integration catalog — every SaaS, cloud, warehouse, browser, and endpoint surface Strac covers — see strac.io/integrations.
The screenshot below shows Strac's MCP DLP redacting sensitive data from a real Claude session — patient identifiers, customer emails, and credit card numbers tokenized inline before the model received the prompt. The same column-level inspection runs on every Snowflake MCP result set routed through Strac.
Setup is agentless and takes under 10 minutes.
json
"mcpServers": {
"snowflake": {
"url": "https://mcp.strac.io/snowflake",
"auth": { "type": "bearer", "token": "<your-strac-token>" }
}
}
For Cursor, OpenAI Agents, and custom agents — same endpoint, same auth.The same Strac Snowflake MCP DLP control produces evidence mapped to every major compliance framework. Because data warehouses are where healthcare and life-sciences companies concentrate PHI, HIPAA is the sharpest edge here — a single NL→SQL query can otherwise pull an entire patient cohort into a model context with zero accounting of the disclosure.
For the broader AI-data-governance program this sits inside, see DSPM for AI.
The Snowflake-managed MCP server is a Model Context Protocol implementation that lets external AI agents (Claude, Cursor, ChatGPT, custom agents) reach into your warehouse via standardized tool calls. It exposes Cortex Analyst for natural-language-to-SQL, Cortex Search for semantic retrieval, Cortex Agents, and direct SQL execution — all scoped to what the authorizing role can read across your databases, schemas, and tables.
Cortex is Snowflake's native AI layer — Cortex Analyst, Cortex Search, and Cortex Agents all run inside Snowflake's governance boundary, operating on your data without it leaving the account. The Snowflake MCP server points the other direction: it exposes those same Cortex capabilities, plus raw SQL, to external agents over the open Model Context Protocol, so the AI client your team already uses can reach in and query. Cortex keeps the work inside Snowflake's guardrails; MCP lets an outside agent pull rows out, and the result set leaves those guardrails the moment it returns to the client. That hand-off is exactly where Strac Snowflake MCP DLP inspects and redacts — at the column level.
By itself, no — not without an MCP-layer DLP control. The managed server honors RBAC, but the analyst roles that make Cortex Analyst useful are broad, and a single NL→SQL query can return millions of rows with SSNs, MRNs, and card numbers in cleartext. For regulated workloads you need a layer like Strac Snowflake MCP DLP that inspects and redacts the result set — column by column — before rows reach the model.
Strac inspects every returned result set and applies column-level handling: a flagged SSN, MRN, or PAN column is redacted, masked, or tokenized inline while the non-sensitive columns in the same row pass through unchanged. The agent still gets usable aggregates and context; the regulated values never enter the model. Optionally, sensitive values are vaulted — replaced with a short-lived retrieval reference that only authorized users can resolve.
Yes. Strac's gateway sees the query before and the result set after execution, so it can cap row counts, block access to flagged sensitive tables, or route oversized and high-risk pulls for approval — stopping bulk export at the tool-call boundary instead of discovering it after the rows have already reached an external model.
Yes. Strac exposes a standard MCP endpoint, so any MCP-aware AI client routes its Snowflake tool calls through it with one configuration change. No SDK changes, no warehouse re-permissioning, no application code changes.
Snowflake's masking policies are powerful but only fire on columns you've already tagged and policied — which is rarely complete across hundreds of tables, and doesn't account for the AI-agent access path or produce per-query audit evidence for it. Strac sits in the MCP path itself, inspects every result set regardless of whether a native policy exists, and logs each agent query as compliance evidence.
Yes. Strac produces a per-call audit log: timestamp, AI client identity, role, user, statement run, databases / schemas / tables / columns touched, row counts, data classes detected, redactions applied, vault references, disposition. It's queryable in the Strac console and exportable to your SIEM — the evidence trail SOC 2, HIPAA, PCI, and GDPR auditors ask about for AI-agent activity in the warehouse.
Under 10 minutes for the first account. OAuth Strac into Snowflake, paste the Strac MCP endpoint into your AI client's config, pick a policy template, done. No agents to install, no Cortex changes, no warehouse re-permissioning.
The Snowflake MCP server is fast becoming the way AI agents query the warehouse — and the warehouse is the single largest concentration of regulated data most companies own. A natural-language question that used to need a careful analyst and a LIMIT clause can now return millions of PII, PHI, and PCI rows into a model's context in one tool call. Running Snowflake MCP in 2026 without an MCP-layer DLP control isn't a question of if the first oversized pull reaches your security team; it's when.
Strac Snowflake MCP DLP gives you the governance layer — See, Control, Protect, Prove — with column-level redaction, bulk-export guardrails, automatic audit evidence, and framework-agnostic compliance coverage, so your team can query Snowflake with Claude, Cursor, ChatGPT, and any future AI client without making each one a separate security exception.
If you are running — or about to run — Snowflake MCP in production, book a 30-minute demo. We'll walk through the architecture, the column-level policy templates, and a deployment plan for your specific Snowflake account and AI clients.
For the broader MCP DLP control plane across every data surface, see the MCP DLP pillar. For more data-store deep dives: Databricks MCP, BigQuery MCP, Postgres MCP, and the Salesforce MCP and Slack MCP SaaS guides.
.avif){kind=icon}
.gif)
