RudderStack Docs – Rudder Lookout Integrations

Lookout: How to Connect a Warehouse to Lookout

Mon, 01 Jan 0001 00:00:00 +0000

The Lookout agent requires access to your data warehouse to answer questions about your data.

The agent lists tables, inspects schema, and runs SQL to answer questions, build dashboards, and investigate your pipelines. The results flow straight into charts, tables, metrics, and funnels.

Lookout supports the following warehouses:

PostgreSQL
Snowflake
Redshift
BigQuery
Databricks

Connect a warehouse

Only admins can connect, edit, and test a warehouse connection. See Roles and Permissions for more information.

Go to Settings > Warehouse.
Select Add account and choose your warehouse type.
Enter the connection details and save.

Note that:

Connected warehouses appear at the top of the page.
RudderStack destinations that are not yet mapped to a warehouse connection are listed under Unmapped Destinations, so you can see at a glance what is available to connect.

Best practices

Follow these best practices to ensure a smooth and secure connection to your warehouse.

Dedicated read-only service account

For every warehouse, connect Lookout through a dedicated service identity that has read-only access rather than reusing a person’s credentials or an account with broad privileges. This isolates RudderStack’s access to your warehouse, keeps it strictly read-only, and makes it easy to audit or revoke independently of anyone’s personal login.

Each platform has its own name for this kind of identity, but the principle is the same — create an identity, grant it read-only access to the data Lookout needs, and use it for the connection:

Warehouse	Identity to create	Access to grant
Snowflake	Service user with a dedicated read-only role	`SELECT` on the relevant databases/schemas
BigQuery	Service account	Read-only roles (for example, Data Viewer + Job User)
Databricks	Service principal	Read-only grants on the relevant catalogs/schemas
Redshift	IAM service user / dedicated database user	`SELECT` on the relevant schemas
PostgreSQL	Dedicated database role	`SELECT` (read-only) on the relevant schemas

Tip: Scope the grant to only the databases, schemas, and tables Lookout needs. Read-only, least-privilege access keeps the connection’s blast radius small.

Note that creating a service account, role, or user, and granting it read-only access usually requires warehouse-administrator privileges. If you don’t manage your warehouse directly, reach out to your Infra team to have it set up.

The exact credentials and permissions each warehouse needs are shown on its connection page in Settings > Warehouse.

Allocate and isolate compute

The following recommendations help Lookout respond quickly while keeping costs predictable. They are written with Snowflake in mind, but the same principles apply to other warehouses — the exact settings may differ:

Assign enough compute: Larger compute size means faster queries and quicker access to your data, which makes the agent feel more responsive.
Isolate the workload: Where possible, point Lookout at a separate, dedicated compute resource rather than one shared with production jobs. This isolates Lookout’s usage for cleaner cost attribution and avoids competing with other workloads.
Auto-suspend aggressively: Configure the compute to shut down quickly when idle — for example, after 5 minutes of inactivity or less. Because Lookout’s usage is bursty, aggressive auto-suspend keeps costs low without affecting responsiveness.

Read-only access

Warehouse access is strictly read-only. The agent can query and inspect your data, but it can’t write to or alter your warehouse.

Note that:

Dashboards store their definition, not their data — they re-run their queries on every load and store no result rows on RudderStack’s servers
Connection credentials are encrypted at rest

See Security and Data Handling for more information.

Where warehouse data is used

Once a warehouse is connected, the same connection powers the following Lookout features:

Chat answers: Natural-language questions answered with live queries
Dashboards: Panels that re-run their queries on every load
Slack: The same answers from a Slack DM or channel

Lookout: How to Connect GitHub to Lookout

Mon, 01 Jan 0001 00:00:00 +0000

Connecting GitHub to Lookout allows the agent to explore repositories, review pull requests, and propose code changes as pull requests.

Connect GitHub

Only admins can connect GitHub. Once connected, any member can use the repository tools in chat. See Roles and Permissions for more details.

From Settings > SCM, install the Lookout GitHub App and grant it access to the repositories you want Lookout to work with.

Installing the app enables webhook-driven pull-request review and bot-authored pull requests.

Once the app is installed, map each repository to the RudderStack source it instruments under Settings > Sources, so Lookout knows which repository to use for review and instrumentation.

How it works

Once a GitHub connection is set up, the agent:

Explores repositories: Reads files, lists commits, searches code, and views pull-request diffs to understand how your data is instrumented.
Proposes changes: Authors branches and commits and opens pull requests for your team to review.
Automates pull-request review: When a pull request is opened or updated, Lookout reviews the diff for breaking data-contract changes and posts its findings as review comments. See PR and MR Review for more details.
Implements pull requests: A background agent implements an approved measurement plan by opening pull requests against your linked repositories.

The agent’s code changes always arrive as pull requests — proposals that sit in your normal review process. A human reviews and merges before anything lands on your main branch.

How changes are attributed

Bot-authored commits and pull requests are made under the Lookout GitHub App identity, so changes proposed by Lookout are clearly distinguishable from your team’s own commits in your GitHub history.

Lookout: How to Connect GitLab to Lookout

Mon, 01 Jan 0001 00:00:00 +0000

Connecting GitLab to Lookout allows the agent to explore repositories, propose merge requests, and review incoming changes — for both gitlab.com and self-hosted instances.

Connect GitLab

Only admins can connect GitLab. Once connected, any member can use the repository tools in chat.

See Roles and Permissions for more details.

Connect GitLab from Settings > SCM with a per-workspace access token.

Note that:

A workspace can hold several connections (one per GitLab instance), so the same project path can exist on multiple instances without collision.
Each connection stores its own encrypted token.
Lookout supports both gitlab.com and self-hosted instances.

How it works

Once a GitLab connection is set up, the agent:

Explores repositories: Browses files, lists commits, searches code, and views merge-request diffs.
Proposes changes: Authors commits and opens merge requests for review.
Automates merge-request review: When a merge request is opened or updated, Lookout reviews the diff for breaking data-contract changes and posts its findings as comments. See PR and MR Review for more details.

GitLab integration currently supports chat exploration, agent-proposed merge requests, and automated merge-request review.

Measurement Plan instrumentation — where an approved plan is implemented as pull requests by a background agent — is currently supported for GitHub repositories only.

The agent’s changes always arrive as merge requests — proposals that sit in your normal review process. A human reviews and merges before anything lands.

How changes are attributed

Changes proposed by Lookout are identifiable in your GitLab history:

Commits carry a Co-authored-by: trailer attributing the change to Lookout.
Merge requests are labeled created-by::rudder-ai.

Lookout: How to Connect RudderStack Control Plane to Lookout

Mon, 01 Jan 0001 00:00:00 +0000

Connecting RudderStack to Lookout lets the agent read and manage your control plane from chat — including your sources and destinations, transformations, Tracking Plans, and Audiences.

Connect RudderStack

Signing in to Lookout with RudderStack is recommended.

When a user creating the workspace signs in with RudderStack, Lookout automatically pulls in the list of RudderStack workspaces they belong to — so linking a Lookout workspace to the right RudderStack workspace takes a single click.

When you create a workspace with this method, Lookout shows the RudderStack workspaces you are part of:

Link: Create a Lookout workspace connected to that RudderStack workspace
Join: If your team already uses a Lookout workspace for that RudderStack workspace, join it so everyone’s chats and dashboards stay together (or choose to create a separate workspace instead)

Connect manually

Though signing in with RudderStack is the recommended approach, a workspace admin can also connect manually under Settings > General by entering a RudderStack Workspace ID and Personal Access Token. The connection is scoped to your workspace and the token is stored encrypted.

The RudderStack connection is configured once per workspace. Once connected, any member can use the RudderStack tools in chat. Connecting it is therefore a workspace-level decision.

See Roles and Permissions for more details.

How it works

Once a RudderStack connection is set up, the agent can:

Inspect sources, destinations, transformations, Tracking Plans, and Audiences
Review live event metrics, schemas, and Tracking Plan violations
Make changes — for example, create or update a transformation or an Audience

Important consideration

Whether the agent can make changes depends on how the connection is authorized. A read-write RudderStack connection enables the management tools above. However, a read-only connection — for example, a workspace linked with a read-only token — limits the agent only to inspecting and reporting.

Once a RudderStack connection is set up, the agent can answer questions and make changes that span your warehouse data and your RudderStack configuration in the same conversation. For example, checking how an event is defined in a Tracking Plan and where it lands in the warehouse.

Lookout: How to Map Sources to Repositories

Mon, 01 Jan 0001 00:00:00 +0000

The Sources tab connects each of your RudderStack sources to the GitHub or GitLab repository where that source’s events are instrumented. This mapping lets Lookout connect your data to the code that produces it, so when you ask for a tracking change, it knows exactly which repository needs a pull request.

Prerequisites

Mapping a source to a repository connects two systems, so both must already be set up:

RudderStack integration set up, so your sources are available to map
A linked GitHub or GitLab repository

Map a source to a repository

From Settings > Sources, select Connect Source, then configure these settings:

Setting	Description
RudderStack source	Choose the source you want to map
Repository	Choose the GitHub or GitLab repository where that source’s events are instrumented
Subfolder	For a monorepo, point Lookout at the folder that holds the source’s code. Defaults to `/` (the repository root)

The Sources tab lists your sources with their current mappings and shows any sources that aren’t connected yet, so you can map them.

How it works

Your events are defined in your warehouse and tracking plans, but they are emitted by analytics calls in your application code — this code lives in a repository. The Sources tab records which repository (and, for monorepos, which subfolder) corresponds to each source.

With the source-repository mapping in place, a request like “Start capturing a checkout_started event so it reaches our warehouse” becomes actionable end to end:

Lookout identifies the source the event belongs to
It looks up the repository mapped to that source
It proposes the instrumentation change as a pull request against the right repository — and the right subfolder

This mechanism powers Measurement Plans and the instrumentation agent. Without the mapping, Lookout would know what to change but not where.

Lookout: How to Connect Slack to Lookout

Mon, 01 Jan 0001 00:00:00 +0000

Connecting Slack to Lookout lets your team talk to the same agent via messages or a bound channel, without opening the web app. They can ask questions, pull metrics, and get answers right in the conversation.

Slack is an access surface, not a data source. It changes where you talk to the agent. The answers still come from the systems that Lookout is connected to, like your warehouse.

Install Slack

Workspace admins can install Slack from Settings > Slack via Slack OAuth. Once installed, the settings page shows your installation, linked users, channel bindings, and available commands.

Slack commands

From Slack, your team can use a few simple commands:

Command	What it does
`/lookout connect`	Link your Slack account to a workspace
`/lookout setup`	Bind a channel to a workspace
`/lookout status`	Show your current connection — the linked workspace, or the channel’s binding
`/lookout help`	Show available commands

Linked users and guest access

Linked users act as their full workspace identity, with thread-to-session continuity so a conversation can pick up where it left off. A Slack user can link their account with /lookout connect.
Guest access lets Slack users who haven’t yet linked an account ask read-only questions in bound channels and DMs. It is on by default — an admin can disable it with the Allow guest access in Slack toggle on the Slack settings. See Roles and Permissions for details on how guest access fits into the workspace model.

Channel bindings

Binding a channel to a workspace routes messages in that channel to Lookout’s agent for that workspace. Note that users may still need to run /lookout connect unless guest access is enabled.

Binding is done in Slack with /lookout setup by any workspace member. Admins can view and unbind channels from the Channel Bindings section on Settings > Slack.

Lookout: How to Connect External AI Tools to Lookout

Mon, 01 Jan 0001 00:00:00 +0000

Lookout exposes a curated set of its tools to external AI tools through the Model Context Protocol (MCP). This lets an approved external assistant or agent call into your workspace programmatically, for example, to run a warehouse query or read a dashboard, using the same connections your team already set up.

What it exposes

External tools get a curated, mostly read-only subset of Lookout’s capabilities. For the exact, current tool list, see the in-app MCP reference in your workspace.

Tool	Permissions	Description
Warehouse	Read	Query a connected warehouse, list tables, describe a table, and list warehouses
Dashboards	Read	List dashboards, get a dashboard, and run a single dashboard panel
Source documentation	Read	List and read Lookout’s AI-generated instrumentation documentation for your sources. This is the generated documentation in the Context Hub, not your RudderStack source catalog
Dashboards	Write	`save_dashboard` creates or updates a dashboard. It is the only write tool and is gated behind the `mcp:write` scope (see below)

Scopes

When an external tool authorizes via OAuth, or when you create a named programmatic token, the default scope is mcp:read mcp:write, which includes the save_dashboard write capability.

To grant read-only access, explicitly request the mcp:read scope only.

Because the default scope includes mcp:write, an external tool that doesn’t narrow its scope can save dashboards in your workspace. If a tool only needs to read, grant it mcp:read only.

How access is secured

Access uses OAuth 2.1 (with PKCE, dynamic client registration, and a consent screen) or named programmatic tokens.
Programmatic tokens are stored hashed and are prefix-identified so they can be revoked.
Tokens used for external access are separate from your web session.

Setup

Any member can create clients and tokens for external access from the MCP area in the sidebar (also reachable from Settings > Integrations). External tools then call into the workspace using those credentials.

External AI tool access is enabled at the deployment level, not per workspace. If you don’t see the MCP area, it may not be enabled for your deployment — check with your admin.

RudderStack Docs – Rudder Lookout Integrations

Lookout: How to Connect a Warehouse to Lookout

Connect a warehouse

Best practices

Dedicated read-only service account

Allocate and isolate compute

Read-only access

Where warehouse data is used

Lookout: How to Connect GitHub to Lookout

Connect GitHub

How it works

How changes are attributed

Lookout: How to Connect GitLab to Lookout

Connect GitLab

How it works

How changes are attributed

Lookout: How to Connect RudderStack Control Plane to Lookout

Connect RudderStack

Connect manually

How it works

Lookout: How to Map Sources to Repositories

Prerequisites

Map a source to a repository

How it works

Lookout: How to Connect Slack to Lookout

Install Slack

Slack commands

Linked users and guest access

Channel bindings

Lookout: How to Connect External AI Tools to Lookout

What it exposes

Scopes

How access is secured

Setup

See also