Overview
Data Security is only available in Enterprise Plan and above
Wren AI’s Data Security framework ensures that sensitive information remains safe while empowering users to access the insights they need. This page provides a high‑level overview of the security components powering Wren AI, including row‑level policies, upcoming column‑level policies, and how user context is captured via session properties.
What you’ll learn on this page
- Definitions & scope: What is a policy (row or column level)? What are session properties and how are they used?
- Policy types: Row‑Level Security and Column‑Level Security.
- Enforcement surfaces: Where Wren AI applies security controls across UI, API, and connectors.
Understanding Policies & Session Properties
Policies in Wren AI declare who can view what.
- Row‑Level Security (RLS): Restricts which rows of a model (i.e., table) each user can access, based on their identity and context.
- Column‑Level Security (CLS): Coming soon. Will control which columns are visible to different groups or users.
Session properties are contextual values that drive policy evaluation. Examples include:
- User's ID on your SaaS platform
- User's department in your company
- User's role in your company
During policy evaluation, these properties are injected into queries as parameters, enabling secure, dynamic filtering without string concatenation.
Row‑Level Security (RLS)
RLS ensures that users only see rows they’re permitted to. It supports data isolation, privacy, multi‑tenant use cases, and least‑privilege access. RLS follows industry‑standard patterns similar to capabilities found in Snowflake, BigQuery, SQL Server, and PostgreSQL.
Common scenarios where RLS is used:
- Tenant/organization isolation: Each customer sees only their own data.
- Regional access: Users see data only for their allowed regions.
- Owner or team access: Users see items they own or those shared with their teams.
- Time‑bounded access: Users are restricted to a permitted time window.
You can define policies once and apply them to one or more tables. Policies are evaluated at query time using the current request’s session properties.
Check out the RLS Examples to see how to use RLS in practice.
Column‑Level Security (CLS)
CLS controls access to sensitive columns without blocking entire tables. It complements RLS by protecting attributes like salaries, PII, costs, and internal-only metrics.
How it works at a glance:
- You select the models and columns to protect.
- You define one access rule per policy: compare a single session property (e.g.,
role,country,group) to a value using an operator. - If the rule is not satisfied, any query that references those columns fails with a clear “Restricted by policy” error.
Examples of when to use CLS:
- Hide
salary,ssn, oremailunless the user is in HR. - Allow
unit_costonly for Finance; block it for everyone else. - Gate
priceby region using acountrysession property.
See the step‑by‑step guide: Column‑Level Security and practical CLS Examples.
Where Wren AI enforces security
| Surface | Row‑Level Security | Column‑Level Security |
|---|---|---|
| Asking questions | Yes | Yes |
| Generating charts | Yes | Yes |
| Data previews | Yes | Yes |
| API requests (ask, chart) | Yes | Yes |
| Spreadsheets | Yes | Yes |
| Dashboard‑embedded charts | Not yet | Not yet |
How Wren AI protects AI‑generated SQL
Queries are routed through Wren Engine with policy enforcement
Even when SQL is generated by AI, Wren AI routes queries through the Wren Engine. Policies are applied at Wren Engine, so row‑level conditions and column‑level conditions are attached before execution against your data source.
Session properties are validated; no SQL injection
Session properties (such as user, org, region, roles) never touch your warehouse as raw strings. They are validated and bound during Wren Engine parsing and dialect SQL generation, preventing SQL injection and ensuring consistent, least‑privilege access.