Point a hundred people at one Genie Agent over one sensitive book of business, and the compliance question lands immediately. Does the analyst see only their region while the auditor sees all of it, or does a shared agent mean shared sight? The instinct is to build one agent per sensitivity tier to keep the data apart. That instinct is usually wrong, and seeing why changes the whole design.
The part that trips everyone up
A Genie Agent runs on a SQL warehouse, and the docs are explicit: the author's compute credentials are embedded and used to process every query for every user. Read that once and you assume everyone sees what the author sees. They do not. Compute identity and data identity are two separate things. The embedded credential runs the warehouse. Each end user's own data credentials are still applied to the query, so a user only sees data they are entitled to, and a question about data they cannot reach returns an empty answer. One agent, one warehouse, a hundred users, a hundred different result sets.
Where the entitlement actually lives
Not in the agent. In Unity Catalog. This is the sentence to keep: the Genie Agent is not the security boundary. Unity Catalog is. Two consequences most teams miss.
Removing a table from an agent is not an access control. Genie can query tables beyond the ones you added when a user has the Unity Catalog permission and prompts for a join or edits the SQL. The agent's table list curates what Genie reaches for by default. It walls nothing off.
Per-user separation inside one shared agent comes from row filters and column masks on the underlying tables. They are enforced at query time, per user, automatically, regardless of how the agent is shared. Define them once on the table and every surface that touches it, Genie, a dashboard, a notebook, inherits the same rule.
So the design flips
You do not need one agent per tier to keep data apart. Run one well-scoped agent over governed tables and let Unity Catalog do the separating. Fewer agents to maintain, and one place to prove the control when someone asks you to.
The answer that scales: ABAC
Row filters applied table by table get unwieldy across dozens of tables. ABAC policies attach at the catalog or schema level and apply by governed tag, so a new table tagged as sensitive is covered the moment it lands, and a table owner cannot quietly strip the policy off. For a growing estate that is the line between a control you assert by hand and a control you can attest to.
What a consumer actually needs
Less than people tend to grant. SELECT on the underlying Unity Catalog objects, the consumer or Databricks SQL entitlement, and CAN VIEW or CAN RUN on the agent. They do not need warehouse permissions, because queries run on the embedded compute credential. Lacking SELECT on a table does not throw an error that betrays the table exists. It returns nothing.
Two gotchas before you trust it in production
Turn ANSI mode on. A row filter is a SQL function, and if its parameter type does not match the column (a STRING column passed to an INT parameter, say) then with ANSI mode off the value silently casts to NULL. A filter written to allow NULL rows will then return every row instead of none. The control fails open and stays quiet about it. With ANSI mode on the cast throws and you catch the bug at once. A security control should fail loud.
Know what feeds the shared context. Prompt matching samples representative values from a column so Genie can map "Florida" to "FL". Those samples are generated with the author's permissions and become part of the agent's shared context. Databricks excludes tables carrying row filters or column masks from prompt matching for exactly this reason, so the protection is there, but know the boundary rather than assume every value is scoped per user.
Where filters and masks stop being enough
They govern which rows and which fields a permitted user sees. They do not stop a permitted user from asking a question you would rather they did not, and they do not decide what counts as sensitive in the first place. Unity Catalog enforces access. Classifying the data and deciding the policy is still human stewardship, and no filter substitutes for it.
A one-line test for your setup
If you cannot answer "prove that user A and user B, in the same agent, saw different data, and show me the control that made it happen" with a Unity Catalog row filter or an ABAC policy, then what you have is curation where you needed governance.
Sources