Does row-level security need PostgreSQL or a database that supports RLS?

No. The policy is enforced by ATX AnalyticsTable itself on DuckDB tables, sheets and exports. External databases keep their own row-level security for the queries sent to them.

Can an administrator see everything?

Only if a rule grants it, or if the installation lists them as a break-glass principal. Being an administrator lets you edit the policy, not read its data.

What happens if the policy has an error?

It is not used. Until it is fixed, its data is unavailable to everyone except administrators, policy owners and break-glass principals, who see it unfiltered so they can repair it.

Can a person with filtered access still build pivots, charts and totals?

Yes. They are computed over the rows and columns that person may see, and pseudonymised columns still group and join.

Does exporting to Excel or CSV bypass the policy?

No. Exports are built from the secured query or the filtered sheet, so a file never holds more than the person could see on screen.

How do I show an auditor how the filter works?

Show what runs displays the exact SQL the server executes for a query, Validate lists each persona's access, and the audit trail records every decision.

Does it slow queries down?

For a restricted person a query costs a few milliseconds more for the rewrite. Projects without a policy pay nothing.

Row- and column-level security (RLS) | ATX AnalyticsTable Docs

Row- and column-level security (RLS)Per-user row filters and column masking for DuckDB tables, sheets and exports — enforced on the server for every query, with preview, explain and audit. ATX AnalyticsTable has its own row-level security (RLS) and column-level security. A data-access policy decides, for each person, which rows of a table or a sheet they see and how each column is shown to them: in full, masked, as a salted pseudonym, empty, or not at all. The backend applies the policy to every query on the project's DuckDB database, to the project file before it reaches the window, and to imports, exports and copies — so a per-user row filter holds for data in DuckDB, in sheets and in every export, not only where an external database such as PostgreSQL enforces row-level security of its own.

Overview

ATX AnalyticsTable has its own row-level security (RLS) and column-level security. A data-access policy decides, for each person, which rows of a table or a sheet they see and how each column is shown to them: in full, masked, as a salted pseudonym, empty, or not at all. The backend applies the policy to every query on the project's DuckDB database, to the project file before it reaches the window, and to imports, exports and copies — so a per-user row filter holds for data in DuckDB, in sheets and in every export, not only where an external database such as PostgreSQL enforces row-level security of its own.
It works for every identity the application knows — people signed in with Microsoft Entra ID, OIDC or SAML, the desktop user, service tokens and unattended scheduled work. A secured table or sheet is closed by default: somebody no rule names sees no rows. Administrators are not exempt unless the installation lists them as break-glass principals, and every decision is written to the tamper-evident audit trail.
Open the data-access policy of the current project: Settings → Settings → Set / Restore → Data access

Row- and column-level security — who sees which rows and columns

A project can carry a data-access policy that decides, for each person, which ROWS of a table or a sheet they see and how each COLUMN is shown to them. It is the product's own row- and column-level security, enforced by the backend for every identity it knows — a person signed in with Microsoft Entra ID, OIDC or SAML, the desktop user, a service token, and unattended work — and it does not depend on the database underneath having row-level security of its own.
A policy names TARGETS: a table or view in the project's DuckDB database, or a sheet of the project. Each target has RULES, and each rule is a grant: these people may see these rows, with these columns shown like this. Somebody no rule names sees no rows at all — a secured target is closed by default — and being an administrator exempts nobody unless the installation lists them as break-glass. WHERE IT IS ENFORCED. Every query on the project database, whoever sends it — the SQL editor, pinned and live results, Find, dashboard and report widgets, pipelines, the AI agent, query-based exports to files, Excel, Parquet and other databases — is rewritten on the server so that a secured table is replaced by only what the person may see.
Aggregates, joins, subqueries, views over the table and SUMMARIZE therefore only ever see the permitted rows. A secured sheet is filtered before the project file leaves the server: withheld rows arrive blank in place, so formulas, styles and references stay aligned, and treated columns arrive masked, pseudonymised or empty. Everything computed in the window — totals, charts, pivots, Find, copy, every export, the agent reading a range — therefore covers only what that person may see.
Results the project file had cached from secured data (pinned blocks, query tabs, formula results, list values) are dropped and re-read through the policy when the project opens. A person the policy restricts cannot save over a secured sheet with their filtered copy, cannot write into a secured table, and cannot get round the policy through the project's files: importing the project file, attaching it to an e-mail, backing up or mirroring the project, reading its Git history, or pointing a DuckDB-file connection at its database are all refused.
Every decision is recorded in the audit trail.

What a restricted person gets, surface by surface

SQL editor, pinned and live query results, Find — The query is rewritten on the server: each secured table is replaced by a filtered subquery with the person's rows and treated columns. Joins, aggregates, subqueries, views and SUMMARIZE only ever see permitted rows.
Dashboards and report widgets — They run their SQL through the same secured path, so totals and charts cover only what the viewer may see.
Pipelines (SQL steps and scripts) — Secured like any other query, under the identity the pipeline runs as.
Ask Greg (the AI agent) — Its SQL goes through the same secured path, and the sheets it reads are already filtered — the model is never given rows the person may not see.
Sheets in the project file — Withheld rows arrive blank in place, so formulas, styles and references stay aligned; treated columns arrive masked, pseudonymised or empty; cached formula results are recalculated over what the person may see.
Exports to files, Excel, Parquet and other databases — Built from the secured query or the filtered sheet, so an export never holds more than the screen does.
Saving — A restricted person cannot overwrite a secured sheet with their filtered copy; the stored sheet is kept and the response says so.
Imports and writes — Importing, materialising or syncing into a secured table is refused for a person it restricts.
The project's own files — Importing the project file, attaching it to an e-mail, backup, mirror, Git history and DuckDB-file connections pointing into the project are refused for a restricted person.

Writing a data-access policy

A project's policy is the file SECURITY/data-access.json in the project folder, edited in Settings → Data access and versioned with the project like its sheets and pipelines. An installation can also push one policy to every machine — data-access.policy.json in the machine-wide configuration folder, or the file named by ANALYTICS_DATA_ACCESS_POLICY — and that one always wins: a project can add protection for objects the installation does not cover, never loosen one it does, and the installation can switch project policies off altogether with allowProjectPolicies: false.
PRINCIPALS say who a rule is for: user:<sign-in name or object id>, group:<group id or name>, role:<Entra app role>, rbac:viewer, rbac:analyst or rbac:admin, service:<token name>, desktop (the person at the keyboard of a desktop installation nobody signed in to), system (unattended work) and * (everyone). A bare value matches a user, group or role with that value, and every comparison ignores case. ROWS is all, none, or a condition on the target's columns — eq, neq, lt, lte, gt, gte, in, notIn, contains, startsWith, isNull and notNull, combined with all, any and not.
A condition compares with literal values or with a USER ATTRIBUTE, such as region in the regions this person holds. Attributes are defined in the policy, each principal holding a list of values; a person holding no value matches nothing. Values are always compared as data and never pasted into SQL. COLUMNS gives a named column a treatment: clear, the value as stored and the default; hash, a salted SHA-256 pseudonym, so counts, joins and grouping still work; mask, four mask characters, optionally keeping the last few characters; null, present but empty; hide, the column is not there and a query naming it fails.
When several rules name the same person they see the UNION, cell by cell: a row is visible when any of their rules lets them see it, and each cell is shown at the most revealing treatment among the rules that match that row. So a rule showing salaries for one department, together with a rule showing every row without salaries, shows salaries for that department only. On a sheet, columns are named by their header text (or C1, C2, …) and headerRow says which row holds the headers; the rows above it are not filtered.
The policy is checked strictly: an unknown field, operator or treatment is an error, and a policy with errors is not used — until it is fixed its data is unavailable to everyone except administrators, owners and break-glass principals. A rule that names a column the target does not have withholds that target's data rather than being ignored. OWNERS name who besides administrators may change the policy, and a saved policy must name at least one. Being an owner grants no data — add a rule for that.

Column treatments — column-level security and data masking

clear — The value as stored (the default) — Columns the person may read
hash — A salted SHA-256 pseudonym — the same input always gives the same pseudonym, so counts, joins and grouping still work — Pseudonymised analysis of traders, customers or counterparties
mask — Mask characters, optionally keeping the last few characters ({ "mask": { "keepLast": 4 } }) — E-mail addresses, account references, phone numbers
null — The column is present but empty — Salaries or commission that a report layout still expects
hide — The column is not there at all; a query naming it fails — National identifiers and other data that must never leave a team

Row conditions

eq, neq — Equal to / not equal to a value or a user attribute
lt, lte, gt, gte — Less than, at most, greater than, at least
in, notIn — One of / none of a list — the usual way to filter by a user attribute such as region
contains, startsWith — Text comparisons
isNull, notNull — The cell is empty / not empty
all, any, not — Combine conditions
Values are always compared as data and never pasted into SQL. A condition on a user attribute matches the values the person holds; a person who holds no value for the attribute matches nothing, so a missing assignment fails closed rather than open.

Example policy

The policy below gives sales the trades of the regions they hold, with commission empty, traders pseudonymised and counterparty e-mails masked; Anna sees EMEA and APAC. On the Salaries sheet, HR sees all staff and the Ops manager sees the rows of their own department. Data owners and the desktop user who built the project see everything.
{ "version": 1, "description": "Sales see their own regions; HR sees all staff.", "owners": ["desktop", "group:bi-data-owners"], "hashSalt": "<a long random value — keep it secret>", "attributes": { "region": { "group:sales-emea": ["EMEA"], "user:anna@example.com": ["EMEA", "APAC"] }, "dept": { "group:managers-ops": ["Ops"] } }, "personas": [ { "id": "emea-sales", "label": "EMEA sales", "groups": ["sales", "sales-emea"] }, { "id": "outsider", "label": "Someone with no grant" } ], "targets": [ { "id": "trades", "kind": "table", "name": "trades", "rules": [ { "id": "sales-by-region", "principals": ["group:sales"], "rows": { "column": "region", "op": "in", "attribute": "region" }, "columns": { "commission": "null", "trader": "hash", "counterparty_email": { "mask": { "keepLast": 4 } } } }, { "id": "owners", "principals": ["desktop", "group:bi-data-owners"], "rows": "all" } ] }, { "id": "salaries-sheet", "kind": "sheet", "sheet": "Salaries", "headerRow": 2, "rules": [ { "id": "hr", "principals": ["group:hr"], "rows": "all" }, { "id": "manager-own-dept", "principals": ["group:managers"], "rows": { "column": "Dept", "op": "eq", "attribute": "dept" } }, { "id": "owners", "principals": ["desktop", "group:bi-data-owners"], "rows": "all" } ] } ] }
Set hashSalt to a long secret value. A pseudonym is only as strong as its salt: without one, a column with few distinct values could be reversed by hashing every candidate. The validator warns about a missing or short salt.

Set up row-level security step by step

1. Open the project and save it, so it has a project folder.
2. Settings → Settings → Set / Restore → Data access. The panel shows whether the project is secured and who the application takes you to be.
3. Click Start from a template, then name your targets: a DuckDB table or view by its name, or a sheet by its name and header row.
4. For each target add rules: the principals (user:, group:, role:, rbac:, service:, desktop, system or *), the rows they may see and the treatment of each sensitive column.
5. Define attributes for row filters that depend on the person — for example the regions each group holds — and add personas, named test identities, for the people you want to check.
6. Click Validate. Errors are listed, and for every persona the panel shows exactly which rows and columns they would get — before anything is saved.
7. Click Save policy. The policy is written to SECURITY/data-access.json in the project folder and applies from the next query. Save and reopen the project to see your sheets through it.
8. Use Preview as to reopen the project as one of the personas, and Show what runs to see the SQL the server executes for a query.

Installation-wide policies

An administrator can push one policy to every machine: data-access.policy.json in the machine-wide configuration folder, or the file named by the ANALYTICS_DATA_ACCESS_POLICY environment variable. The installation policy always wins, object by object — a project can add protection for objects the installation does not cover but never loosen one it does — and allowProjectPolicies: false switches project policies off altogether. Break-glass principals (bypass) can be listed only there, and every bypass is audited.

Checking a policy — preview, show what runs, audit

Settings → Data access shows anyone their own access: who the policy takes them to be, and for every secured table and sheet whether they have full, filtered or no access, which rows they see, how each column is shown, and by which rules. Administrators and owners also get the policy editor. Validate checks a draft and shows, for every PERSONA the policy defines, what that person would see — before anything is saved. Personas are named test identities in the policy: a user name, groups and roles.
Preview as reopens the project exactly as one of them would see it. The server evaluates the policy for the persona INSTEAD of you, never for the two of you combined, and a strip under the ribbon stays until you stop the preview. Saving is turned off while a preview is on, and every preview is recorded. Show what runs takes a query and displays the SQL the server would actually execute for it under the current identity — the answer to an auditor asking how the filter is applied — without running it.
In the audit trail every query run under a policy carries the decision (rewritten, checked, bypass or refused); project loads record which sheets were filtered and how many rows were withheld; protected saves record the sheets that were kept; policy changes record the hash of the file before and after; and every refusal is a dataPolicy.denied record. The test project DataAccess-RLS-Test demonstrates all of this with personas you can preview.

Audit records

A query under a policy — The decision — rewritten, checked, bypass or refused — with the identity that ran it
A project load — Which sheets were filtered and how many rows were withheld
A protected save — The secured sheets that were kept instead of the incoming copy
A policy change — Who changed it and the hash of the file before and after
A preview — That a preview ran, and as which persona
A refusal — A dataPolicy.denied record with the reason

How the filter is enforced

Every query on the project database passes one secured entry point on the server, so a new feature that queries the project is covered by default.
The query is parsed by DuckDB's own parser, each secured table is replaced by a subquery that returns only the permitted rows and treated columns, and the rewritten statement is parsed again and verified before it runs. A rewrite that fails verification is refused, not run.
The subquery is a barrier: a withheld row reads as empty even if the optimiser evaluates the caller's own predicates first, so an error message cannot reveal a withheld value.
Views that read a secured table are inlined and secured the same way, including view chains and views in other schemas.
Statements that cannot be secured — SQL held in a string, direct file reads, table macros, ATTACH, COPY, SET, USE and PRAGMA — are refused for a restricted person.
Before release the enforcement was attacked by an independent review; every confirmed bypass was fixed and is kept as a regression test.

Compared with row-level security in the database

Data covered — Tables in that database, when queries run as the signed-in person — The project's DuckDB tables and views, its sheets, and everything exported from them
Who defines it — The database administrator, in SQL — Project owners and administrators, in one JSON policy per project or per installation
Column masking — Depends on the database — Built in: hide, null, mask and hash
Checking before go-live — Database tooling — Validate per persona, Preview as, Show what runs
Audit — Database logs — The application's tamper-evident audit trail
The two complement each other. Queries to PostgreSQL, SQL Server, Snowflake and other external databases are not rewritten — their own row-level security applies — while data imported into the project is covered by the data-access policy.

Row- and column-level security — what it does not cover

Stated plainly, so that nobody relies on more than is there. On a desktop installation the project's files are on the user's own disk. A policy keeps the application consistent — everyone sees the project through their own access, however they open it in the product — but someone who can open the folder can read the files with other tools. The boundary for confidential data is a server installation, where people do not get the folder, or a folder the operating system already restricts.
External databases are queried as they always were: their own row-level security applies when queries run as the signed-in person through Entra on-behalf-of, and the product's policy covers what is brought into the project — imported tables and sheets. While a policy restricts someone, their SQL is limited to the project's own tables: reading files directly (read_csv, FROM 'file.csv'), running SQL held in a string (query, query_table), table macros, attaching or exporting a database, and statements that change what a name refers to (SET, USE, PRAGMA) are refused, as are statements that write, copy or pivot a secured table.
Get Data still imports files. The catalog stays visible: a restricted person can see that a table or column exists, and table listings estimate its size, but not its values. A hash pseudonym is only as strong as its salt — set hashSalt to a long secret value, or a column with few distinct values can be reversed by hashing every candidate. A secured sheet is filtered when the project opens; pinned blocks on it are not refreshed for a restricted person, and their changes to it are not saved.
Queries under a policy cost a few milliseconds more for the catalog reads and the rewrite; projects without a policy pay nothing.

Common questions

Does row-level security need PostgreSQL or a database that supports RLS? — No. The policy is enforced by ATX AnalyticsTable itself on DuckDB tables, sheets and exports. External databases keep their own row-level security for the queries sent to them.
Can an administrator see everything? — Only if a rule grants it, or if the installation lists them as a break-glass principal. Being an administrator lets you edit the policy, not read its data.
What happens if the policy has an error? — It is not used. Until it is fixed, its data is unavailable to everyone except administrators, policy owners and break-glass principals, who see it unfiltered so they can repair it.
Can a person with filtered access still build pivots, charts and totals? — Yes. They are computed over the rows and columns that person may see, and pseudonymised columns still group and join.
Does exporting to Excel or CSV bypass the policy? — No. Exports are built from the secured query or the filtered sheet, so a file never holds more than the person could see on screen.
How do I show an auditor how the filter works? — Show what runs displays the exact SQL the server executes for a query, Validate lists each persona's access, and the audit trail records every decision.
Does it slow queries down? — For a restricted person a query costs a few milliseconds more for the rewrite. Projects without a policy pay nothing.

Glossary terms on this page

ATX Institute on LinkedIn

This site needs JavaScript for the full experience. Every page above is reachable without it.