Snowflake keeps its SQL copilot's answers inside its perimeter

The setup

Cortex Analyst is Snowflake's natural-language-to-SQL assistant, built to sit inside the data warehouse a customer already runs rather than as a separate analytics tool. Setting it up means writing a semantic model, a YAML file that maps business terms an analyst might type, such as revenue or region, onto the actual table and column names underneath, then granting the roles that will use it read access to that file and select access to the tables it references. The Cortex Analyst documentation presents this semantic-model step as what lets a business question resolve into a specific, governed query rather than a guess.

What the documents show

Snowflake's documentation states that, by default, Cortex Analyst runs on Snowflake-hosted models from Mistral and Meta, keeping data, including metadata and prompts, from leaving Snowflake's own governance boundary. The same page states Cortex Analyst does not train on customer data, and every SQL statement it generates still passes through the account's existing role-based access control, so a user cannot get an answer from a table their role could not otherwise query. Snowflake's broader AI and ML documentation frames Cortex Analyst as one feature in a wider Cortex suite built on this hosted-model design, and the company's own product page markets it the same way, as analysis happening within Snowflake's secure perimeter, a vendor's description of its own architecture, not an independently audited one.

The friction

The documentation is specific about what Cortex Analyst cannot do: it is limited to questions answerable with SQL against the semantic model provided, and does not generate broader business insight beyond that. Access to a semantic model uploaded to a stage is controlled by whoever can read that stage, so the practical security boundary is the stage and role permissions an admin sets correctly, not a property of Cortex Analyst itself. Getting from a demo to a model that reliably answers real questions requires someone to maintain that YAML mapping as tables change, ongoing engineering time the documentation does not estimate.

What changed in the work

Where the documentation is followed, an analyst or a less technical stakeholder can get a governed answer without writing SQL or waiting on a data team, and access control travels with the existing role. That is what the cited pages support. It would go beyond them to claim the assistant is equally reliable across every dataset or replaces a data team's judgment on ambiguous questions; the documentation scopes Cortex Analyst to SQL-answerable questions on a maintained semantic model, a narrower promise than a general analytics copilot.

• Who owns and updates the semantic-model YAML file as the underlying tables change?
• Does the stage holding the semantic model match the access boundary the team intends for Cortex Analyst?
• Which questions in the team's actual backlog are SQL-answerable, and which need a human analyst regardless?

Snowflake's own documentation makes a checkable claim, that the default hosted-model setup keeps a query inside the account's governance boundary, and pairs it with a specific limitation: the assistant answers only what SQL and a maintained semantic model can express, leaving that model's upkeep as the real ongoing cost.