Metadata Exposure Surface

A data catalogue is rolled out with every entry readable by every employee. Each table page shows column names, descriptions, row counts, five sample rows refreshed nightly, the top ten queries and the names of the people who ran them. Sensitivity labelling is phase two.

The estate underneath has row-level policies, column masking and purpose-recorded access. None of them apply to the catalogue, because its content is harvested by a privileged service account and served as metadata. Five rows from a table of 200 million rows are not anonymity; they are five people's records, re-sampled nightly, read without an access log entry against the underlying table.

The surface is larger than the samples. A row count on a table named for a medical condition discloses through the count alone, and through the count changing. "Who ran the top queries" on an incident or HR table is a statement about colleagues rather than about data.

Why it matters

This is a control-coverage gap rather than a privacy opinion, which is what makes it arguable in a design review. An organisation that spent two years building row policies and purpose checks installs, in one quarter, a path that reads every table at once and evaluates none of them. An auditor usually finds it first, because the catalogue is drawn as a documentation tool.

The second reason is sequencing. Most rollouts put labelling in phase two, so the catalogue has no basis on which to decide what to show. Default-allow with a labelling backlog is a disclosure with a project plan attached.

Implementation patterns

• Metadata inherits the sensitivity of the data it describes. One sentence, and it reorders the whole rollout: labels become phase one because the catalogue cannot decide anything without them.
• Split the payload by risk. Names, descriptions, owners, freshness and lineage open to all - that part answers does this exist and can I trust it. Values - samples, profiles, min and max, distinct counts - behind a label and a grant.
• Default-deny on unlabelled assets' values, so a table created this morning is not profiled to the whole company tonight.
• Aggregate the usage signal and gate the identities. Popularity ranking stays; the list of named individuals who ran queries becomes visible to the owner only.
• Log metadata reads against the asset, so the catalogue's access history is reviewable beside the warehouse's.

Industry example

Pinterest publishes Querybook as open source: a notebook-style query tool whose discovery features include table documentation, lineage, sample queries, a table's frequent users, and search ranking derived from past query runs. That ranking is what turns an inventory into something people use, because popularity is the only trust signal available before anyone writes documentation. It is also why the usage layer needs its own access rule: the feature that makes a catalogue useful and the feature that discloses colleagues' work are the same feature, so show the aggregate and gate the names.

Failure scenarios

• Sample rows carrying regulated values into a surface with company-wide read, repeated nightly.
• A differencing route through counts on narrow-cohort tables, refreshed often enough to show changes.
• Harvester credentials as the real blast radius: one account with read on everything, whose scope is never reviewed because it is "only metadata".
• Export and API access to the catalogue that bypasses the page-level rules the UI enforces.

Trade-offs

Gating values costs discoverability: an analyst can no longer tell whether a column holds what they need without asking the owner, and that friction is the reason sample rows were switched on in the first place. The honest middle is profiles without values - null rate, distinct count banded, format pattern - which answers most of the real question and discloses nobody's record. The other cost is sequencing: labelling before launch delays the catalogue by a quarter, and a late catalogue is a catalogue people have already stopped waiting for.

When not to use it

Where the data access control it would mirror does not exist, this is premature. In a 30-person company whose analysts can already query every table, the catalogue discloses nothing a query would not, and locking it down produces a tool harder to use than the warehouse - which is how catalogues die. Build metadata controls when row, column or purpose controls are already in force, and in that order.

Interview question

Q: Your catalogue is being rolled out with nightly sample rows on every table and open access for all staff. Argue for keeping the samples, then tell me the minimum you would change before launch and how you would phase the rest.

What a strong answer covers: the samples as the only pre-documentation trust signal · the harvester identity as the actual control gap · default-deny on values with names and lineage open · profiles as the compromise that keeps discoverability · and the review framing - control coverage, not likelihood of harm.

Quick check

Quiz: Why do a catalogue's sample rows escape row-level security? - They are collected by a privileged harvester and served as metadata, so no policy on the source table is evaluated.

Flashcard: Which catalogue fields can stay open to everyone? - Names, descriptions, owners, freshness and lineage; values and querier identities need a label and a grant.