cd /news/ai-products/how-wren-ai-enforces-role-based-acce… · home › topics › ai-products › article
[ARTICLE · art-140805] src=getwren.ai ↗ pub= topic=ai-products verified=true sentiment=· neutral

How Wren AI Enforces Role-Based Access Control on AI-Generated SQL

Wren AI detailed how its Wren Engine enforces row-level and column-level access control on AI-generated SQL at query time, applying policies based on session properties such as department, region and organization rather than on the prompt. The company said session properties supplied via the X-Wren-Session-Properties header are validated and bound as parameters during query parsing, preventing SQL injection through crafted user attributes, and that row-level security rules for tenant isolation, regional access, owner/team access and role-driven access are compiled into every query touching the protected models. The post was published and updated on Sep 28, 2026.

by read7 min views1 publishedSep 28, 2026
How Wren AI Enforces Role-Based Access Control on AI-Generated SQL
Image: Getwren (auto-discovered)

The Wren Journal Product, Tutorial

Wren AI doesn't replace your data security policy, it enforces it. Row-level and column-level security are applied in Wren Engine at query time, driven by who is asking, even when the SQL was written by an AI.

Wren AI Product Team

Updated: Sep 28, 2026

Published: Sep 28, 2026

Every company already has a data security policy. The question an AI analytics tool has to answer is not "do you have one?" but "will you actually follow it when a model is writing the SQL?"

That is the problem this short demo walks through. Wren AI doesn't replace your policy. It enforces it: who sees which rows, which columns, and what happens when the rules aren't met, applied at query time for every question, chart and API call.

Why AI-generated SQL needs a different kind of guardrail #

In a traditional BI tool, access control often lives in the dashboard. An analyst builds a report, someone scopes it to a team, and the report is the boundary.

A natural-language interface has no such boundary. Anyone can ask anything, and the SQL is composed on the fly. If a model can write SELECT salary FROM employees, then "please don't show salaries" in a prompt is not a control. It is a suggestion.

So the enforcement has to sit below the model, at the point where a query is about to run. In Wren AI, that point is Wren Engine. Every query, whether a person or an agent wrote it, is routed through the engine. Policies are attached there, before anything executes against your warehouse.

Start with who is asking: session properties #

The demo opens with a single user, Erin, and the attributes that describe her:

- **department:** HR
- **region:** APAC
- **organization:** Acme

In Wren AI these are session properties: contextual values that travel with each request, such as a user ID, department, role, or region. For API and embedded use, the calling application supplies them with each request in the X-Wren-Session-Properties header.

Session properties are what policies evaluate against. Critically, they are never pasted into SQL as raw strings. Wren Engine validates them and binds them as parameters while it parses the query and generates dialect SQL for your data source. No string concatenation means no SQL injection path through a crafted user attribute.

Row-level security: which rows each person sees #

Row-level security (RLS) filters the rows of a model based on the session. You write a condition once, apply it to one or more models, and Wren Engine adds it to every query that touches them.

The common patterns are the ones you would expect from Snowflake, BigQuery, SQL Server or PostgreSQL:

  • Tenant or organization isolation. Each customer only sees its own data.
  • Regional access. Users see only the regions they are assigned.
  • Owner or team access. Reps see the deals they own, or those shared with their team.
  • Role-driven access. Rows tagged for a role are visible only to users who hold it.

For Erin, an organization rule looks like this: She asks a plain question, the model writes a plain query, and the engine compiles the policy into it before execution:

Nothing about the question had to mention Acme. The filter comes from the session, not the prompt. The same approach extends to region allow-lists (region_id IN (...)) and, for users entitled to thousands of accounts, to an entitlement mapping table resolved with a subquery so the request stays small.

Column-level security: which columns each person sees #

Row filters don't help when the sensitive part is an attribute rather than a record. Salaries, SSNs, emails, unit costs and internal margins sit on rows that many people legitimately need to see.

Column-level security (CLS) protects those columns without locking the whole table. A policy picks the models and columns to protect and one access rule, which compares a session property to a value:

Protected columns Session property Rule Result
employees.salary ,employees.ssn department equals HR HR can query them. Sales cannot.
products.internal_cost role equals finance Only Finance sees internal cost.
orders.unit_cost ,orders.profit_margin role in finance, executive Both roles see both columns.

This is where Erin's department: HR matters. She can ask about compensation by team and get an answer. A colleague in Sales asking the same question doesn't get a quietly truncated result. The query is rejected with a clear Restricted by policy message that names the column, so nobody mistakes a blocked answer for an empty one.

What happens when the rules aren't met #

Two behaviors in the demo are worth pausing on, because they are where many systems get lenient.

Missing context blocks the query. If a policy depends on a session property that is marked required and the request doesn't carry it, Wren AI blocks the query before any data leaves your warehouse. It doesn't fall back to "no filter." For optional properties you set an explicit default, which lets you build default-deny rules, for example showing customers.email only when is_internal is true and treating every other request as external.

Admin is not the same as all access. Owning or administering a Wren AI project lets you manage models and policies. It does not let you bypass them when you query. The person who configures the security rules is still subject to them, which is exactly what an auditor wants to hear.

One enforcement path across every surface #

Because the policy lives in the engine rather than in a particular screen, it follows the query wherever it comes from:

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

That is the practical meaning of "governed at execution." A question asked in the Wren AI UI and the same question sent through the API resolve against the same context layer and pass through the same policies.

Try it on your own data #

Data security is available on the Enterprise Cloud and Enterprise Plus plans, and existing Business plan customers keep access. You can preview a policy by simulating session property values before you save it, then ask a question in Home to confirm what a given user sees.

To go deeper:

- [Data Security Overview](https://docs.getwren.ai/cp/guide/security/data-security)
- [Row-Level Security examples](https://docs.getwren.ai/cp/guide/security/rls-examples)
- [Column-Level Security examples](https://docs.getwren.ai/cp/guide/security/cls-examples)
- [Watch more product demos](https://getwren.ai/demos?demo=wren-ai-role-based-access-control)

Or start with Wren AI Cloud and set up your first policy on a model you already have.

See governed GenBI in action

Watch short demos of Wren AI turning business questions into governed SQL, charts, and reusable GenBI apps.

Watch product demos

Jul 14, 2026

You Can't Trust an AI Agent You Can't Debug.

An AI agent that answers business questions has to be debuggable and measurable, or 'earned trust' is just a slogan. How thread tracing, benchmarks, and the AI Advisor close the loop.

Aug 10, 2026

Wren AI Is Now Available in Microsoft Teams

Wren AI is now listed on Microsoft Marketplace. Ask a question in plain language inside a Teams chat or channel and get the answer in-thread, with the SQL and a chart, resolved against the same context layer every other surface uses.

Apr 02, 2026

The Missing Context Layer for AI Agents Over Business Data

Why we rebuilt Wren Engine from a context layer into an open context engine, and what we learned along the way

The Wren Journal

Get the next deep dive in your inbox #

Practical GenBI guides, product updates, and customer lessons from the Wren AI team. A couple of emails a month, no noise.

Keep reading

Insight, Product

You Can't Trust an AI Agent You Can't Debug.

An AI agent that answers business questions has to be debuggable and measurable, or 'earned trust' is just a slogan. How thread tracing, benchmarks, and the AI Advisor close the loop.

Product, News

Wren AI Is Now Available in Microsoft Teams

Wren AI is now listed on Microsoft Marketplace. Ask a question in plain language inside a Teams chat or channel and get the answer in-thread, with the SQL and a chart, resolved against the same context layer every other surface uses.

Insight, Product

The Missing Context Layer for AI Agents Over Business Data

Why we rebuilt Wren Engine from a context layer into an open context engine, and what we learned along the way

── more in #ai-products 4 stories · sorted by recency
── more on @wren ai 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
→ Live at https://your-agent.zahid.host ✓
Get free account → Pricing
from €0/mo · no card required
LIVE [news/how-wren-ai-enforces…] indexed:0 read:7min 2026-09-28 · —