How can I let engineering and business teams query the same governed data without duplicating access controls?

Summary

• The reliable fix is architectural: keep one copy of each dataset and one set of access policies in a shared governance layer that every query engine reads through, so analysts and engineers hit the same tables with the same rules applied automatically.
• In Databricks, Unity Catalog is that layer. You define row filters, column masks, and grants once, and they're enforced in the SQL engine for every workload, so nothing bypasses them and no team needs a private copy.
• Attribute-based access control (ABAC) lets you tag a table once, and the matching masks and filters apply to it and to every future table with that tag, with no per-object setup.
• Governing one copy instead of many removes the duplicate pipelines and per-audience table copies that cause policies to drift out of sync and audits to fragment.

How can I let engineering and business teams query the same governed data without duplicating access controls?

Stop giving each team its own copy of the data. The durable answer is a single governance layer over one physical copy of each dataset that applies the same policies to every engine that reads it. When access rules live with the data instead of inside each tool or pipeline, a business analyst running a dashboard and an engineer running a Spark job query the identical table and automatically get the identical row filters and column masks. You grant an entitlement once, and every workload inherits it.

Why teams end up duplicating access controls

Duplication is usually a workaround. When a warehouse governs one way and a data lake or BI tool governs another, teams copy data into each system and re-implement permissions in each place. Every copy is a new surface to secure and a new chance for policies to fall out of sync, so the same person can see masked data in one tool and raw values in another. Consolidating on one governed copy removes the reason to duplicate.

Key capabilities to evaluate

Capability	Why it matters
Single permission model	One place to define who can see what, applied to every engine. Removes per-tool copies of data and rules.
Query-time enforcement	Policies fire in the query engine, not the application, so no tool or API path can route around them.
Row and column security	Row filters and column masks restrict data by user attributes without forking the table.
Tag-based (attribute) policies	Define a rule against a tag once; it applies to every current and future table with that tag.
Unified audit and lineage	One record of who accessed what across BI, engineering, and AI, so access reviews use a single source.
Open, multi-engine reads	Outside engines read the same governed tables through open standards, so governance travels with the data.

How Databricks approaches unified, governed access

Databricks centers this on Unity Catalog, the single authorization layer for the platform. Its guiding rule is "define once, secure everywhere." Every workload resolves access through the same metastore against the same policies: SQL warehouses for BI and analytics, notebooks and clusters for engineering, AI/BI dashboards, and AI features like Genie Agents and Agent Bricks. There's one copy of the data and one permission model, so you don't maintain separate governed tables per audience.
Fine-grained controls use standard SQL. A column mask function transforms sensitive values for users who aren't authorized, and a row filter function injects a transparent WHERE clause so a query returns only the rows a user may see. Because enforcement happens in the engine, an application can't get around it. Attribute-based access control (ABAC) goes further: attach a policy to a governed tag, and it applies automatically to every table with that tag, including tables created later, turning re-granting on each new table into a one-time rule.
The catalog hierarchy (catalog, schema, table) maps to business domains, so a central team sets broad policy while domain teams own their data under it. Access is granted with ordinary GRANT statements or the REST API, and all access lands in one audit trail alongside lineage. Governance also reaches outside engines: through open Apache Iceberg REST catalog APIs, external tools read the same tables with server-side filtering applied. See the Unity Catalog documentation, the access control guide, and the blog on unified governance.

Use cases

Regulated industries: A central team masks account numbers and health identifiers with one column-mask policy; analysts approved for a region see their rows and everyone else sees filtered results, whether through a dashboard or a notebook.
Self-service analytics: Business teams query curated tables in SQL warehouses while engineering builds pipelines on the same tables, and both see the same governed values with no private copies.
Data mesh by domain: Each domain owns a schema and manages grants for its own tables, while enterprise policies such as tag-based masks apply across all domains automatically.

FAQs

Do analysts and engineers need separate copies of the data to enforce different access?

No. Row filters and column masks change what each user sees from the same physical table, so you keep one copy and let policies differentiate access at query time.

Where are the access rules enforced?

In the query engine, during execution. Because enforcement sits below the application layer, no BI tool, notebook, or API can bypass a row filter or column mask.

What is attribute-based access control (ABAC) here?

It's tag-driven governance. You define a mask or filter against a governed tag once, and Unity Catalog applies it to every table with that tag, including new tables, so you don't reconfigure policies object by object.

Can tools outside Databricks read the same governed data?

Yes. Through open Apache Iceberg REST catalog APIs, external engines read the same tables with governance applied server-side, so you don't re-implement permissions in each system.