LLM data permissions: enforce access before the prompt

Design permissions for an assistant connected to business data. Apply user authorization, tenant filters and field controls before building LLM context.

NextScenario Finance Data governanceAI

An LLM connected to business data should receive only the information the user and task are authorized to access. Enforce authorization in the application and data-access path before building model context. A prompt that says “do not reveal other companies’ data” cannot replace those controls.

Example: a subsidiary’s gross margin

A director of subsidiary A asks for August gross margin. The application identifies the person, resolves their permissions and authorizes the metric. It derives the subsidiary filter from verified identity instead of blindly accepting a company identifier suggested by the model.

The context can contain the period, currency, revenue, cost of sales and calculated margin. Answering this question does not require customer names, email addresses, postal addresses or complete invoices.

StepDesign control
IdentityAuthenticated user and valid session
AuthorizationPermission for the entity, metric and period
QueryTenant filters and an allowed field list
TransformationAggregates calculated outside the model
ResponseSource, timestamp and scope of the figure

This is an illustrative architecture, not a claim that any product enables these controls by default.

Retrieved content can contain instructions

A retrieved document may contain text that attempts to change an assistant’s behavior. OWASP describes this prompt injection risk. Treat retrieved content as data, enforce permissions outside the model and restrict available tools. Instructions inside a document must never grant additional access.

Test the boundaries before launch

Verify that a user from subsidiary A cannot retrieve B’s results even when explicitly requesting them. Test denied fields, expired sessions, unauthorized queries and documents with malicious instructions. Check caches and exports too: both can disclose data if they ignore user scope.

Decide what to log and for how long. Full prompt logs can retain the very information you intended to minimize. Query identifiers and authorization decisions may be enough for an investigation without storing raw context.

Where the semantic layer fits

A semantic layer supplies consistent definitions; authorization determines who can use them and over which records. The two responsibilities must work together. Read about hashing and data minimization and semantic layers versus warehouses and BI to complete the design.

Next article Semantic layer vs data warehouse vs BI: roles and examples
Book a demo