The model is not a safe place to enforce permission
Asking a model to 'only answer questions the user is allowed to see' is a prompt-level instruction, not an access control — a sufficiently creative or malformed query can bypass it, and the model has no reliable way to independently verify what any given user is actually entitled to see.
Permission enforcement belongs in the data layer the generated query actually executes against, not in the instructions given to the model generating that query.
Row- and column-level security as the real control
Modern lakehouse query engines support row-level and column-level security policies tied to the authenticated user's identity, enforced regardless of how the query was generated — by a human analyst, a BI tool, or an LLM-generated SQL statement.
This is the design point that matters: the natural-language layer should be a convenience on top of an access-controlled query engine, never a path that executes with broader permission than the user who asked the question actually holds.
Testing it like a security control, not a feature
Before launch, test the system the way you'd test any access control: attempt to retrieve data outside the test user's permission through creative phrasing, indirect references and multi-step questions, not just the intended happy-path queries.
Treat a successful permission bypass here with the same severity as any other access-control finding — because functionally, that is exactly what it is.
A model that answers nicely is not the same as a model that answered only what the user was allowed to see.MNB Data Practice
Key actions
- Enforce row/column security at the query engine, not in the prompt
- Never let generated queries execute with broader permission than the requesting user
- Red-team the natural-language interface for permission bypass before launch
- Log generated queries for the same audit trail as any other data access