Is your data safe with Claude Dashboards?
What Claude sees, where the data goes, and how a semantic layer on ClickHouse limits it. As of October 2026. With Claude Dashboards (beta since October 8, 2026), Claude builds a live dashboard for you: you ask a question, it writes the page, and the page keeps querying your data every time someone

What Claude sees, where the data goes, and how a semantic layer on ClickHouse limits it. As of October 2026.
With Claude Dashboards (beta since October 8, 2026), Claude builds a live dashboard for you: you ask a question, it writes the page, and the page keeps querying your data every time someone opens it. I built several of these on an eMondrian semantic layer over 182 million US flight records in ClickHouse, and the first question everyone asked me was the obvious one: where does the data go?
Short answer: Claude sees your model (table names, measures, formulas), not your rows. Every time the dashboard opens, its queries go through Anthropic's cloud to your semantic layer server, and the aggregated results come back the same way. Whether that's acceptable depends on two things you control: which Claude plan you're on, and where your server sits.
Disclosure: I'm the author of eMondrian, the open-source semantic layer used in this example.
There are two different flows, and it helps to keep them apart.
To write a dashboard, Claude needs to know what it can ask for. It calls two tools on the eMondrian MCP server:
OnTime: OnTime (attributes) FoodMart: Sales, Warehouse, Store, HR, Sales Ragged, Warehouse and Sales Enter fullscreen mode Exit fullscreen mode get_schema returns the model definition: dimensions (Time, Airline, Day of Week, Distance Group), measures, and their formulas: <CalculatedMember name= "On-Time Rate" dimension= "Measures" > <Formula> 1 - ([Measures].[Late Arrivals] + [Measures].[Cancelled] + [Measures].[Diverted]) / [Measures].[Flights] </Formula> </CalculatedMember> Enter fullscreen mode Exit fullscreen mode That's metadata. No data rows are involved. One thing to know, though: the schema includes the SQL behind the cube, so table and column names in your database become visible to Claude.
Claude then writes MDX queries into the page, for example "On-Time Rate and Cancellation Rate for each month of 2025, for Delta". The page stores queries, not numbers.
When someone opens the page, it runs its stored queries through that person's connector. The request goes from the browser to Anthropic's connector service, then to your eMondrian server. eMondrian turns MDX into SQL, ClickHouse does the aggregation, and the result goes back the same way.
What comes back is small. The monthly chart for one year is 12 rows × 3 measures, not the 7 million flights behind them. Raw rows never leave ClickHouse, because the semantic layer only answers questions about the measures it defines.
A Claude Dashboard built on the eMondrian demo with the prompt from "Try it" below. Every chart is a stored MDX query; the month chart comes back as 12 rows.
Refreshing the dashboard runs the stored queries again. It doesn't ask Claude to write anything new.
The question isn't whether Claude sees your rows. It's where your numbers travel:
Everything below comes from Anthropic's own documentation as of October 2026. Terms change, so check the linked pages before you rely on them.
Connections come from Anthropic's cloud, not from your laptop. The Help Center states that Claude connects to a remote MCP server "from Anthropic's cloud infrastructure, rather than from your local device", and that the server "must be reachable over the public internet from Anthropic's IP ranges". This applies in the browser and in Claude Desktop alike.
You choose how people sign in to your connector. There are three modes: sign in up front, sign in when the server asks, or no sign-in. The documentation is explicit about the last one: with no sign-in, "anyone with access to the server URL can use the connector". Connector credentials are stored encrypted.
Custom connectors are unverified. Anthropic warns that custom connectors connect Claude to services "that have not been verified by Anthropic" and that a malicious server could try prompt injection. That's a reason to run your own server rather than someone else's.
No training on your content on commercial plans. Anthropic's Commercial Terms, which cover the API, Claude Team and Claude Enterprise, say: "Anthropic may not train models on Customer Content from Services." Personal plans (Free, Pro, Max) are under the consumer terms instead, where it depends on your privacy settings. If your company's data is involved, use a Team or Enterprise plan.
Retention is set by your agreement, not by the terms page. The Commercial Terms bring in a Data Processing Addendum and treat your content as your confidential information. Retention periods aren't stated on the terms page itself. If retention matters to you, ask Anthropic for the numbers for your plan in writing.
Regulated data. Anthropic's admin guide says organizations set up for HIPAA (the US health privacy law) can turn Dashboards on, but Dashboards aren't covered by the BAA (Business Associate Agreement, the contract under which Anthropic may handle patient data). So keep PHI (protected health information, i.e. patient data) out of them.
Private networks: MCP tunnels (Claude Enterprise, research preview). If your server must not be reachable from the internet, Claude Enterprise can reach it through an MCP tunnel. You run a small stack inside your network, and it opens an outbound-only connection, so you need no inbound firewall rules. Cloudflare carries the traffic encrypted and can't read it. Anthropic's backend does terminate it, so Anthropic still processes the content. The tunnel requires MCP servers that use Streamable HTTP and require OAuth.
Dashboards themselves. Claude Dashboards is in beta on Pro, Max, Team and Enterprise plans; on Enterprise it stays off until an owner turns it on. While Claude builds a dashboard, claude.ai asks you to approve each tool call, and the approval shows the exact MDX query it's about to run.
The finished dashboard stores its queries and runs them through each viewer's own connector whenever it's opened, refreshed or filtered, so a viewer needs access to that connector. Dashboards start private to you. Sharing outside your organization is an admin setting, and a dashboard that uses connected apps can't be shared with "Anyone with the link".
Admins can turn connectors in artifacts on or off, but they can't restrict which connectors a dashboard calls. So the real boundary is the connector itself: what your server lets it see.
This is where the real decisions are, and where a semantic layer earns its place.
What the agent can see at all. Claude Dashboards can also connect straight to a warehouse, ClickHouse included. Then Claude writes SQL against your tables, and every table the connection can read is in play. Through a semantic layer it's different: Claude doesn't get a SQL console to your warehouse. It gets the cubes, measures and dimensions you defined, and it writes MDX against them. A table that isn't in a cube isn't reachable through MCP, and an agent can't invent its own "revenue" formula when one is already defined. One caveat: if the server allows the agent to save schemas, the agent could define a new cube over another table. Read-only mode closes that door.
What it can do. On the public demo, the MCP server runs read-only. The tools that change schemas or register catalogs are switched off.
Who can see which numbers. Mondrian roles can restrict access to cubes, dimension members and measures. To tie those roles to the person who signed in, the MCP server needs OAuth.
Where your server sits. This is the choice that matters most:
You can see all of this on the public demo. The data is public, and the server is read-only.
A step-by-step tutorial with screenshots is coming. Follow to get it.
Sources (official): Get started with Claude Dashboards · Artifacts admin guide · Custom connectors using remote MCP · Add a connector that isn't in the directory · MCP tunnels · Anthropic Commercial Terms
Questions about your own setup? Leave a comment, or write to contact@bisolutions.dev.