--- title: "Connect dbt Labs to Claude: Manage security, users, and audits" slug: connect-dbt-labs-to-claude-manage-security-users-and-audits date: 2026-11-04 author: Sidharth Verma categories: ["AI & Agents"] excerpt: "A complete engineering guide to connecting dbt Labs to Claude via MCP. Automate SCIM user provisioning, audit log exports, and RBAC security workflows using AI agents." tldr: "Learn how to expose the dbt Labs API to Claude using a managed MCP server. This guide covers the engineering challenges of dbt's enterprise API, how to generate a secure MCP server via UI or API, tool calling examples, and real-world workflows for automating security audits and SCIM user management." canonical: https://truto.one/blog/connect-dbt-labs-to-claude-manage-security-users-and-audits/ --- # Connect dbt Labs to Claude: Manage security, users, and audits If your team needs to connect dbt Labs to Claude to automate SCIM user provisioning, enforce IP restrictions, or extract enterprise audit logs, you need a [Model Context Protocol (MCP) server](https://truto.one/what-is-mcp-and-mcp-servers-and-how-do-they-work/). This server acts as the secure translation layer between Claude's JSON-RPC tool calls and the dbt Labs REST API. You can either [build, host, and maintain this infrastructure yourself](https://truto.one/the-hands-on-guide-to-building-mcp-servers-for-ai-agents-2026/), or use a managed integration platform like Truto to dynamically generate a secure, authenticated MCP server URL. If your team uses ChatGPT, check out our guide on [connecting dbt Labs to ChatGPT](https://truto.one/connect-dbt-labs-to-chatgpt-orchestrate-jobs-and-infrastructure/) or explore our broader architectural overview on [connecting dbt Labs to AI Agents](https://truto.one/connect-dbt-labs-to-ai-agents-automate-environments-and-data-runs/). Giving a Large Language Model (LLM) read and write access to your data transformation infrastructure is a high-stakes engineering challenge. You have to handle API token lifecycles, map complex upstream JSON schemas to MCP tool definitions, and deal with dbt Labs' specific security paradigms. Every time dbt updates an endpoint or changes a schema, you have to update your server code, redeploy, and test the integration. This guide breaks down exactly how to use Truto to generate a secure, managed MCP server for dbt Labs, connect it natively to Claude, and execute complex security and audit workflows using natural language. > Want to give your AI agents secure, authenticated access to dbt Labs and 100+ other SaaS APIs? Let's talk about [managed MCP architecture](https://truto.one/auto-generated-mcp-tools-for-ai-agents-a-2026-architecture-guide/). > > [Talk to us](https://truto.one/book-a-demo/) ## The Engineering Reality of the dbt Labs API A custom MCP server is a self-hosted integration layer. While the [open MCP standard](https://truto.one/what-is-mcp-and-mcp-servers-and-how-do-they-work/) provides a predictable way for models to discover tools, the reality of implementing it against specialized enterprise APIs is painful. dbt Labs is built to manage massive data models, strictly governed environments, and enterprise identity. Its API reflects that complexity. If you decide to build a custom dbt Labs MCP server, here are the specific integration challenges you will face: **Asynchronous Enterprise Audit Logs** Enterprise security teams rely on audit logs to track who ran which job or altered which environment variable. In dbt Labs, you do not simply GET a paginated list of historical logs. The API enforces an asynchronous export pattern. An LLM cannot just request the data - it must first POST an export request, extract the resulting export ID, repeatedly poll a status endpoint until the state returns as complete, and finally call a separate download endpoint to retrieve the raw CSV. Your MCP server must expose these distinct steps with strict schema descriptions so the LLM understands the polling orchestration. **SCIM vs Standard User Management** dbt Labs provides different API surfaces for user management depending on the account's SSO configuration. Standard user endpoints (`list_all_dbt_labs_users`) return basic account membership data. However, enterprise accounts using Okta or Entra ID require interaction with the SCIM endpoints (`list_all_dbt_labs_scim_users`). An LLM has no context on which API version to use. You must build an abstraction layer or rely on precise MCP tool descriptions to ensure Claude utilizes the SCIM payload structures (e.g., `application/scim+json`) when handling enterprise identity operations. **Nested Group Permissions and Licenses** Managing access in dbt Labs is not just toggling a boolean flag. It involves a hierarchical web of accounts, projects, environments, and group permission mappings. To assign a user to a specific developer seat, the LLM must first fetch the target user, fetch the available license maps, fetch the specific group IDs, and then construct a nested JSON payload mapping the user to the correct group permission set. If the schema is not strictly typed in the MCP tool definition, the LLM will hallucinate the permission payload structure and return 400 Bad Request errors. **Strict Rate Limits and Header Normalization** dbt Labs enforces rate limits across its API endpoints. When an LLM executes a loop - such as auditing 50 different project connections - it will likely hit a 429 Too Many Requests error. Truto does not retry, throttle, or apply backoff on rate limit errors. When dbt Labs returns a 429, Truto passes that error directly to the caller. Truto normalizes the upstream rate limit info into standardized headers (`ratelimit-limit`, `ratelimit-remaining`, `ratelimit-reset`) per the IETF spec. The caller (the LLM orchestration layer) is strictly responsible for interpreting these headers and executing retry/backoff logic. ## Creating the dbt Labs MCP Server Truto handles the complexity of authentication, schema mapping, and endpoint discovery dynamically. Rather than writing tool definitions by hand, Truto reads the dbt Labs OpenAPI documentation and derives the tools automatically. You can generate an MCP server for dbt Labs in two ways: via the Truto UI or programmatically via the API. ### Method 1: Via the Truto UI For administrators setting up Claude Desktop for internal use, the UI provides a fast path to generating a secure token URL. 1. Log into your Truto dashboard and navigate to your connected dbt Labs **Integrated Account** page. 2. Click the **MCP Servers** tab. 3. Click **Create MCP Server**. 4. Select your desired configuration. You can name the server, filter the available methods (e.g., select only `read` methods to prevent Claude from altering infrastructure), and apply tag filters. 5. Click **Create** and copy the generated MCP server URL. This URL contains the cryptographic token required for authentication. ### Method 2: Via the Truto API For platform engineers building multi-tenant AI agents, you can generate MCP servers programmatically. This allows you to spin up tightly scoped, short-lived MCP servers on behalf of your users. Make a POST request to `/integrated-account/:id/mcp` with your desired configuration: ```bash curl -X POST https://api.truto.one/integrated-account//mcp \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "name": "dbt Labs Security Audit Server", "config": { "methods": ["read", "list"], "tags": ["security", "users", "audit"] }, "expires_at": "2026-12-31T23:59:59Z" }' ``` The API responds with a database record containing the secure, ready-to-use MCP URL: ```json { "id": "mcp-7a8b9c0d-1234-5678", "name": "dbt Labs Security Audit Server", "config": { "methods": ["read", "list"], "tags": ["security", "users", "audit"] }, "expires_at": "2026-12-31T23:59:59Z", "url": "https://api.truto.one/mcp/a1b2c3d4e5f6g7h8..." } ``` ## Connecting the MCP Server to Claude Once you have your Truto MCP URL, connecting it to Claude is a straightforward process. Because Truto's MCP servers are fully self-contained, the URL inherently knows which dbt Labs account to target and which tools to expose. ### Method A: Via the Claude UI If you are using the Claude web application or enterprise workspace: 1. In Claude, navigate to **Settings** -> **Integrations**. 2. Click **Add MCP Server** (or **Add custom connector**). 3. Provide a name (e.g., "dbt Labs Security Tools"). 4. Paste the URL generated by Truto. 5. Click **Add**. Claude will instantly connect to the endpoint, perform the JSON-RPC initialization handshake, and discover the available dbt Labs tools. *(Note: If you are using ChatGPT, the flow is similar: Settings -> Connectors -> Add, paste the URL, and save).* ### Method B: Via Manual Config File (Claude Desktop) If you are running Claude Desktop locally and prefer file-based configuration, you can modify your `claude_desktop_config.json` file. Because Truto acts as a remote server over HTTP, you will use the Server-Sent Events (SSE) transport adapter. Edit your configuration file (located at `~/Library/Application Support/Claude/claude_desktop_config.json` on macOS or `%APPDATA%\Claude\claude_desktop_config.json` on Windows): ```json { "mcpServers": { "dbt_labs_mcp": { "command": "npx", "args": [ "-y", "@modelcontextprotocol/server-sse", "--url", "https://api.truto.one/mcp/a1b2c3d4e5f6g7h8..." ] } } } ``` Restart Claude Desktop. The dbt Labs tools will now appear in the application interface, ready for execution. ## Hero Tools for dbt Labs Truto automatically generates tools for every documented resource in the dbt Labs API. Below are the highest-leverage hero tools for managing security, identity, and compliance. ### List All SCIM Users **Tool:** `list_all_dbt_labs_scim_users` Retrieves the complete list of users provisioned via SCIM in the dbt Labs account. This is critical for auditing active enterprise identities and mapping internal user IDs for subsequent updates or deletions. > "Fetch all SCIM users currently active in our primary dbt Labs account and output their names, emails, and SCIM IDs in a markdown table." ### Delete a SCIM User **Tool:** `delete_a_dbt_labs_scim_user_by_id` Removes a user from the dbt account via SCIM, immediately revoking their access and freeing up their enterprise license. > "Terminate access for the SCIM user with ID '12345'. Ensure the deletion is successful, then list all service tokens to check if any orphan tokens remain tied to their ID." ### Create an Audit Logs Export **Tool:** `create_a_dbt_labs_audit_logs_export` Submits a bulk export request for account audit logs. This triggers the asynchronous backend job required to generate the historical compliance data. > "Trigger a new audit log export for our dbt Labs account covering the last 30 days of activity. Give me the export job ID so we can poll its status." ### Get Audit Logs Export Status **Tool:** `get_single_dbt_labs_audit_logs_export_by_id` Checks the state of a previously requested audit log export. Claude uses this to poll the API until the `status` indicates the file is ready for download. > "Check the status of audit log export job 'job_9876'. If it is completed, proceed to download the file. If it is still processing, wait 10 seconds and check again." ### Update an IP Restriction **Tool:** `update_a_dbt_labs_account_ip_restriction_by_id` Modifies an existing IP restriction rule. This allows security automation agents to dynamically update allowlists when VPN blocks or corporate NAT gateways change. > "Update the IP restriction rule with ID 'rule_456' to include the new CIDR block '192.168.1.0/24'. Verify that the payload applies cleanly without failing on conflicting subnets." ### List Account Service Tokens **Tool:** `list_all_dbt_labs_account_service_tokens` Retrieves all active service tokens for the account. This is essential for discovering stale tokens, auditing permissions, and rotating credentials linked to CI/CD pipelines. > "Retrieve all service tokens active on the dbt Labs account. Flag any tokens that were created over 90 days ago so we can schedule them for rotation." For the complete tool inventory and granular JSON schema details, view the [dbt Labs integration page](https://truto.one/integrations/detail/dbtlabs). ## Workflows in Action Access to individual tools is useful, but the real power of connecting dbt Labs to Claude lies in orchestrating multi-step administrative workflows. ### Scenario 1: Offboarding a Compromised Developer When a security incident occurs, security operations teams need to immediately revoke access across all platforms. In dbt Labs, this means stripping the user's SCIM identity and destroying any personal or service tokens associated with their account. > "A security alert was triggered for engineer Alice Smith. Immediately locate her SCIM profile in dbt Labs, revoke her access by deleting the SCIM user, and then audit all account service tokens to ensure no active tokens are associated with her user ID. Delete any that you find." ```mermaid sequenceDiagram participant User as Human Operator participant Claude as Claude Desktop participant MCP as Truto MCP Server participant dbt as dbt Labs API User->>Claude: "Revoke Alice Smith's access and delete her tokens." Claude->>MCP: Call tool `list_all_dbt_labs_scim_users` MCP->>dbt: GET /api/v2/accounts/{account_id}/scim/v2/Users dbt-->>MCP: Returns SCIM users list MCP-->>Claude: JSON response containing Alice's ID (user_88) Claude->>MCP: Call tool `delete_a_dbt_labs_scim_user_by_id` (id: user_88) MCP->>dbt: DELETE /api/v2/accounts/{account_id}/scim/v2/Users/user_88 dbt-->>MCP: 204 No Content MCP-->>Claude: Deletion confirmed Claude->>MCP: Call tool `list_all_dbt_labs_account_service_tokens` MCP->>dbt: GET /api/v3/accounts/{account_id}/service-tokens dbt-->>MCP: Returns active tokens MCP-->>Claude: JSON array of tokens Claude->>MCP: Call tool `delete_a_dbt_labs_account_service_token_by_id` (for matching tokens) MCP->>dbt: DELETE /api/v3/accounts/{account_id}/service-tokens/{token_id} dbt-->>MCP: 204 No Content MCP-->>Claude: Tokens deleted Claude-->>User: "Alice Smith has been removed via SCIM and 2 associated service tokens were deleted." ``` **What the user gets back:** Claude confirms that the user's SCIM profile was successfully located and deleted, effectively locking them out of the platform. It also verifies that the token list was parsed and confirms the destruction of any rogue credentials. ### Scenario 2: Asynchronous Compliance Auditing During a SOC 2 or ISO 27001 audit, compliance officers need historical logs proving that production deployments were not altered by unauthorized users. Because dbt Labs exports these logs asynchronously, Claude must manage the lifecycle of the request. > "We need evidence for our SOC 2 audit. Trigger an audit log export for our dbt Labs account. Monitor the job status until it completes, then download the final log file and summarize any IP restriction modifications made in the last 14 days." ```mermaid flowchart TD A["Claude triggers
export request"] -->|`create_a_dbt_labs_audit_logs_export`| B["MCP Server
POSTs to dbt"] B --> C{"dbt returns
export ID"} C --> D["Claude polls
status"] D -->|`get_single_dbt_labs_audit_logs_export_by_id`| E{"Status ==
Complete?"} E -->|No| D E -->|Yes| F["Claude calls
download tool"] F -->|`list_all_dbt_labs_downloads`| G["MCP retrieves
CSV file"] G --> H["Claude parses CSV
for IP rule changes"] ``` **What the user gets back:** Claude handles the API polling mechanics silently. Once the dbt Labs backend finishes generating the report, Claude downloads the raw CSV data, analyzes the log events internally, and outputs a clean markdown summary of every IP restriction rule change, noting the timestamp and the user responsible. ## Security and Access Control Exposing an enterprise infrastructure platform like dbt Labs to an LLM requires strict governance. Truto MCP servers are generated with robust access controls baked into the configuration payload, allowing you to limit exactly what the agent can do. * **Method Filtering (`config.methods`):** Restrict the server to specific operation types. By setting this to `["read"]`, the MCP server will only generate tools for `get` and `list` endpoints. Claude will be able to audit users and logs, but the API will physically block any attempts to create, update, or delete resources. * **Tag Filtering (`config.tags`):** Scope the server by functional area. If you only want Claude to manage identity, you can filter tools using tags like `["scim", "users"]`, hiding unrelated functionality like database connections or project repositories. * **Secondary Authentication (`require_api_token_auth`):** By default, possessing the MCP URL is enough to access the tools. Setting this flag to `true` adds a secondary auth layer, requiring the client to also pass a valid Truto API token in the `Authorization` header. This ensures only authenticated team members can execute the workflow. * **Server Expiration (`expires_at`):** For temporary workflows - like giving a contractor agent access to run a one-off infrastructure audit - you can set a TTL. Once the timestamp passes, the highly available KV store automatically expires the token, and distributed alarms tear down the server access permanently. By leveraging these controls, you can confidently connect Claude to your dbt Labs environment, transforming complex, multi-step API mechanics into simple, conversational automation.