Lookout Security and Data Handling

Beta
Understand how Lookout treats your data, credentials, and connected systems.

Lookout is currently in Public Beta. Contact the Product team if you have any questions.

Lookout is a conversational agent that can read your warehouse, read your repositories, and read your RudderStack control plane — and it is deliberately constrained. This guide explains how it treats your data and the systems you can connect.

For questions about RudderStack’s security and data handling practices not covered here, or to discuss requirements for your deployment, contact Customer Success.

Warehouse access

The Lookout agent’s access to your warehouse is read-only. It can list tables, inspect schema, and run queries to answer questions and build dashboards, but it cannot write to or alter your warehouse.

On Databricks, Lookout can also read Unity Catalog metric view definitions — the descriptions, display names, and synonyms on each view. It reads that metadata when a question needs it and writes nothing to your Databricks workspace. As with query results, the definition is kept in the chat’s history.

See How to Use Databricks Metric Views in Lookout for more information.

Where Lookout runs

Lookout runs in the US. This applies to workspaces in every region, including EU and IN workspaces:

  • Lookout stores its workspace data, such as chats, dashboards, and audience definitions, in the US
  • Lookout connects to your warehouse from US IP addresses

If your warehouse restricts network access, allow the Lookout IP addresses. See Allow Lookout to reach your warehouse for the addresses.

What Lookout dashboards store

Dashboards store their definition — the parameters and panels that make them up — not their results. No result rows are stored on RudderStack’s servers. Each time a dashboard loads, its queries run again against your warehouse.

Note that within a single browser session, the interface may briefly reuse already-fetched results while it re-queries, but nothing is persisted server-side. This keeps dashboards current and ensures your warehouse data stays in your warehouse.

What leaves your warehouse when you activate

An audience stores its definition — the rules that describe membership — not a list of identifiers. Sizing it runs that definition against your warehouse and returns a number.

Activating an audience is the point at which identifiers, rather than counts, leave your warehouse. The audience becomes a source in your linked RudderStack workspace, and RudderStack sends the matching records to the destination on the schedule you set. What is sent is the identifier you mapped — an email, phone number, or user ID — for records that currently match.

The identifiers travel through your own RudderStack workspace and your own destination account. Removing an activation stops the sync, but it doesn’t delete the audience already sitting in the destination — remove that in the destination itself.

Credentials encryption

The connection credentials you share with Lookout (for example, your warehouse connection details) are encrypted at rest using AES-256-GCM.

Where Lookout keeps your warehouse password depends on the warehouse and on the link to your RudderStack workspace:

  • ClickHouse, with a link that can make changes: Lookout creates the warehouse account in your linked RudderStack workspace. It sends the password to RudderStack, which stores it. Lookout keeps no copy. It reads the password from RudderStack when it connects.
  • ClickHouse, with no link or a read-only link: Lookout stores the password, encrypted with AES-256-GCM.
  • Other warehouses: Lookout stores the credentials, encrypted with AES-256-GCM. If the link can make changes, Lookout also copies them to a Reverse ETL account in your linked RudderStack workspace. Reverse ETL then uses the same warehouse. RudderStack encrypts that copy with its own key. Lookout makes no copy for a read-only link or for Snowflake password authentication.
  • Redshift with IAM authentication: Lookout stores no password. It gets temporary credentials that are valid for up to one hour. It keeps them in memory only and gets new ones 5 minutes before they expire.

Least privilege, per task

The agent is assembled fresh for each task and handed only the tools that task needs. A chat in a workspace with no connected repositories simply has no source-control tools available. The agent never carries the full set of capabilities — each task starts with exactly what it needs and nothing more.

This matters because some surfaces handle input Lookout didn’t author — the contents of a repository, a message from someone outside your team. Narrowing each surface to its minimum tool set means a crafted input can’t reach tools that were never granted. The Slack surface is narrower still — it strips out anything that has no place in a direct-message conversation.

Consequential actions dependency

For consequential actions, the agent prepares the work and only a person can pull the trigger:

  • Source control is read-only: The agent reads your repositories. There is no tool for it to create a branch, commit, or open a pull request
  • Audiences are saved by you: The agent drafts a definition and measures it; saving it, and sending it to a destination, are actions you take
  • Public sharing is explicit: Publishing a dashboard is an action a person takes, not an agent

Workspace isolation

Every request is checked for workspace membership. The agent only ever sees the connections, repositories, and data belonging to the workspace you are working in, and it cannot reach outside it.

Note that:

  • Public dashboard links are unauthenticated: Anyone who holds the link can view the dashboard. There is no per-viewer login, only the secret token in the URL.

Treat publishing as a deliberate “make this externally visible” decision.

See Build Dashboards for more information.

  • Membership is a meaningful access decision: Members and admins share the team’s connected systems and roles separate configuration duties from everyday use. Treat adding someone to a workspace as granting them access to its connected data and systems. See Roles and Permissions for more information.

Questions? Let's figure it out together.

Join the RudderStack Slack community to connect with other users, customers, and the RudderStack team — or reach out for direct support.