Letting an LLM query Snowflake or Databricks safely means never giving it a credential that can run arbitrary SQL against production tables; instead, create a dedicated read-only service role scoped to specific views rather than raw tables, so column masking, row-level security policies and sensitive fields defined in the warehouse itself are enforced before any data reaches the model. On top of that, expose a small set of parameterized query tools, for example one for revenue by region or one for a customer's order history, instead of a single generic run-SQL tool, since narrow tools are far easier to review and far harder to misuse through a crafted prompt. Snowflake Cortex and Databricks Genie offer built-in natural-language query features that follow a similar constrained pattern and are worth evaluating before building a custom layer. Query timeouts, row limits and cost quotas on the warehouse role prevent an overly broad or looping agent request from triggering an expensive full-table scan. Nanobase AI designs these data warehouse integrations around least-privilege views and tool scoping rather than direct database access for the model.
Why text-to-SQL is riskier than it looks
A tool that lets a model generate arbitrary SQL against a live warehouse is attractive because it seems maximally flexible, but it carries a specific and underappreciated risk: a crafted or simply confused prompt can produce a query that scans an entire fact table, joins across tables the user should not correlate, or returns far more rows than the question needed. This is not the same as classic SQL injection since the model is not being tricked by attacker-controlled string concatenation, but the effect is similar, an unintended query executing with the credentials the tool was given. The safer default is a small set of parameterized, purpose-built tools rather than one generic run-SQL capability, trading some flexibility for a query surface that is actually reviewable.
Generic text-to-SQL vs curated tools
| Approach | Flexibility | Reviewability | Typical risk |
|---|---|---|---|
| Generic run-SQL tool | High, answers almost any question | Low, every query is unique and hard to pre-audit | Full-table scans, unintended joins, cost spikes |
| Curated parameterized tools | Lower, limited to defined questions | High, each tool's query is fixed and reviewed once | Contained to what the tool was designed to do |
| Semantic layer query | Medium, flexible within defined metrics | High, queries route through pre-approved metric definitions | Low, since metrics enforce consistent filters |
A semantic or metrics layer, the kind of approach used by tools like Databricks Genie or Snowflake Cortex Analyst, sits between these two extremes: the model expresses intent in natural language, but the actual SQL is generated against a pre-defined set of metrics and dimensions rather than an open schema, keeping the flexibility of natural language while bounding the query shape.
Enforcing security below the tool layer
Whichever approach is chosen, security should not depend solely on the tool's own logic; the warehouse itself should enforce it. Snowflake's dynamic data masking and Databricks Unity Catalog's row- and column-level access controls apply regardless of how a query reaches the warehouse, so even a flawed or overly permissive tool cannot surface a masked column or a row outside the caller's row-level policy. Layering warehouse-native masking underneath the tool layer means a mistake in the AI integration degrades to "the tool doesn't work" rather than "sensitive data leaked."
Guardrails worth setting regardless of approach
- Use a dedicated read-only service role for any AI-facing query path, never a role with write or DDL privileges.
- Scope that role to specific views rather than raw tables, so the view definition itself excludes sensitive columns.
- Set a query timeout and a maximum row limit at the role or session level, not just in application code.
- Apply a cost or credit quota specifically to this role in Snowflake or a cluster policy in Databricks, so a runaway or looping agent request cannot generate unbounded compute cost.
- Log every query text and its result row count for later review, independent of whether the query came from a curated tool or a semantic layer.
Frequently asked questions
Should we ever let an LLM write directly to the warehouse?
This is a materially different and higher-risk request than read queries, and most enterprise deployments avoid it entirely for AI-initiated writes, preferring that any data pipeline change go through existing ETL or reverse-ETL tooling rather than a model-generated write statement.
Does a semantic layer replace the need for row-level security?
No, they solve different problems. A semantic layer controls what questions can be asked and how they translate to SQL; row-level security controls which rows a given user is allowed to see regardless of how the query was generated, and both should be applied together.
How do we test whether our query tools are actually safe?
Run adversarial prompts deliberately designed to push the model toward broader queries than intended, such as asking it to "show everything" or combine unrelated tables, and confirm the tool layer and warehouse permissions reject or narrow the request rather than executing it as asked.
How Nanobase AI helps
Nanobase AI designs data warehouse integrations around least-privilege views and narrow, parameterized tools rather than direct database access for the model, layering warehouse-native masking underneath so a flawed tool cannot bypass Snowflake or Databricks' own access controls. Row-level security patterns for multi-user query access are covered further in row-level-security-llm-data-queries.
Ready to discuss your project? Contact Nanobase AI or email hello@bumu.tech.