Row-level security (RLS)

Row-level security is a database or semantic-layer feature that attaches a filter to every query automatically. A regional manager querying the sales table sees only rows where `region = 'South'`; a SaaS customer sees only rows where `tenant_id` matches their account. PostgreSQL, SQL Server, Snowflake and BigQuery all support it natively, and BI tools such as Power BI and Looker implement it at the model layer.

For Text-to-SQL it is essential rather than optional. The model writes the query, but it must not be the thing that decides who sees what. If the filter is enforced by the database session or a query rewriter that the model cannot bypass, a prompt injection or a badly phrased question cannot leak another tenant's or another department's rows. This is the analytics counterpart of permission-aware retrieval in RAG.

It is not the same as column masking (hiding a salary column), nor as role-based access to whole tables. RLS works within a table, row by row, and it is enforced where the data lives, not in the prompt.

• CISO: it is the control that makes an AI query interface defensible; the model can be wrong, but it cannot be wrong about permissions.
• CTO / Head of Engineering: enforcing tenancy at the database layer means every future feature inherits it, instead of re-implementing filters in application code.
• Compliance officer: DPDP, GDPR and RBI guidance all expect access to personal and financial data to be limited by need; RLS is how that expectation is evidenced for analytics.
• Product manager: multi-tenant analytics cannot be sold to enterprise buyers without it; the question will come up in the security review.

RLS exists because access control cannot live in the prompt. A language model can be talked into ignoring instructions, and even an honest model can misread a filter. If the same table holds every tenant's or every region's data, the only safe place to enforce who sees what is the database session or a policy layer the model never touches. The trade-off is design effort: policies must be written, tested and kept in step with the org chart, and they can slow queries on very large tables. The alternative, trusting the model to add the right WHERE clause, is not acceptable to any serious buyer.

• A multi-tenant SaaS analytics feature where every AI-generated query is scoped to the caller's tenant by a session variable.
• A bank's branch-performance assistant that lets each branch head see their own book and nothing else.
• A retail franchise dashboard where franchisees query their stores while head office sees the network.
• A university reporting tool that limits a department head to their own students' outcomes.
• A hospital analytics assistant that shows aggregate metrics to administrators but patient-level rows only to treating clinicians.

Technique / practiceA security technique implemented in the database or semantic layer, not a product. Eazyware applies it in every natural language data querying build and in multi-tenant SaaS analytics generally; see also tenant isolation.

Eazyware service that covers it: Natural Language Data Querying. Starting prices are on the pricing page.