Genie, Snowflake CoWork and Spotter: Row Security Holds, Sample Values Leak

All three text to SQL tools in this review enforce your row-level security on the query they run. Databricks says row filters apply per user, Snowflake says row access policies propagate, and ThoughtSpot applies its rules at the table. The gap sits one layer up. Each product builds sample values to help the model guess, and Snowflake's documentation states those values, stored as metadata, "are not masked".

What an AI data analyst actually is in 2026

Strip the branding and all three products do the same job. A user types a question, and a model maps it onto a curated description of your tables. It generates a query, runs it and explains the result. Vendors call this an AI analyst. Search engines call it text to SQL.

The names moved this year. Snowflake renamed Snowflake Intelligence to Snowflake CoWork in a June 2026 announcement, and Databricks renamed Genie spaces to Genie Agents the same month. CoWork routes questions through Cortex Agents to Cortex Analyst over a semantic view. A Genie Agent generates SQL over up to 50 Unity Catalog objects.

Spotter, in its first version, translates a question into ThoughtSpot search tokens against a governed model before any SQL exists. Two of these products let a model write SQL. One makes the model pick from a vocabulary that compiles to SQL deterministically. I think that is the most defensible design of the three, and ThoughtSpot appears to be loosening it in Spotter 3.

This piece is written for the person who must get one of these tools through a data governance review, and keep it there.

Whose identity runs the query in each text to SQL tool

When a regional manager types a question, whose permissions decide what comes back? The three products answer differently, and only one separates compute from data cleanly.

Databricks Genie splits compute from data

Genie embeds the author's compute credentials in the agent, and Databricks documents that they "grant access to the warehouse only". Data access is a separate check, made against the end user's own Unity Catalog permissions. The author pays for compute while the reader's own grants still govern rows.

The exception is the dashboard path. Published Databricks dashboards default to shared data permissions, where viewers query with the publisher's access. Genie embedded in a dashboard inherits that dashboard's permissions. If your rollout puts Genie inside dashboards, check that setting first.

Snowflake CoWork runs as the caller's role

Cortex Agents take permissions from the context of the request, and in CoWork the role selected in the interface authorises the call. Plain SQL against a semantic view uses owner's rights. Snowflake states that Cortex Agents need SELECT "on both the semantic view and its underlying tables". The agent path is stricter than the SQL path, and I expect that pushes admins to grant base-table SELECT more widely than they intended.

ThoughtSpot depends on how you connect

ThoughtSpot sits outside your warehouse, so the connection decides the identity. With per-user OAuth to Snowflake, each user authorises ThoughtSpot to query under their own account, and the token is stored for 90 days. With a shared credential, the warehouse sees one identity and ThoughtSpot's own row rules do the filtering. ThoughtSpot also documents that administrative users "can always see all rows", because its row-level security does not apply to them.

That identity question is the same one raised in the analysis of agent credentials against user impersonation. Here it arrives with a chat box attached.

Row-level security holds at query time in all three products

The good news is consistent. Each vendor documents that its native row and column controls survive the trip through the AI layer. None asks you to rebuild policies inside the assistant.

Databricks states that Unity Catalog row filters and column masks "are enforced per user automatically" inside Genie. Snowflake states that row access and masking policies on underlying tables "propagate to semantic views and are enforced". ThoughtSpot states that its row-level security "applies at the table level" and extends to every model built on it.

One cost hides in row two. Snowflake documents that row access policies require Enterprise Edition or higher, so an account on Standard cannot use the control this comparison depends on.

The leak is in the sample values, not the generated SQL

Every text to SQL tool has the same problem to solve. A user types "sales in Pune last quarter" and the model must know that Pune is a value in a column called branch_city. All three products fix this by showing the model real values from your data. Whose access those values were drawn with is the part nobody demos.

The answer a user sees is filtered correctly. The vocabulary the model was handed to produce it may not be. That is the finding I would put in front of a governance committee.

Genie: representative values use the author's access

Databricks is the most explicit. Its tuning guide states that representative values for prompt matching "are generated using the author's data permissions", and they become shared context for every user. If the author can see every region, the model's context can name every region.

Databricks has shipped a real mitigation. Tables with row filters are excluded from prompt matching entirely, and masked columns are excluded individually. The remaining gap is narrow and specific: for views over filtered tables, and for dynamic views, the author has to switch entity matching off by hand.

Snowflake: sample values are stored, unmasked

Snowflake's semantic view guidance states that sample values, "which are stored as metadata, are not masked". Masking policies protect the column when it is queried. They do not reach back into the examples an author pasted into the semantic view definition.

I would not call this a bug. It is a documented design boundary. But every semantic view now needs a review that asks one question of each sample value: could a masked user read this string? That review belongs in the sequence for making data AI-ready, before launch rather than after.

Spotter: suggestions indexed as the connection creator

ThoughtSpot carries the clearest warning of the three. Under passthrough security, it "builds the search index on the user who created the connection", and other users may see suggestions for values they should not see. They cannot query those values. They can see that they exist.

ThoughtSpot's fix is Secure Suggestions, early access since its February 2026 release, plus a recommendation to turn off indexing on sensitive columns. If you buy Spotter, treat both as day-one configuration, not later hardening.

Semantic layers: three names for the same bet on curation

Every vendor now agrees that a text to SQL tool pointed at raw tables fails. Accuracy comes from a curated layer that says what revenue means, which join is correct, and which questions have a verified answer. They differ on where that layer lives.

Snowflake recommends semantic views, defined in SQL, for new Cortex Analyst work, with YAML model files kept as a legacy option. A verified query repository pairs questions with approved SQL. Because semantic views are schema objects, they inherit grants and the policies on their base tables.

Genie keeps curation inside each agent. Its knowledge store does not change Unity Catalog metadata, and trusted assets are example queries and SQL functions an author has verified. Each agent caps at 100 instructions. That per-agent scoping is my main concern with Genie at scale: ten agents built by ten analysts can carry ten definitions of churn. Unity Catalog metric views reduce the risk, but only if your team uses them.

ThoughtSpot's model predates the language model, and Spotter adds coaching, where an analyst saves a corrected answer back into memory. The common thread matches the argument that context engineering replaced prompt engineering. The model is rented. The curated context is the asset, and in all three products it is locked to one vendor's object model.

Published accuracy claims for AI analytics tools share no benchmark

Each vendor publishes an accuracy figure, and each is real. They are also measured on different questions, with different scoring, against different comparators. Putting them in one table, as several roundups do, tells you nothing about your schema.

What each accuracy number actually measures

Snowflake's 2024 claim of 90% or more rests on 150 internal questions, scored on lenient precision and recall of columns rather than strict execution match. Its comparison is a single-prompt GPT-4o baseline that scored 51%. The figure predates semantic views and the CoWork rename by more than a year.

Databricks reports that Genie answered 84.5% correctly on the first attempt, against 52.4% for the strongest unnamed coding agent. The suite is 28 questions, so one question moves the score by about 3.6 points. I treat it as a direction, not a measurement.

ThoughtSpot's 82.8% is the most transparent. It uses 1,533 public BIRD questions, reports a margin of about 2 points, and admits a rubric judge stood in for the official scorer. It also reports that 52.8% of the BIRD examples it reviewed had annotation problems, which cuts against every BIRD score, its own included.

Build your own benchmark before the trial

Genie ships the best tool for this. Each agent holds up to 500 benchmark questions, and Genie scores its result against a reference SQL answer, ignoring row order. That is the discipline in the guide to building an LLM evaluation suite, applied to analytics. Whichever vendor you pick, write 50 questions from your own ticket queue, with reference SQL, before the trial starts.

Billing for text to SQL tools: tokens, credits and capped queries

Pricing is where the products diverge most. Two meter consumption. One sells seats with a usage ceiling.

Snowflake meters tokens at two credit prices

Snowflake bills Cortex Agents in AI Credits per million tokens, at a rate set by the orchestration model. It prices an AI Credit at $2.00 with global routing and $2.20 with regional routing, a 10% premium for keeping inference in region. The generated SQL then runs on a warehouse at platform rates. You pay twice per question, in two credit types.

Databricks is free now, and metered later

Databricks moved Genie products to pay as you go with a per-user free allowance, which its June 2026 post put at up to $10 per user per month. Service principals get no free allowance, which matters once you call Genie from an application. Databricks also states that Genie Agents use by people is free through 31 January 2027. Budget the renewal on the metered price, not the pilot invoice, for the reasons in the breakdown of credit and token billing confusion.

ThoughtSpot sells seats with a question cap

ThoughtSpot's pricing page lists a $50 per user per month plan with Spotter capped at 25 queries per user per month, a usage option at $0.10 per credit, and custom Enterprise pricing. It states that ThoughtSpot "does not meter or charge for LLM tokens". That is the most predictable bill of the three. For a heavy analyst, 25 questions is roughly one per working day.

Where this comparison is weakest

Three limits, and the first is serious.

Every source here is the vendor describing itself

All governance claims above come from vendor documentation. I have preferred pages where a vendor documents its own inconvenient default, because nobody overstates their own exposure. No independent test of metadata leakage across these three products appears to be published. This is a reading of manuals, not a penetration test. The ThoughtSpot pricing page also changes with a toggle, so the pairing of the $50 price with the 25-query cap is my reading. Confirm it on your quote.

The leak is narrow, and often harmless

A helper value is a string, not a result set. Seeing that a region called North exists is not seeing North's revenue. For many schemas, the values that reach the model are product names and status codes every employee already knows.

It matters in specific cases: customer names in a sales table, employee names in an HR mart, deal codes in a pipeline view. If your sensitive dimensions are already masked, the exposure is close to zero, and price and accuracy deserve more weight than this piece gives them.

Warehouse lock-in may decide it before governance does

If your data lives in Snowflake, CoWork inherits policies you already maintain, and Genie is not an option without moving data. The reverse holds on Databricks. ThoughtSpot alone works across warehouses, and that portability can outweigh every row in the tables above. The wider pattern is in the analysis of AI switching costs and lock-in.

Frequently asked questions

Where to start

Pick your three most sensitive dimensions before you pick a vendor. Customer name, employee name and deal code are typical. For each one, find out whether it appears in any sample value, suggestion index or knowledge store your candidate product will build. That inventory takes an afternoon, and it turns a vague worry into a short list of settings.

Then log in as a row-filtered test user during the trial. Type the first letter of a value that user should never see, and screenshot what the assistant suggests. If nothing appears, you have a product your auditor can sign off. If something does, you have found the conversation that belongs before the contract, which is the lesson from the comparison of Glean and Copilot permission handling.

Related reading