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.

The Wren Journal https://getwren.ai/blog Product, Tutorial How Wren AI Enforces Role-Based Access Control on AI-Generated SQL 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 https://cloud.getwren.ai/ 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 https://getwren.ai/demos Related posts Jul 14, 2026 https://getwren.ai/post/trust-ai-agent-thread-tracing-evaluation 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 https://getwren.ai/post/wren-ai-microsoft-teams-connector 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 https://getwren.ai/post/the-missing-context-layer-for-ai-agents-over-business-data 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. https://getwren.ai/post/trust-ai-agent-thread-tracing-evaluation 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 https://getwren.ai/post/wren-ai-microsoft-teams-connector 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 https://getwren.ai/post/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