Skip to main content

Access Control Best Practices

This guide explains how to set up access control in Wren AI so users only see data they are authorized to access, while keeping the data warehouse (e.g., Amazon Redshift) as the primary security boundary.

It covers:

  • Recommended access control architecture (defense-in-depth)
  • Best-practice connection and role patterns
  • When to use Row-Level Security (RLS) and Column-Level Security (CLS)
  • Operational guidance for audits and troubleshooting

Design principles​

1. Warehouse-first security boundary​

Your data warehouse should remain the ultimate enforcement point for object-level access (schemas/tables). Wren AI should not be configured in a way that expands the access scope beyond what you intend.

2. Defense in depth​

Wren AI adds additional guardrails on top of warehouse controls:

  • Wren AI does not allow end users to submit arbitrary SQL directly to the warehouse.
  • Queries are expressed as Wren SQL and go through Wren Engine parsing, planning, and rewrite before being compiled to warehouse SQL.
  • The engine rejects access to any table/column not defined in the Semantic Layer.

3. Least privilege, smallest blast radius​

Prefer role scoping and connection design that limits the maximum accessible surface area in case of misconfiguration.

How access control works in Wren AI​

Connection role defines what Wren AI can discover​

Wren AI builds the initial model using the Connection Info you provide (including the warehouse identity/role). Wren AI can only discover schemas/tables/columns that this connection role can access.

Semantic Layer acts as an explicit allowlist for the model​

Wren AI creates a Semantic Layer that defines the tables and columns the LLM can use. The LLM only plans against objects in this Semantic Layer.

Wren Engine enforces object access during rewrite/planning​

Wren SQL is rewritten and planned by Wren Engine before execution. Any reference to a table/column not defined in the Semantic Layer is rejected during the rewrite process (before anything is sent to the warehouse).

RLS/CLS apply fine-grained restrictions​

For per-user restrictions beyond warehouse object permissions:

  • RLS filters which rows a user can see at query time.
  • CLS restricts access to sensitive columns at query time.

See:

Pattern A: Single connection (tightest) + RLS/CLS (when needed)​

Use this when:

  • Most users can access the same general dataset surface area
  • You primarily need row or column restrictions (tenant / region / PII columns)

How it works

  1. Create a warehouse role for Wren AI with least-privilege access to the allowed schemas/tables.
  2. Connect Wren AI using that role.
  3. Model only required objects into the Semantic Layer (keep it minimal).
  4. Use RLS/CLS to enforce per-user restrictions where applicable.

Pros

  • Simple operations
  • Easy to keep one semantic model
  • Works well when you have consistent scoping keys (tenant_id, org_id, region, etc.)

Cons

  • If your warehouse role needs broad object access, you rely more on Wren-side policies and semantic allowlisting for separation.

Use this when:

  • Different teams must not access each other’s schemas/tables at all (Finance vs HR vs Product)
  • You want the warehouse to enforce strict object-level boundaries

How it works

  1. Define warehouse roles per domain:
    • e.g., wren_finance_role, wren_product_role, wren_hr_role
  2. Create separate Wren AI connections for each role (or separate workspaces/projects if that matches your org workflow).
  3. Each connection generates/maintains a Semantic Layer scoped to only what that role can access.
  4. Add RLS/CLS inside each domain only if needed.

Pros

  • Strongest object-level isolation (warehouse enforced)
  • Smaller blast radius per connection
  • Matches existing RBAC governance models

Cons

  • Potential duplication of semantic definitions across domains (mitigated with naming conventions and shared modeling standards)
One semantic layer” vs “multiple semantic layers”

If your organization insists on a single semantic Single Source of Truth (SSoT), you can still follow Pattern B by:

  • Keeping a “shared modeling standard” (metric naming, definitions, documentation) and
  • Using separate domain-specific semantic subsets that are consistent and governed In practice, a single global semantic layer that includes objects users must never touch is hard to reconcile with strict object isolation requirements.

Pattern C: Warehouse views for hard boundaries + Wren AI modeling on top​

Use this when:

  • You need to enforce stable access boundaries that are easy to audit
  • You want to centralize complex joins / masking in the warehouse

How it works

  1. Create secure views/materialized views per domain/use case (optionally with masking).
  2. Grant Wren AI connection role access only to these curated views.
  3. Model the views into the Semantic Layer (not raw tables).
  4. Use CLS/RLS only when necessary.

Pros

  • Very auditable (“Wren can only read these views”)
  • Simple mental model for security teams

Cons

  • Additional warehouse maintenance
  • May reduce flexibility for ad-hoc exploration

Choosing between RLS and CLS​

Use RLS when:

  • You can reliably scope data by a key (tenant/org/region/team)
  • Or you can join through an entitlement mapping table

Common examples

  • Multi-tenant SaaS: org_id
  • Geography: region
  • Department ownership: cost_center

Use CLS when:

  • The table is broadly accessible, but some columns are sensitive
  • Examples: email, phone, salary, ssn, internal notes, security fields

When RLS is hard Some tables don’t contain a scoping key and can’t be joined reliably. In these cases, prefer:

  • Warehouse RBAC/object isolation (Pattern B), and/or
  • Curated views that add the required join keys (Pattern C)

FAQ​

Why not rely only on Semantic Layer for access control?​

Semantic Layer is primarily a mapping/abstraction. Wren AI treats it as an allowlist enforced during query planning, but it should be used alongside warehouse RBAC and (when needed) RLS/CLS for defense in depth.

We already use BI tools with extracted datasets + Tableau RLS. How should we map that to Wren AI?​

Use:

  • Warehouse RBAC/object isolation to scope datasets (Pattern B or C)
  • RLS/CLS in Wren AI for fine-grained restrictions where needed
  • Keep semantic modeled surface minimal and governed