AI Assistants
Your team already works with AI assistants. The problem is that an assistant knows nothing about your warehouse, so it guesses: it invents table names, writes SQL against columns that do not exist, and cheerfully explains a number it has no way of knowing. dbdeux closes that gap by letting an assistant connect directly to your projects, so it reads what is actually there instead of imagining it.
Connect Claude, Cursor, or any assistant that speaks the Model Context Protocol, and it can explore your models and lineage, look at how last night's run went, ask a governed metric, and even run a dbt command, all inside the permissions you grant.
Setting It Up
Open your organization and choose the MCP Server tab. It gives you the connection address, ready-made configuration for Claude and Cursor, the full list of permissions you can grant, and the assistants you have already connected.
The whole setup is one address plus one decision: does the assistant act as the organization, or as you.
Connect as Yourself
Point your assistant at the address with no credential and it discovers that dbdeux supports sign-in. A browser window opens, you sign in as usual, and a consent screen asks you to approve exactly which permissions this assistant gets. Approve, and the assistant is connected.
This is the option to use for your own laptop, and the reason is not convenience. A connection made this way acts as you: it sees the projects you can see, uses connections you are allowed to use, and is refused everything you would be refused. Nobody gets a wider view of the warehouse by asking an assistant instead of opening the app.
Connect as a Service Account
For an assistant that runs unattended, create a token under Service Accounts and grant it only the permissions that assistant needs. The token acts as the organization rather than as a person, which makes it the right fit for shared automation and the wrong fit for browsing warehouse data. It cannot run SQL at all, no matter which permissions you tick.
| Sign in as yourself | Service account token | |
|---|---|---|
| Acts as | You, with your own access | The organization |
| Best for | Your editor or desktop assistant | Unattended and shared automation |
| Approving permissions | A consent screen you accept | Chosen when you create the token |
| Read-only SQL | Available if you approve it | Never available |
| Shown in the audit log as | Your name | The token name |
| Turning it off | Revoke that assistant | Rotate or revoke the token |
What You Can Grant
Permissions are never implied. An assistant that can trigger a job cannot list your jobs unless you also granted that, and anything you did not approve does not even appear in its tool list.
Reading:
| Permission | What the assistant can do |
|---|---|
projects:read | List projects, models, and lineage |
catalog:read | Browse catalog metadata and node detail |
jobs:read | List scheduled jobs and their settings |
runs:read | Read run history, logs, and artifacts |
environments:read | List environments, never their secret values |
connections:read | List connection names and types, never their secrets |
semantic:read | Discover governed metrics, dimensions, and saved queries |
Acting:
| Permission | What the assistant can do |
|---|---|
jobs:write | Create or change a scheduled job |
jobs:run | Trigger a job that already exists |
dbt:run | Run approved dbt commands in your project |
semantic:query | Run a governed metric query and read the results |
sql:execute | Run read-only SQL as you and read the rows it returns |
Asking About Your Project
With reading permissions granted, the questions people actually ask stop being research projects:
- "What feeds
fct_orders, and what breaks if I change it?" answered from real lineage - "Did last night's job fail, and where?" answered from the run and its logs
- "What is the compiled SQL for this model in production?" answered from the compiled artifact rather than a guess at your macros
- "How healthy is this model?" answered from its tests, freshness, and recent run history
Asking for a Number
An assistant with semantic:query does not write SQL to answer "what was revenue by region last month". It asks the semantic layer, which compiles the query from the definition your team published. The number it gives back is the number your dashboard would give back, because both came from the same definition.
This is the difference between an assistant that sounds confident and one that is correct. Every one of those questions also lands in query history labelled as coming from an assistant, so a surprising answer can be traced later.
Running dbt
Grant dbt:run and the assistant can run a dbt command in your project: build a model and its children, run a test, compile. It is the same run the Run button in the editor performs, with the same environment, the same variables, and the same rules. An environment locked to a branch stays locked. A run that would not be allowed from the editor is not allowed from an assistant either.
The assistant gets back the run it started, so it can follow the status and read the log, and describe what failed rather than telling you to go and look.
Read-Only SQL
sql:execute is the one permission held to a higher standard, and it is worth understanding why.
- It is available only when you connect with your own sign-in. A service account token can never run SQL
- It runs as you, so your connection access rules apply exactly as they do in the app
- Only a single read-only query is accepted. Anything that would change data is refused before it reaches your warehouse
- Rows returned are capped and every query has a timeout
That leaves one thing that is your judgement rather than a control: the assistant can read the rows a query returns, and so can the AI provider behind it. Grant sql:execute when you are comfortable with that, and leave it off when you are not. Everything else on this page works without it.
Assistants You Have Connected
The MCP Server tab lists every assistant you have connected with your sign-in, when you authorized it, when it was last used, and what it was allowed to do. Revoke ends that assistant's access immediately. Any credential it holds stops working, and it can only come back by signing in and asking your consent again.
That list matters more than it first appears. Connecting an assistant is a normal thing for someone to do on a Tuesday afternoon and then forget, and being able to see the ones that are still connected, with a last-used date, is what turns it from a forgotten grant into something you can review.
It Is All in the Audit Log
Every action an assistant takes is attributed in the audit log: actions taken with your sign-in appear under your name, and actions taken with a service account appear under the token name. An assistant is never an anonymous actor in your history.
Availability
Assistant access is included in Business plans and above. If your plan does not include it, a connection attempt returns a clear message rather than failing obscurely, and your current plan is shown under Plan and Limits in your organization.
How It Compares
| dbdeux | dbt Cloud | Warehouse-only assistant | Copying context by hand | |
|---|---|---|---|---|
| Project structure and lineage | Read directly | Not available to assistants | Tables only, no dbt model graph | Whatever you pasted |
| Run history and logs | Read directly | Not available to assistants | Not available | Not available |
| Metric answers | From your governed definition | Not available | Assistant writes its own SQL | Assistant writes its own SQL |
| Running dbt | Approved commands, same rules as the editor | Not available | Not available | You run it and paste the output |
| Acts with your own access | Yes, when you sign in | Not applicable | Depends on the credential given | Not applicable |
| Per-permission consent | Yes, on a consent screen | Not applicable | Usually all or nothing | Not applicable |
| Attributed in an audit log | Every action | Not applicable | Warehouse-side only | No |
| Turn one assistant off | Revoke that assistant | Not applicable | Rotate a shared credential | Not applicable |
The point of the comparison is not the length of the list. It is that the alternatives make you choose between an assistant that knows nothing useful and an assistant handed broad warehouse credentials. Here you grant a narrow, named, revocable set of permissions, and get answers grounded in the definitions and runs your team already trusts.
Good Practice
- Grant the fewest permissions the assistant actually needs; you can add more later
- Prefer your own sign-in for personal assistants, and service accounts for unattended automation
- Store service account tokens in a secret manager. They are shown once at creation
- Review your connected assistants occasionally and revoke the ones you no longer use
- Revoke immediately if a credential might have leaked