Row-Level Security in the Age of AI BI: Querio's Approach

How row-level security survives AI analytics: where to enforce filters, why agents need per-user identity, and how Querio applies RLS to every query.

Row-level security still works when an AI agent writes the queries — but only if the filter is enforced below the agent, and the agent runs as the person asking rather than as a shared service account. That is the whole design question. Everything else — prompt guardrails, output filtering, "the model was told not to show that" — is a policy suggestion, not access control.

This article covers where row-level security (RLS) can live in an AI BI stack, what breaks when a natural-language layer sits on top, how Querio enforces it, and a checklist you can take into any vendor evaluation.

Why AI Changes the Row-Level Security Problem

Traditional BI has a narrow, predictable query surface. An analyst publishes a dashboard, the platform parameterises it, and access rules are attached to the published object. Natural-language analytics removes that chokepoint: any user can generate any query, at any grain, at any time. Three things change.

The query surface becomes open-ended. You can no longer enumerate the queries in advance, so you cannot secure them one by one. Enforcement has to be a property of the connection, not of the artefact.
Identity gets laundered. Most AI tools connect with one warehouse credential and then decide, in application code, what each user is allowed to see. If that logic is wrong once, the warehouse has no idea — it saw a legitimate query from a legitimate account.
Answers leave the platform. A number that appears in a Slack thread or an AI assistant window is easy to forward and hard to audit. Governance has to follow the answer, not just the dashboard.

The failure mode nobody talks about is subtler than a leak: an AI tool applies a filter after the aggregate is computed. The user is blocked from seeing individual rows but the total they are shown still includes them. The permission model looks correct in a demo and is wrong in production.

The Four Places Access Control Can Live

Every AI analytics architecture puts enforcement in one of four layers. They are not equally strong, and the differences only show up under natural-language querying.

Enforcement layer	How it works	Strength under AI querying	Main trade-off
Warehouse-native (Snowflake, BigQuery, Redshift, Postgres)	Row access policies and views evaluated by the database itself	Strongest — restricted rows never enter the result set, whatever SQL is generated	Requires the analytics tool to pass a real user identity through to the warehouse
Context / semantic layer	Filters and permitted joins defined once, injected into every generated query	Strong when the layer is the only path to data and every query is inspectable	Only as good as the definitions in it; needs review discipline
BI application layer	The tool checks the user's role before returning results	Moderate — correct until a new surface (API, chatbot, agent) bypasses the check	Every new delivery surface re-opens the question
Prompt or model instruction	System prompt tells the model which data is off-limits	Weak — not an access control at all	Useful for tone and scope, never for compliance

The practical answer for most teams is the first two together: warehouse-native policies as the hard boundary, a governed context layer as the correctness layer, and nothing important riding on the third or fourth. If you want the broader background on the model layer itself, see what a governed context layer is and role-based security practices in BI platforms.

How Querio Enforces RLS

Querio's approach starts from the assumption that the agent is untrusted plumbing and the data platform is the authority.

Live, read-only, encrypted connections

Querio connects to Snowflake, BigQuery, Redshift, ClickHouse, MotherDuck, PostgreSQL, MySQL, MariaDB, SQL Server and MongoDB with encrypted, read-only credentials. There are no extracts and no duplicated copies, so there is no second dataset sitting outside your warehouse's policies with its own weaker permissions. Whatever row access policies you already run in the warehouse apply, because the query executes there. This is the same argument behind warehouse-native analytics generally.

Per-user identity, including for agents

Role-based access control governs the app. For agent traffic, Querio's MCP server uses OAuth, so a question asked inside Claude or another AI assistant inherits that user's data permissions rather than running under a shared robot account. This matters more than it sounds: it means the answer an executive gets and the answer a regional manager gets can legitimately differ, and the difference is enforced where it should be. If you are wiring assistants to a warehouse, the step-by-step MCP setup covers the mechanics.

A context layer that is reviewable

Joins, metric definitions and trusted queries live as plain SQL, Markdown and Python files, synced to GitHub in the same repository as your dbt project. The agent proposes updates as it learns; only logged-in humans approve and commit them. Security-relevant definitions — which table is the source of truth for customers, which filter excludes internal test accounts — are therefore reviewed in a pull request, not buried in a vendor's database.

Every answer is inspectable, and auditable

Each answer is produced as real SQL and Python in a reactive notebook. You can open any result and read the query that produced it. When someone asks a question through the Slack bot, Querio spins up a real notebook in the app behind the scenes, so chat answers leave the same audit trail as work done in the product — not a message that disappears in a thread. Conversations are private by default and shared explicitly; dashboards are tagged by trust level (trusted, experimental, team-specific) so a governed number is visually distinguishable from an exploratory one. See how audit logs improve data security for why this matters after the fact.

Honest refusals

Querio answers only from what is actually in the data. If the data isn't there — or the user cannot see it — it says so instead of producing a plausible number. A confident wrong answer is a governance incident too, just a quieter one. More on that in stopping your BI tool from making up numbers.

Platform controls

Querio is SOC 2 Type II compliant, runs annual third-party penetration tests, supports HIPAA workloads and signs BAAs, integrates with SSO, and executes generated code in a sandbox. Enterprise deployments can be self-hosted or physically separated for teams whose regulator requires it.

A Worked Example

A brand manager asks in Slack: "What is monthly churn by plan?" The Slack bot opens a real notebook in the app. The agent writes SQL against the live warehouse under that user's permissions and returns a chart. A data lead reviews the logic and approves the churn definition into the context repo on GitHub. From then on, every question, notebook, dashboard and MCP call — including questions asked inside Claude — uses that definition. The result becomes a board and a scheduled report, and an automation watches the metric daily, investigating the root cause when it moves abnormally.

Note what is governed at each step: the connection (read-only, encrypted), the identity (that user's permissions), the definition (reviewed in Git), and the artefact (tagged by trust level). No step depends on the model behaving.

Evaluation Checklist for Any AI BI Tool

Ask vendors these questions in a trial, not in a sales call — and test them with a low-privilege account, not an admin one.

Does the platform connect with one shared credential, or does it pass through per-user identity to the warehouse?
Are row filters applied before aggregation? Verify by comparing a restricted user's total to the unrestricted total.
Can I read the exact SQL behind any answer, including answers delivered in Slack or an AI assistant?
Do permissions apply identically across every surface: app, chat, scheduled report, embedded dashboard, API and MCP?
What happens when a user asks about a table they cannot see — a refusal, or a silently narrower answer?
Where do metric definitions live, who can change them, and is the change reviewable?
Is there an audit record of who asked what, when, and which definition version answered them?
Can the agent write to anything? Read-only credentials should make that structurally impossible.
For embedded or customer-facing use, how is tenant isolation enforced — see row-level security in multi-tenant SaaS analytics.
What is logged when the agent is wrong, and can you reproduce the run?

Designing Policies That Stay Maintainable

Two failure modes account for most RLS pain, and neither is about AI.

The first is policy sprawl: dozens of hand-assigned user-to-row mappings that nobody dares refactor. Prefer attribute-driven policies sourced from your identity provider — department, region, entity — and keep hand-assigned exceptions in a short, documented list. The second is filter columns that fight the physical layout of the table. If sales data is partitioned by region and date, express policies in those same columns; a policy on a derived expression forces full scans and gets blamed on "the AI being slow".

Test policies the way you would test code: a fixture user per role, a fixed set of questions, and a comparison of expected versus actual row counts. Because Querio answers are notebooks, that test suite can literally be a saved notebook you re-run after every policy change. Broader governance context is in data access control and data governance best practices.

FAQ

Does row-level security slow down AI-generated queries?

Enforcement cost is a warehouse question, not an AI question. A policy that filters on a partitioned or clustered column is close to free; one that filters on a computed expression or a wide lookup join can force a scan. Because Querio queries the warehouse live and shows you the SQL, you can profile a slow answer the same way you would profile any query.

Can an AI agent bypass row-level security by writing clever SQL?

Not if the policy is enforced by the warehouse under the asking user's identity: restricted rows are never returned, regardless of how the SQL is written. It can bypass application-level checks, which is exactly why enforcement should not live there.

How does this work when questions are asked inside Claude or another assistant?

Querio's MCP server authenticates with OAuth, so the assistant acts as the signed-in user and inherits their permissions. The Build tier is free to start — 100 questions per month via MCP or API, with no payment details required — so you can test permission inheritance before committing.

Does Querio support HIPAA and SOC 2 requirements?

Querio is SOC 2 Type II compliant, commissions annual third-party penetration tests, supports HIPAA compliance and signs BAAs. Self-hosted and physically separated deployments are available for enterprise requirements. Your own obligations still depend on how you configure warehouse policies and user provisioning.

What does Querio cost?

Starter is $500/month for up to 10 users. Core is $1,999/month, or $1,699/month billed annually, with unlimited users, three data connections and guided onboarding. Enterprise pricing is custom for self-hosting, physical data separation or complex deployments. AI usage is included rather than charged per question, with transparent at-cost overages above the included pool and an optional hard cap. Details are on the pricing page.