Rudder Lookout Security and Data Handling Private Beta

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

For questions about RudderStack’s security and data handling practices not covered in this guide, 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.

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 is important because some surfaces handle untrusted input — a pull request from an outside contributor, a comment on a merge request. Narrowing each surface to its minimum tool set means a crafted input cannot 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:

• Code changes arrive as pull and merge requests: Proposals that sit in your normal review process, not commits pushed straight to your main branch
• Measurement plans are human-approved: From chat the agent can only save and manage a plan; turning an approved plan into code is a separate, human-gated step
• 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 Share 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.