Keep the permission boundary outside the model
An enterprise AI assistant is more than a chat interface. A single request may pass through identity verification, document retrieval, a vector database, SQL generation, model inference, and tools connected to an ERP, CRM, or messaging platform. Checking that the user is signed in at the front end leaves every downstream component capable of retrieving too much. A prompt that tells the model not to reveal confidential information is not a security control; the instruction can be misunderstood, and restricted facts can still leak through summaries, citations, or follow-up questions.
The core engineering rule is authorize first, retrieve second, and invoke the model last. Every request should carry a verified identity, tenant, organizational unit, roles, and any required attributes. The retriever applies filters while searching, the database enforces row and column limits, and each tool validates the requested operation again. Retrieving a broad result and asking the model to remove forbidden content is unsafe because the data has already crossed the permission boundary once it enters the model context.
Read access and action permissions must also be separated. Someone who can inspect customer data may not be allowed to update a contact, create a quotation, approve a transaction, or send a message. Define tools as narrow capabilities such as read, create, update, approve, and send. Reauthorize each call on the server using the current identity. High-impact operations should include an explicit confirmation, a human-readable summary of the proposed action, and an audit record after execution.
Use RBAC as the baseline without creating endless roles
RBAC works well for stable, understandable job boundaries. Sales staff may search assigned accounts, finance staff may inspect billing fields, and administrators may configure data sources. Roles should normally be synchronized from the existing identity provider or corporate directory instead of maintained in a separate AI-specific account store that will drift over time. Permission evaluation should default to deny, with a clear rule for whether an explicit denial overrides inherited access.
RBAC becomes difficult when every combination of department, project, region, and sensitivity level produces another role. A more maintainable pattern uses roles to grant baseline capabilities and resource attributes to constrain their scope. During design, make the following distinctions explicit:
- Roles define what a user may do: search a knowledge base, query orders, or invoke a particular tool.
- Attributes define where that capability applies: the user's department, project membership, assigned accounts, or permitted classification.
- Resources carry filterable metadata: tenant, organization, owner, project, sensitivity, and lifecycle state must survive ingestion.
- Membership changes take effect quickly: a transfer, departure, or completed project should not require rebuilding the entire vector index.
- Service identities remain least-privileged: the assistant backend should not depend on one shared credential that can read all enterprise data.
For RAG, preserve the source document's access rules on every derived chunk. If the source platform's access-control list cannot be synchronized directly, create an explicit mapping and define how failures behave. Missing, stale, or unrecognized permission metadata should make a resource unavailable. It should never silently broaden retrieval merely to improve recall.
Mask raw values, semantic clues, and cached results
Masking is not complete when a name or phone number is replaced with asterisks in the final screen. Start by separating three needs: permanently excluding data that should never enter the AI platform, showing different precision by role, and hiding selected fields only in the response. If personal data has no retrieval purpose, remove it before ingestion or indexing. If finance users may see an exact amount while others may see only a category, enforce that distinction in the query layer. Output formatting is appropriate only when the underlying data is already authorized.
Masking rules should be consistent and context-aware. Replacing the same identifier differently on every occurrence prevents the model from connecting related records, while a stable replacement must not become a key that can be reversed into the original identity. Sensitive values may also appear in free text, attachments, headings, and generated summaries. Even if visible text is sanitized later, embeddings, keyword indexes, traces, or model caches created from the original value may retain signals that were never needed.
Caches must participate in authorization. A response cache, retrieval cache, or tool-result cache cannot be keyed only by the question. Its key should include tenant, role set, effective data scope, masking-policy version, and authorization-policy version. Otherwise, an answer produced for a privileged user may be reused for a less privileged one asking the same question. Permission revocation and masking-policy changes also need targeted invalidation for cached answers and indexes, not merely a refreshed user interface.
Treat query scope as a verifiable contract
The backend should construct query scope; the model should not invent it. Vector retrieval can translate tenant, department, project, document type, and sensitivity into mandatory metadata filters. SQL access can use row-level security, controlled views, and explicit column allowlists. External business APIs should receive a short-lived token representing the current user, or sit behind a proxy that injects scope constraints the model cannot override. The model may interpret intent, but it must never expand the caller's authorization.
For every answer, retain a decision trail that is useful without unnecessarily duplicating sensitive content. It can record the user and tenant identifiers, effective roles, applied query scope, matched resource identifiers, masking policy, tool parameters, allow or deny result, and policy version. Citations need authorization checks too: a link the user cannot open should not become visible merely because the model selected it. Audit records are themselves sensitive and require retention rules, access control, and masking.
Pre-production testing should go beyond normal role paths. Include cross-tenant questions, users whose memberships have just changed, documents with identical names, missing metadata, prompt injection, cache reuse, delayed index updates, and denied tool calls. Failure should be closed: return that access is unavailable instead of guessing or falling back to an unfiltered search. When the assistant spans several existing platforms, agreeing on one authorization contract with the engineering and integration teams early is usually easier to operate than adding security rules after the conversational interface is complete.