This blog post is AI-Assisted Content: Written by humans with a helping hand.

The Problem

A client came to us with a mandate from their CTO. They wanted their business users to ask questions of their Snowflake data in plain English, and specifically from inside Claude Desktop, not from a separate analytics tool. Claude Desktop was already where their teams worked, keeping conversation and project history, collaborating on local files, and using other integrations. Sending people somewhere else just to ask about data was friction they did not want. 

But they needed real guardrails. They wanted to control exactly which data could be queried, some assurance it would be queried correctly and an absolute guarantee that nobody could change anything in Snowflake through Claude Desktop — even users who had write access in Snowflake itself. There could be no accidental DROP TABLE, no rogue INSERT and no clever prompt that talks its way around the rules. 

What We Built

We built it on Snowflake Cortex Agents, a Snowflake-managed MCP server and OAuth authentication wired into Claude Desktop as a connector. A user asks a question in Claude Desktop, it routes to a Cortex Agent that turns the question into SQL through a semantic view, runs it read-only and returns the answer. We chose this over a custom app because it put data access inside the tool the client already lived in, and because the read-only guarantee could be built into the architecture instead of bolted on. It runs against the client’s governed Snowflake environment. Here’s what it looks like in practice:

How It Works 

We made the solution available where the business already was. For them, that was Claude Desktop, though it could have just as easily been another system such as a chat application or another AI copilot. The key is that this is the same place they already draft emails and work through problems. So, when they ask a question in plain English, something like, “Which teams have the most points this season?” they get an answer back in the conversation, with no SQL to write and no separate dashboard to open. 

Underneath, the question routes through the MCP server to the Cortex Agent, which uses a text-to-SQL tool to generate a query against a semantic view, runs it on a Snowflake warehouse and sends the results back. What makes it trustworthy for an analytics-literate user is that none of that is hidden: 

• The pipeline is transparent. In Claude Desktop you can see the tool call being made, the exact SQL Cortex Analyst generated, and the results coming back. Nothing happens off-screen. 
• It is auditable in Snowflake. Every query shows up in Snowflake’s query history under the authenticated user, so there is a real trail attributed to a real person. 
• It stays in one place. Because it is a connector inside Claude Desktop, a data question lives in the same conversation as everything else the user is working on, which is the entire reason the client wanted it there. 

For the walkthrough, we used a demo dataset (a fictitious soccer league) so the screenshots show real behavior without exposing client data. The experience is the same either way: Ask in plain English, get an answer you can trace all the way back to the SQL that produced it. It looks something like this:

How It Was Built

The solution is four Snowflake objects and a connector, and the interesting part is how they stack into governance: 

• An OAuth security integration lets Claude Desktop authenticate against Snowflake on behalf of an individual user. 
• A semantic view defines what the data means, the business concepts, metrics, dimensions and joins, and just as importantly scopes what the agent can see. If a table or column is not in the semantic view, the agent cannot query it, no matter what the user’s roles allow elsewhere. 
• A Cortex Agent defines the AI behavior and, critically, the tools it is allowed to use. 
• A Snowflake-managed MCP server exposes the agent as a callable tool that Claude Desktop connects to. 

The read-only guarantee comes from three layers working together. Role permissions control who can reach the agent at all. The semantic view controls what data is visible. The agent’s tool list controls what operations are even possible. That last layer is essential. We gave the agent only the text-to-SQL tool and deliberately left out execute_sql: 

tools: 
  - tool_spec: 
      type: "cortex_analyst_text_to_sql"   # generates analytical SQL only 
      name: "tpl_analyst" 
# no execute_sql tool, so DROP / INSERT / UPDATE have no pathway

We deliberately did not give our agent the execute_sql tool. That tool lets the agent run arbitrary SQL against Snowflake, which would undermine the read-only guarantee the client asked for. This is one of the key governance enforcement points. The tools you assign to the agent define what it’s capable of doing, and by only giving it cortex_analyst_text_to_sql, we constrain it to generating analytical queries through the semantic view. It can’t DROP, INSERT, UPDATE or CREATE anything because the tool itself doesn’t support those operations. This is your third governance layer: Role permissions control who has access, the semantic view controls what data is visible, and the agent’s tool list controls what actions can be performed against it. 

A few things tripped us up, and they are the kind of detail that costs an afternoon if you do not know them: OAUTH_USE_SECONDARY_ROLES has to be set to IMPLICIT or the connection just fails with an unhelpful error. The OAuth redirect URI has to match Claude’s callback URL exactly. The execution_environment block in the agent spec is not optional, even when the user has a default warehouse. And when you build the MCP server URL, underscores in your org or account name have to become dashes. None of these are spelled out in neon lights in the docs, and each one produces a vague failure rather than a clear message. 

This was part of a larger engagement, and the Snowflake-to-Claude piece was a few weeks of work. The harder, slower part is never the agent. It is the foundation underneath it, a clean RBAC hierarchy and a semantic layer good enough that an AI can query it reliably. 

Why It Matters

For the business users, the change is direct. A question that used to mean filing a request with the analytics team, or learning enough SQL to be dangerous, is now a sentence typed into a tool they already had open. They get the answer in the flow of their work, and they can see the query behind it. 

For the analytics team, the win is quieter, but bigger. The steady stream of ad hoc questions and the, “Can you just pull me the numbers on…?” requests that interrupt real project work now largely answer themselves. That frees the team for the higher-value work that actually needs a human analyst, which is what the CTO was after in the first place. 

Where this could go

The same architecture extends in several directions, most of them just more tools on the same agent. 

• More agent tools: Add cortex_search to bring unstructured documents into the same natural-language interface, or data_to_chart to return visualizations in the conversation instead of only tables. 
• More of the business: Expand the semantic views to cover more subject areas, widening what users can ask about without touching the security model. 
• A second front door, for free: The same semantic view and Cortex Agent also power Snowflake Intelligence inside Snowsight, so users who live in Snowflake get the same governed access without anyone building it twice. A client can turn this on themselves. 
• Beyond analytics: Expose the Cortex Agent in Slack or other important systems so the data does not just answer questions but feeds deliverables where people work. 

Each of these rides the same governed foundation. The agent gets more capable without the guardrails getting weaker. 

Takeaway

The client wanted business users asking questions of their data in plain English, in the tool they already worked in, without ever being able to change a thing. That is what they got, and the guarantee holds because it is built into the architecture, not bolted on. If you are weighing whether to hand an LLM the keys to your warehouse, the question is not the agent. It is whether the foundation underneath it can be trusted.