Rudder Lookout Security and Data Handling Private Beta

Rudder Lookout is currently in Private Beta, where we work with early users and customers to test new capabilities and gather feedback before making it generally available.

Contact your Customer Success Manager if you are interested in enabling Lookout for your team.

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.

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.

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.

Public links and membership

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.