A data platform must enforce that analysts see only permitted rows and columns across thousands of tables and hundreds of users. How should this be designed so it is enforceable and auditable?

Why per-table grants do not scale

With thousands of tables and hundreds of users, explicit grants produce a permission set nobody can reason about. New tables are created constantly, access is granted ad hoc and never revoked, and the question "what can this person see?" becomes unanswerable — which is both a security failure and an audit failure.

The characteristic symptom: an access review that takes weeks, produces a spreadsheet, and results in nothing being revoked because nobody can determine whether a grant is still needed.

The design that works

Attribute-based rather than identity-based. Access is determined by properties of the data and properties of the user, evaluated at query time:

• Classify the data, at ingestion and as a required attribute: sensitivity level, whether it contains personal data, its subject area, its jurisdiction. Unclassified data should default to restricted, or classification never happens.
• Attribute the user: role, team, region, clearance, purpose of access.
• Express policy over attributes: "analysts may read data classified internal in their own region; personal data requires an additional approval; financial data requires membership of the finance group."
• Enforce centrally, in the platform, so the policy applies identically to every access path — a policy enforced by the BI tool and not by the query engine is not enforced, since the notebook bypasses it.

Row filters applied automatically from user attributes; column masking for sensitive fields, so the column remains queryable in aggregate while individual values are hidden — which is what allows analysis to proceed without the underlying data.

Making it auditable

• Policy as code, version-controlled and reviewed, so a change is a diff with an author.
• The effective-access question answerable programmatically: "what can this person see?" and "who can see this table?" — both must be computable, and in a grant-based system neither is.
• Access logged with the policy decision, not just the query, so a review can establish why access was permitted.
• Automatic expiry on exceptional grants, since a temporary grant with no expiry is permanent.
• Periodic recertification driven by attributes rather than by grants, which makes review a question about roles rather than about thousands of individual permissions.

The practical failure modes

• Unclassified data defaulting to open, which makes the whole scheme decorative.
• Policy enforced in one tool, bypassed by every other.
• Derived tables losing classification, so a restricted column copied into an aggregate table becomes unrestricted — the most common leak, and it requires classification to propagate through lineage.
• Masking that is reversible in aggregate: a masked identifier that can be re-identified by joining on other columns, which is a genuine and frequently-overlooked risk.
• Exceptions accumulating until the exceptions are the policy.
• Performance impact from row filters on large tables, which drives people to request unfiltered copies — and an unfiltered copy is the failure of the entire control.