The first time Claude writes against live BigQuery and Snowflake warehouses, it's also the first time your schema becomes prompt context.
Here’s the request that just got obsolete: a Jira ticket to the BI team asking for “weekly active users by plan tier, last 90 days, with a drill-down.” Two-week turnaround, one dashboard nobody opens after the first week.
Anthropic’s new Dashboards beta, shipped today alongside a text-to-video feature called Motion, collapses that loop into a sentence. You connect Claude to BigQuery or Snowflake, describe what you want in plain English, and it writes the queries and returns a live, interactive dashboard—not a screenshot, not a CSV, an actual rendered thing that re-runs against your warehouse. Docs, Slides, and Design also dropped onto the free tier the same day, which is the kind of “capability expansion across plans” line that reads like marketing until you notice it means a lot more people now have an LLM that can touch production data.
The load-bearing claim in all the coverage is that this is the first time Claude writes against live warehouses and hands back interactive output instead of text. That’s true, and it’s genuinely the interesting part. BI tools have existed since the Clinton administration. Natural-language generation against a live schema is the new thing. So let’s pressure-test the claim that actually matters to anyone running this: that it’s safe to point at your warehouse.
What actually connects today?
Two sources at launch: Google BigQuery and Snowflake. Both are beta, both are behind an auth flow where you authorise Claude to reach the warehouse. That connection is the whole ballgame. Everything downstream, every clever dashboard, depends on what that identity is allowed to do.
A sourcing note, because it matters here: the announcement confirms the two connectors and the beta status. The specific auth mechanics below—service accounts and scoped IAM roles for BigQuery, a dedicated role and warehouse for Snowflake—are not spelled out in the launch coverage. They’re the recommended patterns based on how each platform’s access model actually works, and on how any sane connector would have to authenticate. Treat them as what I’d do on day one, not as a transcription of Anthropic’s setup docs.
The flow, stripped down, is this: Claude reads your schema, reasons about which tables answer your question, generates SQL, executes it, and renders the result into chart components. The schema read is the step people skip past. To write a sensible query, the model needs to see your table and column names, types, and often a sample of rows to understand distributions and enum values. That metadata—and potentially those sample rows—goes into the prompt context. Hold that thought.
What rights does Claude need on your warehouse?
The honest answer: far less than the default integration will tempt you to grant. The path of least resistance is to connect with whatever credential you already have in your hand, which for a lot of engineers is something with roles/bigquery.dataEditor or worse. Don’t. Claude needs to read metadata and run SELECT queries. That’s it. No write, no DDL, no access to tables outside the datasets you care about.
For BigQuery, that’s a purpose-built service account scoped to specific datasets:
The Snowflake equivalent is a role with USAGE on a dedicated warehouse and SELECT on specific schemas, and nothing else. If you’re feeling disciplined, give that role a resource monitor so a hallucinated CROSS JOIN on a billion-row events table doesn’t quietly burn a week of credits at 2am. It will happen. The model does not pay your Snowflake bill.
What happens to your schema and your rows?
This is the question the launch posts wave past, so here’s the plain version. When Claude builds a dashboard, your schema goes into the model context. Depending on the question and the connector’s behaviour, so do sampled rows and the aggregated query results—because the model has to see output to render charts and to self-correct when a query fails. That means your column names (often the most sensitive metadata you own—churn_risk_score, pending_acquisition_flag) and some of your actual data transit Anthropic’s inference path.
Anthropic’s published commercial terms say it doesn’t train on your inputs or outputs by default for API and commercial products—that part is on the record. What the launch coverage does not detail is how a beta warehouse connector logs query metadata and results, for how long, or in which region. So don’t infer it. Confirm it, in writing, against your own contract and data-processing terms before you connect—not after. If you have data-residency obligations, a model endpoint in the wrong region reached via a dashboard prompt is still a data transfer, and “but it was a chart” is not a defence your auditor accepts. Treat the warehouse connection as an egress path, because that’s what it is.
The worked example
Say you’ve got this in BigQuery:
You connect the scoped service account, then type something like: “Show MRR by plan tier over the last 12 months, plus net new vs. churned MRR per month, and flag any month where churn exceeded 5% of starting MRR.”
What comes back is a rendered dashboard: a stacked area chart for MRR by tier, a waterfall for net movement, and a conditional callout on the bad months—each tile backed by SQL Claude wrote and will re-run live. You give it the connection and the instruction, not the SQL. The useful habit: ask it to show you the generated queries. Read them. The chart is only as true as the GROUP BY, and a confident, wrong dashboard is more dangerous than no dashboard. I’ve watched one define “active” three different ways across three tiles because the prompt was vague. The fix was a clearer prompt, not a smarter model.
And Motion?
Motion is the lighter story. Feed it text plus optional images and it produces a short animated explainer—it appears designed for short-form content rather than film, though the launch coverage doesn’t nail down exact format or length limits, so I won’t pretend to either. It’s a rendering pipeline over your content, useful for onboarding snippets and release notes, not a reason to cancel your motion designer. The security surface is smaller because it’s working off content you hand it, not a live credential into your data. Judge it on output quality once you’ve tried it; I wouldn’t build a workflow on its exact specs while it’s in beta.
Can enterprise turn this off?
Enterprise deployments typically offer admin controls that gate which features and connectors are available—that’s the pattern across Anthropic’s business tiers, and a text-to-dashboard tool wired into warehouses is precisely the kind of capability a security team wants to allow-list by connector and by dataset rather than leave on by default. If you run a regulated shop, confirm those controls exist and are set before you let either feature light up, rather than assuming the default is conservative. The free-tier expansion of Docs, Slides, and Design makes that governance conversation more urgent, not less—more surface, more users, same need to decide what’s connectable.
So the headline claim holds, with a sharper edge than the headline admits. The BI ticket really is dead for a large class of ad-hoc questions, and that’s a real productivity shift, not a demo. But the dashboard didn’t replace your query-writing. It replaced your access-review. The thing you’re actually deploying is a credential, and the only question that decides whether this is a great tool or next year’s incident is how tightly you scoped it. Read-only, dataset-level, logged, region-pinned. Do that and the sentence-to-dashboard trick is a gift. Skip it and you’ve handed a very fast, occasionally confident intern the keys to the data warehouse.