How to Connect ChatGPT to a Data Warehouse

The production-safe way to connect ChatGPT to a data warehouse is to put governed analytics between the agent and the database. Connect Snowflake, BigQuery, Redshift, or Databricks to Cube, then add Cube's hosted MCP endpoint as a personal plugin in ChatGPT Work. ChatGPT asks for governed business data; Cube applies certified metric definitions and the authenticated user's permissions before the warehouse runs the query.

The resulting path is ChatGPT Work → Cube MCP → Cube's governed semantic model → your data warehouse. ChatGPT never needs a warehouse password, and the warehouse remains the storage and compute layer. Cube is the agentic analytics platform that turns the user's question into a governed, permission-aware request.

What you are actually connecting

"Connect ChatGPT to the warehouse" sounds like one integration. In production, four components have different jobs.

This separation matters because a correct SQL query can still answer the wrong business question. If ChatGPT sees only tables, it has to infer which revenue column is certified, which join avoids a fan-out, and which tenant filter belongs in the query. A semantic model gives it named, governed objects to select instead. Cube then generates the query under the user's permissions.

For the broader architecture, see what BI for agents means and the analytics MCP server guide.

Step 1 — Connect the warehouse to Cube

Start in Cube, not in ChatGPT. Connect the warehouse, then define the business context the agent is allowed to use:

1. Connect Snowflake, BigQuery, Redshift, Databricks, or your supported data source to a Cube deployment.
2. Model the measures, dimensions, joins, entities, time behavior, and descriptions behind the first questions you want ChatGPT to answer.
3. Add access rules for roles, rows, and tenants. Keep those controls in Cube so they are compiled into the query instead of remembered by a prompt.
4. Validate each metric against a known warehouse query or an existing Cube workbook before exposing it to an agent.

Cube does not move or replace the warehouse. The warehouse keeps the data and compute; Cube provides the governed business context that ChatGPT needs to ask for the right data.

If the semantic model is not ready, stop here. A plugin can make an under-modeled warehouse easier to reach, but it cannot make ambiguous business definitions trustworthy.

Step 2 — Configure MCP access in Cube

An administrator controls which Cube deployments MCP clients can reach.

1. Open Admin → MCP Server in Cube.
2. Confirm that the page shows an MCP endpoint. Cube's universal hosted endpoint is https://cubecloud.dev/mcp.
3. Choose the default deployment for MCP sessions.
4. Turn on Limit available deployments if ChatGPT should reach only a subset, then select the allowed deployments.
5. Confirm that the test user has at least the Viewer role and permission to reach the deployment.

The deployment allowlist is not a replacement for user permissions. Cube intersects both: a deployment must be allowed for MCP, and the authenticated user must already have access to it.

Cube hosts the server over HTTPS and uses OAuth Authorization Code with PKCE. The endpoint is the same for every hosted account; Cube uses the OAuth token to select the account and route each request. For a self-hosted console domain, use https://<your-console-domain>/mcp.

Step 3 — Add Cube as a personal plugin in ChatGPT

OpenAI's current setup uses a remote MCP server as a ChatGPT plugin:

1. Open ChatGPT and go to Settings → Security and login.
2. Turn on Developer mode.
3. Open the ChatGPT Plugins directory, select the plus button, and enter https://cubecloud.dev/mcp as the MCP server URL.
4. Review the discovered connection details and create the plugin. Cube publishes the OAuth metadata the client needs, so there is no warehouse password or API key to paste into ChatGPT.

This creates a personal plugin first—a useful boundary for a pilot. It lets one builder verify the tool list, authentication flow, permissions, and answers before a broader workspace rollout.

The exact ChatGPT interface changes over time. OpenAI's plugin quickstart is the source of truth for the current developer-mode and personal-plugin steps.

Step 4 — Install, invoke, and authenticate

Creating the plugin does not make it active in a conversation. Install and invoke it:

1. Open your personal plugins.
2. Open the Cube plugin and select the plus button to install it.
3. Return to the ChatGPT homepage and switch from Chat to Work.
4. Start a Work chat, type @, and select the Cube plugin.
5. Ask a data question. When ChatGPT calls an authenticated tool, complete the Cube OAuth flow and choose the correct Cube account if prompted.

OAuth is the user boundary. ChatGPT receives a token for the signed-in Cube user rather than sharing one warehouse service account across the whole workspace. Cube runs every MCP tool as that user and applies the same role, deployment, and row-level permissions used by the rest of the platform.

OpenAI's MCP authentication guide documents the authorization-code and PKCE flow used for authenticated remote MCP servers. Cube's MCP server documentation documents the endpoint, admin controls, tool list, and Cube-side permissions.

Step 5 — Run the grounded-answer test

Do not call the integration finished when OAuth succeeds. A green connection proves only that ChatGPT can call a tool. Test whether it can return the right answer under the right permissions.

Use this sequence:

1. Ask a question with a known result, such as revenue by region for the last completed quarter.
2. Confirm that ChatGPT selected the certified measure and valid dimensions rather than guessing names.
3. Inspect the filters, time range, and query returned with the answer.
4. Ask the same question as a user with a different role and confirm the row set changes as expected.
5. Ask for a metric, tenant, or deployment the user cannot access and confirm Cube rejects the request below the model.
6. Repeat a follow-up slice and confirm the metric definition stays fixed.

That is the practical standard for governed AI data access: right number, right permissions, and a traceable definition. Fluency is not part of the security test.

What ChatGPT can do through Cube

Cube's MCP server exposes governed analytics tools according to the user's role. A read-only pilot can start with three useful workflows:

• Ask a business question. Cube's chat tool plans the analysis and returns an answer with the generated SQL; larger result sets can be paginated.
• Discover and query the model. ChatGPT can search available views, measures, and dimensions, then run a Cube SQL query without inventing member names.
• Inspect existing analytics content. Depending on the role, the plugin can read reports, workbooks, dashboards, deployments, and other governed context.

Cube also exposes tools for creating analytics content, editing semantic-model files on a personal development branch, and inspecting or building pre-aggregations. Those capabilities should be added after question answering works. Cube annotates destructive tools so compatible clients can require explicit approval, model edits never write directly to production, and a human must commit any model change from Cube.

The point is not to give ChatGPT every possible action on day one. Give each user the smallest tool surface that completes the job, then expand it when the approval and review path is clear.

Security checklist

• No warehouse credentials in ChatGPT. ChatGPT authenticates to Cube with OAuth; Cube owns the warehouse connection.
• A small MCP deployment allowlist. Only the deployments needed for the pilot are available.
• Least-privilege Cube roles. Start question-answering users as Viewers; grant content or model permissions only when the workflow requires them.
• Row and tenant rules tested with two users. A policy that has never been denied in a test is still an assumption.
• Certified metrics verified. Known answers, time grains, filters, and joins match the data team's reference results.
• Write actions reviewed separately. Dashboard publication, destructive content changes, and data-model edits have explicit confirmation and human review.
• Queries and outputs are inspectable. Review the metric, filters, SQL, result, and acting user when an answer looks wrong.

Common connection problems

The plugin does not appear in ChatGPT Work

Confirm that Developer mode is enabled, the personal plugin was created successfully, and it was installed from the personal Plugins directory. In a new Work chat, type @ and select the plugin explicitly rather than assuming ChatGPT will choose it automatically.

OAuth does not start

Invoke a Cube tool from the plugin. ChatGPT launches linking when the remote MCP server reports that authentication is required. If the connection details were edited manually, recreate the plugin from the MCP URL so ChatGPT can discover Cube's OAuth metadata again.

ChatGPT connects but sees no deployment

Check Admin → MCP Server in Cube. At least one deployment must be allowed, and the authenticated user must have role-based access to it. The deployment limit and the user's permissions both apply.

ChatGPT returns a plausible but wrong metric

Treat this as a modeling or context problem, not a reason to grant broader database access. Verify that the metric has one certified definition, the valid dimensions and join paths are described, and the user can discover the intended model objects. Then rerun the grounded-answer test.

Methodology

We verified the ChatGPT setup against OpenAI's plugin quickstart and MCP authentication documentation as available on August 29, 2026. We verified the Cube endpoint, OAuth flow, deployment controls, permission behavior, and tool surface against Cube's MCP server documentation on the same date. The guide recommends a governed analytics boundary because connecting successfully is not the production test; correct metrics, inherited permissions, and traceable answers are.