Most enterprises secure the dashboard and leave the query wide open.
By the time your access filter fires, the data has already left the warehouse.
Why tool-level controls don't travel
Row and column rules bolted onto a BI tool protect exactly one surface. The moment an AI agent reaches the same warehouse through a different door — an MCP server, a notebook, a REST call — those rules don't come with it.
So teams do what's available: duplicate datasets per audience, maintain parallel views, and accept that the copies drift.
Attach policy to meaning, not storage
| Tool-level ACLs | Compile-time predicates | |
|---|---|---|
| Attached to | Reports, folders, views | Entities, metrics, relationships |
| Travels to new consumers | No — re-implement per tool | Yes — it's part of the concept |
| Unauthorised request | Filtered result | Fails to compile |
| Rows read | Then hidden | Never read |
| Audit artefact | Access log | The SQL, with predicates inline |
The third row is the security boundary. "Filtered afterwards" means the query ran with full privileges and something downstream decided what you were allowed to see.
What precision looks like in practice
RBAC gets you role membership. ABAC adds attributes — region, cost centre, clearance, purpose of use. Row and column predicates then narrow the actual result at compile time, per person, per question.
One governed query path serves every persona and returns a different, correct slice to each. No shadow copies to reconcile, and no separate governance implementation per tool.
That's the difference between preventing a breach and documenting one.
The full breakdown — the policy model, how RBAC and ABAC compose, and the predicate injection mechanics — is here:
👉 Fine-Grained Data Access Control: Precision & Security
Originally published at colrows.com/blogs/fine-grained-data-access-control-precision-security
Top comments (0)