Snowflake Cortex Analyst is great, if you never leave Snowflake.
If Snowflake is your whole estate, Cortex Analyst is close to the obvious answer and this page will not talk you out of it. The costs are worth naming anyway, because two of them are architectural and one of them is a default your account is probably still running.
What Cortex Analyst gets right.
This is a well-built product and the parts it gets right are the hard parts. Take the section below at face value.
Semantic views are real database objects
Logical tables, dimensions, facts, metrics and relationships, defined as first-class objects in Snowflake rather than as a YAML file on a stage. That is the right architectural call and it is the one most of this category has not made.
It inherits RBAC instead of reimplementing it
Snowflake's documentation says the SQL Cortex Analyst generates and executes adheres to established access controls. Your existing row access policies, masking policies and roles apply without a second permission model to keep in step. This is genuinely the strongest thing about it.
Nothing leaves the account
Inference happens inside Snowflake's governance boundary. For a team whose security review is mostly about data egress, that answer is short and it is true.
There is no infrastructure
No gateway, no service to run, no credential to broker. If you already have Snowflake, you already have the whole deployment.
CORTEX_USER is granted to PUBLIC by default.
Snowflake documents this plainly and it still surprises most people who read it. PUBLIC is automatically granted to every user and every role in the account.
The composition is the part to hold: the SNOWFLAKE.CORTEX_USER database role is granted to PUBLIC by default, and PUBLIC is held by everyone. So unless someone has revoked it, every user in your Snowflake account can call Cortex features, Cortex Analyst included.
This is not a vulnerability and Snowflake is not hiding it. RBAC still applies underneath, so a user querying through Cortex Analyst sees what their role could always see. What changes is the surface: a natural language interface over the warehouse is available to a population you never scoped for it, and the audit question stops being "who has the analyst seat" and becomes "who in the account has a role at all".
Two minutes of SQL closes it if you want it closed. Note that Snowflake also offers a narrower role: CORTEX_USER covers all the AI features, and CORTEX_ANALYST_USER covers only Analyst, which is the one to grant if Analyst is what you are enabling.
-- Check the default first. If this returns PUBLIC, every user in the
-- account can call Cortex today.
USE ROLE ACCOUNTADMIN;
SHOW GRANTS OF DATABASE ROLE SNOWFLAKE.CORTEX_USER;
-- Take it off PUBLIC.
REVOKE DATABASE ROLE SNOWFLAKE.CORTEX_USER FROM ROLE PUBLIC;
-- Grant the narrow role to the people who are meant to have it.
-- CORTEX_ANALYST_USER covers Cortex Analyst only. CORTEX_USER covers
-- every AI feature, which is more than most teams intend to enable.
CREATE ROLE IF NOT EXISTS cortex_analyst_users;
GRANT DATABASE ROLE SNOWFLAKE.CORTEX_ANALYST_USER TO ROLE cortex_analyst_users;
GRANT ROLE cortex_analyst_users TO ROLE analyst;
GRANT ROLE cortex_analyst_users TO ROLE supply_chain_manager;Run the first statement before you finish reading this page. It is the one thing here that is worth acting on today regardless of which product you end up choosing.
Snowflake-hosted models only. You do not pick.
The models are good. That is not the same as the models being yours.
Snowflake's documentation describes Cortex Analyst selecting at runtime from a preference order of Snowflake-hosted models, which currently includes Anthropic and OpenAI models alongside Snowflake's own. The quality question is therefore settled: these are strong models and the routing is sensible.
The control question is a different one. You do not choose the model, you cannot pin a version for reproducibility, you cannot route a cheap question to a cheap model, and you cannot bring your own provider keys or an endpoint inside your own VPC. The commercial terms you may already have negotiated with a model vendor do not apply, because you are not the one buying the inference.
That matters in three specific places. It matters when an answer changes and you need to know whether the model changed. It matters when your legal team has an agreement with a model provider and wants inference to run under it. And it matters when your AI strategy is deliberately multi-provider, because this is the one component of it that cannot participate.
Snowflake compute, on Snowflake data.
The generated SQL runs on your Snowflake warehouses, against what is in Snowflake.
For the estate that is entirely in Snowflake this is a feature and not a cost. There is one place the data lives, one place the compute happens, and one bill.
For everyone else it is the shape of the project. Cortex Analyst can answer questions about data Snowflake can reach, so the ERP that is not in Snowflake, the POS extract that lands in S3 as Parquet, the planning system with an API and no warehouse connector, and the Postgres instance behind the e-commerce site all become ingestion work before they become answerable. That work is the data warehouse project, and it is the one most teams were hoping the AI layer would let them defer.
The honest framing is that Cortex Analyst is excellent at the last mile and assumes the first mile is finished. Whether that is a cost depends entirely on how much of your estate is already inside Snowflake, and that is a number you have.
| Question | Cortex Analyst | Ward |
|---|---|---|
| Where inference runs | Snowflake-hosted models, selected at runtime | Your provider keys, or an endpoint in your own VPC |
| Which model answers | Snowflake decides | You route it, per task |
| Where query compute runs | Snowflake warehouses | Pushed down to each source, Snowflake included |
| What it can answer about | Data Snowflake can reach | Snowflake plus the sources you connect, read in place |
| Semantic definitions | Semantic views, authored by your team | Drafted by Ward AI from reports you publish, approved as a diff |
| Access control unit | Snowflake roles and policies, inherited | Per-agent scope evaluated per call, over the warehouse grant |
| Audit surface | Snowflake query history and account usage | One record per call covering people and agents, streamed to your SIEM |
What that audit record contains, field by field, with the DDL to land it in your own warehouse. The audit log schema →
When Cortex Analyst is the right answer.
These are real cases and there are a lot of teams in them.
- Snowflake is your estate. If the answer to "where is the data" is one word, most of this page is theoretical for you.
- Your governance is already expressed in Snowflake roles, row access policies and masking policies, and you would rather inherit it than restate it anywhere else.
- Data egress is the central question in your security review. Inference inside the account is a short answer to a hard question.
- You have a team that will author and maintain semantic views. Cortex Analyst is only as good as the semantic model behind it, and that is work.
- You have no multi-provider AI requirement and do not expect one. If model choice is not a constraint you have, it is not a cost you are paying.
If Snowflake is your warehouse, it stays your warehouse.
Ward connects to Snowflake on a read-only service account scoped to tables you name, and reads it in place. Nothing is copied out to make that work and revoking the role returns you exactly to where you started. The case for putting Ward in front is that your other systems become answerable in the same sentence as your Snowflake data, that inference runs on your own model contracts, and that one log covers every caller. If none of those three is a problem you have, Cortex Analyst is a shorter path and you should take it.
The longer version, for the person who owns the warehouse: for data and analytics leaders. The category argument: a semantic layer an agent cannot route around.
The questions that arrive with this one.
Answered without assuming you have picked a side. Every claim about Snowflake Cortex Analyst here is checkable in their documentation.
Yes. Snowflake's documentation states that the SNOWFLAKE.CORTEX_USER database role is granted to the PUBLIC role by default, and PUBLIC is automatically granted to all users and roles. In practice that means every user in the account can call Cortex features, including Cortex Analyst, unless an administrator has revoked it. Underlying RBAC still applies, so nobody sees data their role could not already query, but the natural language surface is available to a wider population than most teams intend. Revoking the database role from PUBLIC and granting SNOWFLAKE.CORTEX_ANALYST_USER to named roles instead is the usual fix.
Snowflake-hosted models, selected at runtime. Snowflake documents a preference order that currently includes Anthropic Claude and OpenAI GPT models alongside Snowflake's own Arctic model and a Mistral and Llama combination. You cannot choose the model, pin a version, or bring your own provider keys or endpoint. For teams whose model choice is fixed by a vendor agreement or a multi-provider strategy, this is the constraint that decides the evaluation.
It queries what Snowflake can reach. The generated SQL executes on Snowflake warehouses against Snowflake-accessible data, so sources that are not in Snowflake have to be brought in first through ingestion, external tables or Iceberg. If most of your estate is already in Snowflake this is not a cost. If your ERP, POS and lake are elsewhere, the ingestion work is the project, and it is the same project you would be doing without an AI layer.
Yes, and this is the strongest thing about it. Snowflake's documentation says the SQL Cortex Analyst generates and executes adheres to established access controls, so your existing roles, row access policies and masking policies apply without a second permission model. Stage-based semantic models inherit stage permissions. The gap to be aware of is not row-level enforcement, it is that the unit of identity is a Snowflake role rather than a per-agent scope, so several agents sharing a role are indistinguishable in the record.
Cortex Analyst is a natural language interface to data that is already in Snowflake, running on Snowflake-hosted models and Snowflake compute, inheriting Snowflake RBAC. Ward is a warehouse, semantic layer and governed agent runtime that reads the sources you already run, Snowflake among them, in place and on read-only credentials, routes inference to your own model providers on your own keys, and evaluates a per-agent scope on every call. If your estate is one warehouse and your model choice is not a constraint, Cortex Analyst is the shorter path. If either of those is untrue, the difference is the whole evaluation.
They can, and the semantic work is not wasted either way. Ward reads Snowflake in place on a read-only role scoped to named tables, so adding it does not displace anything and revoking the role reverses it completely. Teams that run both usually keep Cortex Analyst for questions entirely inside Snowflake and use Ward where a question crosses into systems Snowflake does not hold, or where a scoped agent identity and a single audit record across sources is what the security review asked for.
Check it rather than take it from us.
Free to deploy, 5% of model spend
No license, nothing per seat. Setup is one-time: $0 self-guided, $7,500 guided, $20,000 managed, $50,000 and up for a program.
See the numbers →The audit log, with the schema
What a complete agent audit record contains, field by field, with copy-pasteable DDL and the SOC 2 mapping.
Read the schema →The governed MCP server
The tools an agent can call, the three permission layers that gate them, and a worked example with the warehouse grants.
Read the reference →The 48-hour test protocol
A vendor-neutral acceptance test you can run against us, against them, or against both.
Run the protocol →Claims about Snowflake on this page are taken from Snowflake's own public documentation, checked on 20 September 2026. Specifically: the CORTEX_USER and PUBLIC default and the CORTEX_ANALYST_USER alternative come from Snowflake's Cortex Analyst and database roles documentation, the model preference order and the statement that generated SQL adheres to established access controls come from the Cortex Analyst page, and the semantic views description comes from the same source. Model availability and the preference order change, so treat the model list as correct on the date above rather than indefinitely. No Snowflake pricing is quoted here. If you find a row that is out of date, it is a mistake rather than a position: write to brian@askotter.ai and it will be corrected or removed.
Run the test rather than take the page for it.
Deploying is free, so an evaluation costs you a credential and two days.
Read-only to start · your LLM keys · SOC 2 Type II underway · or book a call directly
Find out what your data has been hiding.
Tell us about your operation. We’ll show you the problems Ward catches, and the ones your current tools miss.