An AI analyst that cannot become the leak.

Most data leaks through a second path that applies the rules a little differently. Text-to-SQL straight against the warehouse is exactly that path. Atlas gives the analyst no path of its own: it asks through the same masked views, under the same grants, as everyone else.

The usual pattern

The model writes SQL against raw tables.
Masking lives in the BI tool, not the database, so the model's query skips it.
A keyword filter is the only guard; a quoted identifier walks past it.
Every example question is a paid model call.

Atlas

The model fills a typed spec; the platform compiles it.
Masking and scope live in the database, in the only views the analyst can read.
The database re-checks the compiled query before running it.
Verified questions cost no model call; new ones sit inside a daily budget.

From question to answer

1
Verified questions first
11 reviewed questions answer with no model call at all. They cover most of what analysts ask every week, and they cost nothing.
2
The model writes a spec, not SQL
For a new question, the model picks measures, dimensions and filters from the semantic layer. It never sees a table name and never writes a statement.
3
Validated, then compiled
Every field is checked against the semantic layer. Filter values must be known values, numbers or months, so no free text ever reaches the database.
4
Masked views, view-only role
The compiled query runs as a database role that can read the masked views and nothing else, under the asker's persona and purpose.
5
Logged like any other read
The answer lands in the same hash-chained access log as the access-control screen and the API.

Try it as the partner: ask for cardholder emails. The analyst compiles the request, the database returns nothing because the partner contract grants aggregates only, and the attempt is logged.

Try it as the partner