Hiding a column
is not access control
Most BI permission models control what a report displays. That is a different thing from controlling what data a person can obtain, and the difference shows up in an audit.
The question an auditor actually asks
Not "who can see the salary column on the dashboard". They ask who could obtain salary data in March, by any route, and what evidence you have.
Those are different questions, and most reporting stacks only answer the first.
Where the mask is applied
If the restriction lives in the dashboard, the data still travelled. It reached the reporting layer, it sat in a result set, and the layer chose not to draw it. Every route that bypasses the dashboard bypasses the control with it.
The four routes that bypass a dashboard
Export. A permitted export often carries the underlying result, not the rendered view.
The API. Anything that queries the semantic model or the warehouse directly gets what the query returns, not what the dashboard displays.
A direct connection. Anyone with warehouse credentials is downstream of nothing.
An AI agent. The newest and least controlled. An assistant with a warehouse connection has whatever that connection has, and it does not read your dashboard permissions.
What query-time enforcement means
The policy is applied when the query is built. A masked column is not in the SELECT. A filtered row is not in the result. There is no version of the response that contains the restricted data and then hides it, so there is nothing for an export, an API or an agent to retrieve.
It also means the audit log records something meaningful: the query as executed, against a named identity, with the policy that shaped it.
Why agents make this urgent
Every organisation is currently connecting an assistant to its data. An agent with an unsupervised connection to the warehouse is a compliance incident waiting to be discovered, and the fact that nobody has discovered it yet is not the same as it being safe.
The fix is not a separate AI policy. It is onboarding the agent the way you onboard a person: a named identity, a role, namespaces, column masks it cannot see past, and a record of everything it read.
The honest limitation
Enforcement lives in the layer that builds the query. If somebody connects to the underlying engine directly with their own credentials, they are underneath it.
That is true of every architecture of this shape, and the answer is defence in depth: fine-grained policy and audit in the platform, plus engine-level roles underneath so a direct connection is not wide open. Anyone who tells you their product prevents this without engine-level roles has not thought about it.