The access a governance layer needs is narrow, specific and worth naming precisely. What gets read from a catalogue, what read only means when it is structural, not promised, why your own warehouse role stays the boundary, and what inheriting a catalogue buys you.
Updated · 6 min read
The first question in any review is what the thing actually touches. The answer is short enough to read aloud in the meeting.
Every item on that list is metadata. It is your catalogue, your vocabulary and your permissions, which together are the material a governance report is made of. Row data is a separate ask with a separate answer, and it is covered by the governed query path, not the sync.
A good question to put to any tool asking for warehouse access: ask what it keeps. Here the audit keeps the shape of a result, which is the row count, and none of the cells.
There are two ways for software to be read only, and they are nowhere near equivalent.
The weak way is a promise. The code is fully capable of writing and undertakes not to, upheld by a review comment that a future contributor will never read. The strong way is structural: the connector classes expose a connection test and an introspection, and there is no write method to guard because none was ever written. The guarantee survives a refactor by somebody who has not heard of it.
A second leg runs alongside the catalogue APIs, and it is worth knowing why it is there. Some of the governance you want lives in the account’s own information schema and system views, not the REST catalogue. Reading ownership tags and key constraints means running statements. Those statements are reads, they are bounded, and they are the reason a compute endpoint appears on the connection form at all.
Access is inherited and never widened. You supply a credential, every read runs as that principal, and the horizon of the report is the horizon of the role. Whatever the credential cannot reach stays out of reach.
Three consequences, all of them practical.
The value of this in a review is that it changes the question being asked. What a tool does with your data is hard to answer and easy to distrust. What you granted it is a question your own team already owns, in a system they already run, with an audit they already read.
A connection form that accepts any host at all is a request-forgery surface with a friendly label on it. A warehouse host has to match one of the vendors’ real hostname suffixes before anything leaves the process, and private, loopback, link-local and cloud metadata addresses are turned away at the same gate.
The practical effect is that a typo produces an operator message naming the host, not a request into your own network that half succeeds and is never explained.
The credential itself is encrypted at rest and is never echoed back. What the console renders for a configured connection is filtered by the field specification’s own secret flag, not a list somebody maintains by hand. A token cannot reach a page even when it is stored one field away from something that does. What you see is the host, the role, the warehouse, the database, and which kind of credential authenticated.
That last item earns its place. A connection that falls back from one credential kind to another without saying so can go unnoticed and unrepaired. Which one answered is recorded and shown.
Inheriting a catalogue and restating one read almost the same on a feature list and behave nothing alike after six months.
Restating asks somebody to retype owners, classifications and descriptions into a second system. From the day that work finishes there are two records of the same fact, and one of them is ageing. Inheriting means the first sync reads what your platform already holds: tables, columns, comments, tags, keys and grants, none of it re-keyed by anyone.
It is also why the permission ask stays small. A tool that inherits needs reads. A tool that expects you to curate inside it needs somewhere to write, somewhere to store, and an argument for why its copy is the one you should trust.
Naming conventions are treated as enrichment on top of what arrived, not as a requirement. A warehouse matching none of the expected patterns still ingests fully. The layer name is read from the object’s own qualified label, and the vocabulary is open, so a layer name nobody taught the tool arrives intact instead of collapsing into unknown.
Some governance reads need a grant that plenty of accounts have never made. Reading tag references on one platform requires a privilege on the account’s own shared database, and that data lags by a couple of hours even once it is granted.
Where the grant is absent the read is best effort: it returns what it could and reports what it could not. The distinction is the entire point. A tool reporting zero documented owners when it means it was unable to read the owner tags has told you something false about your own documentation, you will act on it, and the work will be wasted.
A blank column and a column that could not be read look identical on screen and mean opposite things. One is a documentation gap on your side. The other is a grant gap on the connection.
The same discipline runs through the rest of the product. A lineage map names what completed its grain. An empty layer scores zero, not a flattering hundred. A first sync that comes back thin is showing you your coverage or it is showing you your grants, and the report is expected to say which of the two it is.
A short list to take to whoever owns your warehouse.
Ask for the smallest set that answers your first question, run a sync, then read what came back empty. Granting against evidence is a far better conversation than arriving with a list, and it leaves your warehouse team holding the boundary, which is exactly where it belongs.
A semantic layer gives a metric one home. Each tool that works out the metric reads that one home. They all get the same number. Here is what that means in practice, and what changes when you run more than one warehouse.
A metric contract is what a semantic layer looks like once something is actually enforcing it. How a definition gets pinned, what happens to a question naming fields from two warehouses, and why the identifiers reaching the SQL come from the contract itself.
Two Tableau credentials doing two different jobs. One carries a person’s permissions. The other extends a platform capability. Picking the right one keeps a permission model you spent years building in charge of who sees what.