Authentication asks who you are. Every enterprise solved that a decade ago.
Authorisation asks what this specific question is allowed to return. Almost nobody solved that.
Where the gap opens
Your identity provider knows the user. Your warehouse knows the tables. Neither knows that this analyst may see EMEA revenue but not the salaries sitting in the same join.
So the gap gets filled with copies:
| Workaround | What goes wrong |
|---|---|
| Duplicate datasets per audience | They drift; nobody knows which is current |
| Parallel views per role | Combinatorial explosion as roles multiply |
| Filters in each BI tool | Re-implemented per tool, inconsistently |
| Post-query redaction | The rows were already read |
Every one of these is a workaround for the same missing capability: authorisation that understands meaning rather than storage.
Attaching authorisation to concepts
Put policy on the entity and the metric — not the table, not the report — and evaluate it when intent is compiled.
- One definition of
Salary, carrying its own restriction everywhere it appears - ABAC attributes (region, cost centre, purpose of use) narrowing rows per caller
- Column predicates suppressing fields at compile time, not in the response
- One governed query path returning a different, correct slice per persona
The property this buys
No shadow copies. When policy lives with meaning, adding a new consumer — a new BI tool, an MCP server, an agent framework — inherits the governance automatically. You stop re-implementing security per surface, which is where most real breaches originate.
And an unauthorised intent fails to compile. Nothing is read, so nothing can leak.
The full breakdown — the authorisation model, ABAC composition, and how predicates are injected — is here:
👉 Data Authorization: Why Security Fails in the Semantic Layer
Originally published at colrows.com/blogs/data-authorization-the-problems-and-the-solution
Top comments (0)