How to make each person see only their specific data (i.e. their own rows in Genie) with RBAC & ABAC

[Valeria_Koz_DBX]

When rolling Genie out to a UK enterprise Finance department, one of the questions was  "will a cost-centre owner accidentally see another team's numbers?"

In Finance, one leaked row is a bigger problem than a slightly clumsy chart. The good news: you don't secure Genie separately. Genie runs SQL through Unity Catalog, so it inherits whatever access rules you set on the data. The trick is knowing which of the two levers to reach for — and one configuration step that decides whether either of them works at all.

The mental model: RBAC gets you to the table, ABAC gets you to the right rows

• RBAC (role-based) answers who can touch this object at all. You grant a role/group access to a catalog, schema, or table. Coarse-grained, and where you should always start.
• ABAC (attribute-based) answers which rows inside that table this person may see. It's driven by attributes — the user's group or region, and tags on the data — evaluated at query time. Fine-grained, and what actually delivers "each person sees only their rows."

Genie respects both automatically — but only if it runs queries as the viewer, not as the room's creator. That one setting is the whole ballgame.

Step-by-step

1. Step 1: Start with RBAC — grant table access by role. Give the business group access to the objects the Genie room needs, and nothing more.
   GRANT SELECT ON TABLE finance.actuals.cost_centre_spend TO `finance_analysts`;
2. Step 2: Make the Genie space run on-behalf-of the viewer (OBO). This is the make-or-break step. Enable user authorization / identity forwarding so queries execute under the signed-in user's identity. If the space runs as its creator or a single service principal, Unity Catalog only ever sees that one identity — so everyone sees the creator's rows. Configure the space (or backing app) to forward the user's SQL scope rather than running as a fixed principal.
3. Step 3: Model the attributes. Decide what row visibility keys off — usually group membership (RBAC-style) or an entitlement table mapping each user to their cost centres/regions.
   -- who is allowed to see which cost centre
   CREATE TABLE finance.security.cost_centre_acl (user_email STRING, cost_centre STRING);
4.  Step 4: Apply the row filter. Two routes:

             4.1 Classic (UDF-based): a small function that checks the session identity, attached to the table.
CREATE FUNCTION finance.security.cc_filter(cc STRING)
RETURNS BOOLEAN
RETURN is_account_group_member('finance_admins') -- admins see all
OR EXISTS (SELECT 1 FROM finance.security.cost_centre_acl
WHERE user_email = current_user() AND cost_centre = cc);

ALTER TABLE finance.actuals.cost_centre_spend
SET ROW FILTER finance.security.cc_filter ON (cost_centre)

         4.2 ABAC (tag-driven, GA 2026): 

• tag the sensitive column with a governed tag once, then let a single row-filter/column-mask policy apply everywhere that tag appears — far less per-table plumbing at scale. (Confirm the exact policy DDL and any workspace-specific limits in your own environment before rollout.)
  
  5. Step 5: Prefer OAuth over PATs, and viewer credentials over embedded. Personal access tokens and embedded creds quietly bypass per-viewer identity — they're the most common way RLS "silently stops working."
  
  6. Step 6: Test as two personas. Open the room as two different users and ask Genie the same question ("show my cost-centre spend this quarter"). The rows must differ. Cross-check against the audit log that the query ran under the viewer's identity, not the creator's.

(Screenshot placeholder: side-by-side of the same Genie question asked by two users, returning different rows.)

What good looks like (expected outcome)

Two people ask Genie the identical question and each gets only their own rows — with no filtering logic living inside Genie itself. Security stays in Unity Catalog, so it holds no matter how anyone phrases the question, and new tables inherit protection the moment the governed tag is applied.

Common errors (and fixes)

• Room runs as creator/service principal → everyone sees the creator's rows. Fix: enable OBO / viewer identity.
• PAT or embedded credentials in the path → identity doesn't flow, filters don't apply. Fix: OAuth + viewer credentials.
• Filtering in a dashboard/app layer instead of UC → Genie bypasses it entirely. Fix: push the rule down to a row filter/ABAC policy
• Overlapping ABAC policies on the same table/principal → access gets blocked outright. Fix: keep policies non-conflicting and test the matrix.
• Ungoverned tags → ABAC policies won't reliably bind. Fix: use governed tags.

Takeaway: you never secure Genie — you secure the data, and let Genie inherit it. RBAC gets people to the table; ABAC gets them to the right rows; running as the viewer is what makes both real.