An enterprise AI assistant becomes a data-exfiltration system when it retrieves information the user could not access in the source. This can happen even when the model itself is secure. The weakness may be in document ingestion, stale group membership, vector-store filtering, shared caches, citation previews or an agent tool that uses a service account with excessive privilege.
Permission-aware RAG means that access control remains correct throughout the complete answer path. The retriever must enforce the requesting user’s effective rights before content enters the model context. The generator must receive only authorised evidence. Caches, logs and citations must preserve the same boundary.
The core design principle is simple: retrieval must never expand authority. Implementing that principle across enterprise identity and content systems requires a deliberate architecture.
Begin with the source-system security model
Different sources express access differently. A document platform may support users, groups, domains, links, folder inheritance and item-level exceptions. A data warehouse may use roles, row-level security and column masking. A ticketing system may use projects and issue security schemes.
Do not flatten these models into a single “public or private” field. Inventory the permission primitives, inheritance rules, denial semantics, external sharing and update behaviour for each source.
Decide whether the AI system will mirror source permissions, call the source at query time, or expose a deliberately narrower curated collection. It must never silently create a broader model.
Separate authentication, authorisation and retrieval
Authentication establishes who is asking. Authorisation determines what that identity may access. Retrieval finds relevant evidence within that authorised set.
Pass a verified user identity from the application through the orchestration layer. Do not accept a user ID supplied by the browser without validating the session and audience. Resolve groups, roles, tenant and relevant attributes through an authoritative identity service.
Create an authorisation context containing subject identity, tenant, groups, roles, policy attributes and a decision timestamp. Bind it to the retrieval request and audit record.
Choose an enforcement pattern
There are three common patterns.
Pre-filtering limits the vector search to documents and chunks whose ACL metadata permits the user. It is efficient and prevents unauthorised content from becoming a candidate, but requires the index to support robust filters and fresh permission metadata.
Post-filtering retrieves a broader candidate set and then removes unauthorised items. It can work when the vector store has weak filters, but requires over-retrieval and must ensure prohibited content never reaches logs, rerankers or the model.
Source-side retrieval queries the authoritative system using delegated user credentials or a permission-aware enterprise search API. It offers strong permission fidelity but may add latency, rate-limit dependence and inconsistent relevance across sources.
High-risk systems often combine pre-filtering with a final policy decision. Choose based on source capability, data scale, latency and required assurance.
Propagate ACLs during ingestion
For every document, ingest the allow and deny principals, inherited permissions, tenant, classification and sharing state. Store the permission version separately from the content version because access can change without content changing.
Normalise principals into stable identity IDs rather than display names or email aliases. Expand groups at query time or index group IDs depending on scale and change frequency. Pre-expanding every group into users can create enormous metadata and stale access after membership changes.
Record the source permission token or revision. The ingestion ledger should show whether content and permission metadata were both processed successfully. Do not activate a document version when its ACL extraction failed.
Honour group membership and nested groups
Enterprise access frequently depends on nested groups, dynamic groups and role assignments. Build an identity-resolution layer that can calculate effective membership with bounded caching.
Cache membership to meet latency objectives, but define a short validity period for sensitive systems and support revocation events. A user removed from a confidential group should not retain AI access until a daily refresh.
Avoid passing thousands of group IDs directly to a vector query if the platform cannot handle them efficiently. Options include entitlement tokens, materialised access partitions or a dedicated policy service that returns eligible collections.
Preserve tenant isolation structurally
Tenant filtering should not be a best-effort metadata predicate added by application code. Use separate indexes, namespaces, encryption keys or data stores when the risk warrants stronger isolation.
If a shared index is used, make tenant an invariant filter injected by trusted middleware. Do not allow agents or prompt-generated query parameters to choose the tenant.
Test cross-tenant attacks explicitly, including similar document titles, malformed filters, cache collisions and citation URLs.
Enforce before reranking and generation
Many pipelines apply vector search, keyword search, reranking and generation. Unauthorised text can leak at any intermediate stage.
Apply permission filtering before any component that receives document content. If a reranking model operates as an external service, it must receive only authorised candidates and comply with data-handling requirements.
The generator should not be expected to ignore restricted content through a prompt. Once sensitive text enters the context, the control has already failed.
Make caches permission-aware
A cached answer generated for an executive must not be served to a general employee because the question text matches. Include tenant, authorisation context or entitlement fingerprint, source versions and policy version in cache keys.
Prefer caching authorised retrieval results rather than final answers for sensitive domains. Invalidate or age caches aggressively when group memberships, document sharing or classification changes.
Audit cache hits and be able to explain why the cached object was eligible for the current user.
Secure citations and previews
A citation can leak a confidential title, snippet, owner or URL even if the answer body is safe. Generate citations only from authorised evidence and avoid embedding secrets in URLs.
When the user opens a citation, the source should re-authorise the request. Do not use permanently accessible object-storage links. Use the source platform link or a short-lived proxy that verifies identity.
Search suggestions, recent-answer lists and conversation titles require the same review because they may expose derived sensitive information.
Handle conversations and memory
A conversation may outlive a user’s access. If permissions change, old retrieved content can remain in chat history, agent memory or summarisation stores.
Define whether past answers remain visible after revocation. For high-risk data, re-authorise conversation access, redact stored context or set retention limits. Do not automatically place sensitive retrieved text into long-term model memory.
When multiple users share a conversation or workspace, calculate access based on the intersection appropriate to the product policy, not the creator’s privileges.
Control agent tools and service accounts
Agentic systems may query databases, send messages or open documents beyond the RAG index. Prefer delegated user credentials or down-scoped tokens that preserve the user’s authority.
Where a service account is unavoidable, place a policy enforcement point before every tool invocation. Validate resource, action, tenant and purpose. Log the decision and require approval for high-impact operations.
A broad service account combined with prompt-based restrictions is not enterprise authorisation.
Protect logs, traces and evaluation datasets
Observability platforms can become a secondary leak. Avoid logging full prompts, retrieved chunks or model responses by default. Apply redaction and access controls, and separate security audit metadata from sensitive content.
Evaluation datasets built from production conversations require classification, consent and restricted access. Synthetic or curated test data is safer for routine quality checks.
Retain enough provenance to investigate access decisions: user, policy version, source IDs, permission versions, filter applied and decision result.
Test permission correctness continuously
Create a matrix covering allowed, denied, revoked, newly granted, nested group, external user, cross-tenant and link-shared cases.
Automate adversarial tests:
- Ask for a known confidential phrase using direct and indirect wording.
- Attempt prompt injection that requests filter removal.
- Change group membership and verify revocation latency.
- Change a document from shared to private without editing content.
- Test cached queries across users with different entitlements.
- Verify reranking and evaluation services receive only approved content.
- Open citations after access is revoked.
- Attempt access through agent tools and alternate APIs.
Measure false allows separately from false denies. A false deny harms usefulness; a false allow is a security incident.
Design an audit trail that explains decisions
For each answer, record the authenticated subject, tenant, policy version, entitlement fingerprint, source and permission versions, selected chunks and citation targets. Protect this log and avoid storing raw sensitive text unless necessary.
Security teams should be able to reconstruct whether the user had access at the moment of retrieval. Product teams should be able to diagnose false denials without receiving confidential content.
Add alerts for missing ACL metadata, unfiltered vector queries, cross-tenant candidate counts and documents whose permission version is stale.
Apply data minimisation
Permission does not imply that every authorised document should be retrieved. Limit collections by use case, classification and purpose. A general workplace assistant may not need payroll, legal investigation or merger data even for some authorised users.
Use separate assistants or scopes for high-risk domains. Require explicit user action to enter a sensitive context. Apply output controls for personal data, secrets and regulated records.
This reduces blast radius and makes the permission model easier to explain.
Implementation roadmap
First, classify sources and map their access models. Establish verified identity propagation and tenant isolation. Add stable principal IDs and permission versions to ingestion.
Second, implement pre-filtering or source-side retrieval, followed by a final policy check. Make caches, citations and logs permission-aware.
Third, add revocation events, reconciliation and continuous access-control testing. Expand to agent tools only after read-only retrieval controls are proven.
Conduct a threat model before launch and repeat it when new sources, models, tools or sharing features are introduced.
Common failure modes
The most common failure is indexing with a privileged service account and treating all indexed content as generally available. Other failures include stale group expansion, missing ACLs on extracted child objects, post-filtering after content reaches a reranker, shared answer caches and citations with public links.
Another subtle failure is enforcing permissions at the document level while chunks contain content inherited from embedded attachments or merged exports with different rights. Track provenance and permissions at the smallest retrievable unit.
Final recommendation
Make authorisation part of retrieval architecture, not an application-layer patch. Mirror or delegate the source security model, version permissions independently, enforce access before content reaches any model and bind caches and citations to the same decision.
Enterprise AI earns trust when it provides useful answers without changing who is allowed to know what. If the system cannot prove that boundary, it is not ready for confidential enterprise data.
Sources and further reading
NIST AI Risk Management Framework
OWASP Top 10 for Large Language Model Applications
AWS Prescriptive Guidance on RAG
Policy decision service design
A central policy service can evaluate subject, resource, action and contextual attributes consistently across retrieval and agent tools. Keep decisions fast through local policy bundles or bounded caching, but retain a source of truth and revocation path.
Return an allow or deny decision plus policy version and reason code. Do not return sensitive policy detail to the end user. Log the minimal evidence needed for audit and debugging.
Entitlement indexing at scale
For large enterprises, placing every user ID on every chunk is impractical. Index stable groups, roles or entitlement sets and resolve the user’s effective memberships at query time. Where filters have limits, partition high-risk collections or use entitlement-set IDs generated by an authorisation layer.
Measure permission-filter selectivity and latency. A design that is logically correct but requires retrieving thousands of candidates for post-filtering may be too slow and can increase exposure to intermediate systems.
Break-glass and privileged support
Administrative support sometimes requires exceptional access. Implement break-glass as a separate, time-limited workflow with strong authentication, reason capture, approval where feasible and prominent auditing.
Do not let the ordinary assistant inherit support privileges. A privileged session should be visually distinct, narrowly scoped and excluded from reusable caches and training datasets.
Security review evidence pack
Before launch, prepare the data-flow diagram, identity sequence, source permission mapping, cache design, threat model, test matrix, logging policy and incident runbook. Include evidence from cross-tenant, revocation and citation tests.
Repeat the review when adding a source, changing the identity provider, enabling shared conversations or giving an agent a new tool. Each change can introduce a new route around the original enforcement point.
