Documentation / Platform glossary / Row-level security
Row-level security is a database capability that restricts which rows a given caller can see or modify, enforced by the database itself rather than by application code. Its defining property is that a query missing the expected filter returns no rows instead of the wrong ones.
Conventionally, access to a shared table is scoped in application code: every query adds a condition restricting results to the current context. Correctness then depends on that condition being present in every query, every report, every background job, and every future change. One omission is a data exposure.
Row-level security moves the restriction into the database. A policy attached to a table is applied automatically to matching statements, so scope is enforced regardless of what the query text says. Application code no longer carries sole responsibility for the boundary.
The security consequence is the direction of failure. Under application-level filtering, forgetting the condition returns more data than intended and the code appears to work. Under row-level security, the same omission returns nothing, which surfaces as an obvious bug in development rather than an exposure in production. Failing closed on omission is the whole point.
Two operational cautions apply generally. Policies must cover reads and writes, or a caller may be able to modify rows it cannot read. And administrative or migration roles frequently bypass such policies by design, which means those roles need separate controls rather than being assumed safe.
Row-level security is how tenant isolation becomes a structural property instead of a coding convention. It also mitigates whole vulnerability classes: an insecure direct object reference is far less exploitable when the database will not return the referenced row to a caller outside its scope.
The assurance it provides is about failure behaviour, which is what makes it meaningful to an evaluator rather than merely a technology choice.
QueryTek enforces tenant scope at the data layer so records cannot cross the tenant boundary through an incorrect query. Public documentation covers the pattern and its failure behaviour; policy definitions, table structures, and role configuration are not published.
