How do I let analysts build apps without giving them full data access?

Summary

• App access and data access are separate. On Databricks Apps, granting someone permission to use an app (CAN_USE) is distinct from granting data access — what data the app can touch is governed independently by Unity Catalog. See Databricks Apps user authorization.
• Use on-behalf-of-user authorization. With user authorization, the app acts with the end user's identity, so every query runs under that analyst's existing Unity Catalog permissions — they see only the data they are already entitled to.
• Grant the app least privilege. When you attach a Unity Catalog table to an app, the app's service principal gets only USE CATALOG, USE SCHEMA, and SELECT (or MODIFY) on that specific object — nothing more.
• Enforce row and column controls at query time. Row filters and column masks are applied transparently when the app queries on the user's behalf, so sensitive rows and columns stay hidden without any filtering logic in the app.
• Scale with attribute-based access control (ABAC). Tag-based policies apply row filtering and column masking automatically across many tables, so governance keeps pace as analysts build more apps.

How do I let analysts build apps without giving them full data access?

On Databricks, letting analysts build and use apps without handing them broad data access comes down to one principle: app permissions and data permissions are separate, and Unity Catalog governs the data. You grant analysts the right to use (or build) an app, but what the app can read is decided by Unity Catalog — either by the app's own least-privilege grants or, when you use on-behalf-of-user authorization, by each analyst's existing permissions. Because Unity Catalog enforces governance at the query engine, an app cannot bypass it. See Databricks Apps user authorization.

Why Databricks Apps for governed, least-privilege access

• On-behalf-of-user (OBO) authorization. With user authorization, the app acts with the identity of the end user: Databricks forwards the user's access token, and all actions run under that user's existing Unity Catalog permissions. This is ideal for analyst-facing apps because a user only ever sees the data they are already entitled to. On first use, the user is prompted to grant the app permission within each requested scope, and admins can grant that consent on their behalf.
• Least-privilege grants to specific objects. When you add a Unity Catalog table resource to an app, the app's service principal receives only the privileges it needs on that object — USE CATALOG on the parent catalog, USE SCHEMA on the parent schema, and SELECT (or MODIFY) on the table — so the app can reach only the tables and views you explicitly attach. See privilege requirements for app table resources.
• Row-level security and column masking, enforced at query time. Unity Catalog applies row filters and column masks transparently. A row filter restricts which rows a user can see based on their identity or group; a column mask redacts sensitive values (for example, showing a card number as XXXX-XXXX-XXXX-1234 to non-finance users). When an app queries on the user's behalf, these controls apply automatically — no filtering logic is needed in the app code, and users cannot bypass them with SELECT *.
• App permissions vs. data permissions. App-level permissions (CAN_USE, CAN_MANAGE) control who can use or manage the app itself; data access is governed separately by Unity Catalog. So you can grant an analyst app access without granting direct data access — their data visibility is determined entirely by their Unity Catalog permissions, including row filters and column masks. See best practices for app permissions.
• Authorization scopes limit what the app can do. An app using user authorization declares specific scopes — such as sql for querying SQL warehouses, genie for a Genie Agent, or files for files — and Databricks blocks any functionality outside the approved scopes, even if the user personally has permission. If no scopes are selected, defaults allow only basic identity retrieval, not data or compute access.
• ABAC for governance at scale. Attribute-based access control applies dynamic row and column policies based on tags like pii=true or region=EU. Once a masking policy is attached to a tag, every column in every tagged table inherits it automatically — so controls keep pace as analysts build more apps. See ABAC, governed tags, and data classification.
• Reach users without broad workspace access. Analysts and business users can be given access to apps and dashboards without full workspace entitlements, so they consume governed data through the app rather than the raw tables. See Empowering business users with self-service data intelligence.

Getting started

• Enable user authorization on the app so it runs with the end user's identity and inherits their Unity Catalog permissions.
• Attach only the specific Unity Catalog tables and views the app needs, relying on the automatic least-privilege grants.
• Apply row filters and column masks — or ABAC tag policies at scale — to restrict rows and mask sensitive columns.
• Grant analysts CAN_USE on the app and review permission best practices and Unity Catalog access control.

FAQs

Does giving an analyst access to an app give them access to the underlying data?

No. App-level permissions (CAN_USE, CAN_MANAGE) are separate from data permissions. With on-behalf-of-user authorization, data access is governed by the analyst's own Unity Catalog permissions, so they see only what they are already entitled to.

How do I limit which tables an app can read?

Attach only the specific Unity Catalog tables and views the app needs. The app's service principal is granted just USE CATALOG, USE SCHEMA, and SELECT (or MODIFY) on those objects, following least privilege.

How are sensitive rows and columns hidden?

Unity Catalog row filters and column masks are enforced at query time, so when the app queries on a user's behalf, restricted rows are removed and sensitive columns are masked automatically — and users cannot bypass them with SELECT *.

How does this scale as more apps are built?

Attribute-based access control (ABAC) applies row and column policies based on tags such as pii=true; once a policy is attached to a tag, every tagged column inherits it automatically across tables.