How do I stop AI from showing users data they shouldn't see?

Summary

• Genie Ontology and AI features respect Unity Catalog's four-layer access control: Genie Agent membership, Unity Catalog grants (USE CATALOG, USE SCHEMA, SELECT), row filters (per-row access based on user identity), and column masks (value transformation or redaction). All four layers must pass for data to return.
• Row filters restrict which rows a user can see based on their identity (e.g., region-based access), while column masks transform or hide sensitive values like PII or compensation data. Both are enforced at query time; Genie runs queries as the user (on-behalf-of).
• Attribute-based access control (ABAC) applies governed tags to enforce policies at scale: a single policy tied to a sensitivity tag applies everywhere that tag appears, so you don't need to maintain per-table restrictions.
• Silent enforcement means restricted data returns fewer rows or NULL values, with no errors or indication of what users aren't authorized to see. This prevents users from inferring what's restricted.
• Best practices: grant each user group minimum necessary data access, use curated views to constrain the queryable surface, verify row filters with DESCRIBE TABLE EXTENDED, and ensure filters include ELSE FALSE to prevent unintended exposure.

How do I stop AI from showing users data they shouldn't see?

AI agents and conversational interfaces like Genie must respect data governance just like any other interface. The mechanism is permission-aware context retrieval: the AI only surfaces content users are already authorized to access, enforced through Unity Catalog's row filters, column masks, and role-based access control. When a user asks a question, the AI runs queries under their identity, so all existing access controls apply. Unauthorized rows are silently filtered, sensitive columns return NULL or transformed values, and the user sees only what they're entitled to see.

Four-layer access control for AI

Genie and AI features inherit Unity Catalog's comprehensive governance:

Layer	Control	Effect
1	Genie Agent or feature membership	User must be added to the agent; grants ability to ask questions
2	UC grants (USE CATALOG, USE SCHEMA, SELECT)	User must have SELECT on tables they want queried
3	Row filters	Only rows matching the filter condition are visible (e.g., current_user in allowlist)
4	Column masks	Sensitive columns return NULL, hashed, or redacted values

All four layers must pass. If any layer denies access, the data does not appear in the AI response.

Row filters and column masking

When Genie generates and executes a SQL query, it runs as the logged-in user (on-behalf-of). Unity Catalog enforces row filters and column masks at query execution time, so restricted data cannot leak. Row filters restrict which rows a user can see: a region filter ensures a salesperson only sees deals in their territory. Column masks redact sensitive values: a compensation column might return NULL for non-HR users, or PII columns might be hashed. Both are applied silently: no error is raised, no indication that data was restricted. Fewer rows and NULL values simply appear in the response.

Attribute-based access control at scale

For sensitive datasets requiring fine-grained protections, attribute-based access control (ABAC) drives row and column policies from governed tags. Instead of defining restrictions table by table, you tag tables and columns with sensitivity levels (e.g., pii, hr-only). A single policy tied to that tag then applies everywhere the tag appears. This scales governance across a large data estate: you update one policy and it propagates to all tagged assets automatically.

Implementation best practices

Grant minimum necessary access: Each user or group should have the minimum data access they need. Avoid blanket SELECT grants; restrict instead to specific schemas or curated views.
Use curated views: Build views that filter or transform data appropriately (e.g., a sales view that excludes cost columns). Grant SELECT on the view rather than the base table.
Verify row filters: Use DESCRIBE TABLE EXTENDED to inspect active row filters on a table and confirm they're configured correctly.
Include ELSE FALSE: Row filter expressions should end with ELSE FALSE to deny access if the condition doesn't match, preventing accidental exposure.
Test identity propagation: In on-behalf-of execution, verify that identity functions like current_user() resolve correctly. Note: is_member() evaluates the SQL execution identity, not the calling user; use current_user() combined with an allowlist table for reliable group-based filtering.

Use cases

Multi-tenant SaaS: Each customer's account has access to only their own data. Row filters keyed on current_user() and an account membership table ensure a customer's AI only sees their data, even if they somehow access the shared Genie Agent.
Region-based sales analysis: A salesperson asks "what are my top opportunities?" Row filters restrict the result to their region. The AI surfaces only records matching their assigned territory.
Sensitive HR data: HR analytics tables are tagged hr-only. A column-mask policy redacts salary and bonus columns for non-HR users. When non-HR asks an AI question, salary data never appears in context or responses.

FAQs

Can a user infer what they're not authorized to see?

No. Row filters return fewer rows and column masks return NULL values silently. No error is raised, and no indication is given that data was restricted. The user sees a complete, valid response that's simply filtered to their permissions.

If I add row filters after data is already in production, do existing queries automatically respect them?

Yes. Row filters are enforced at query time by Unity Catalog. New row filters apply immediately to all new queries, even retroactively to existing AI conversations.

What happens if the AI asks about data the user isn't authorized to see?

The generated SQL query executes under the user's identity. If the user isn't authorized, the query returns no rows or NULL columns. The AI can only infer from what's actually returned, so unauthorized data never influences the response.

Does ABAC work with AI and Genie?

Yes. Policies attached to governed tags apply to all access methods, including AI. Tag a table as customer-pii, attach a column-mask policy, and the mask applies to Genie queries just as it does to SQL or BI tools.

Can I use row filters to hide entire tables?

Row filters hide rows within a table, not the table itself. To hide a table entirely, deny SELECT access via Unity Catalog grants. To hide it from one user group but not another, use separate schemas and grant access accordingly.