Permission-safe Retrieval-Augmented Generation (RAG) in enterprise information…

Research Question

What are the technical constraints on permission-safe Retrieval-Augmented Generation (RAG) in an enterprise information architecture with incoherent access controls, collaboration groups created ad hoc, document-store Access Control Lists (ACLs) unaudited, file-level sharing at individual discretion, and what are the architectural options (per-user token delegation, per-security-boundary index partitioning, ACL metadata filtering) with their respective failure modes at enterprise scale, including the embedding inference problem and the permission-change propagation problem?

Findings

(Populated from §6 Synthesis above.)

Executive Summary

• An incoherent permission estate is a technical blocker for permission-safe Retrieval-Augmented Generation (RAG), because every reviewed architecture needs permissions to be either represented correctly as retrieval metadata or evaluated live at query time, and ad hoc enterprise sharing defeats both requirements.

• Query-time ACL filtering is necessary but not sufficient for permission safety, because published work shows that dense embeddings and RAG retrieval databases can leak source information or document membership through inversion and black-box interaction.

• For Microsoft 365 and SharePoint estates with broken inheritance and unsupported principal types, live delegated retrieval is safer than copied ACL indexing because it preserves source governance and avoids stale-permission windows that copied-index architectures must manage explicitly.

• Per-security-boundary partitioning and ACL metadata filtering remain useful only after the permission model has been rationalized into stable, auditable boundaries; before that point they reproduce the underlying incoherence rather than containing it.

Key Findings

1. [high]An enterprise with incoherent document permissions cannot operate permission-safe RAG, because the reviewed platforms only enforce the permission representation they are given, and none can infer a correct allow-set from ad hoc, unsupported, or unknown sharing state.
2. [high]Dense text embeddings are not intrinsically permission-safe artifacts, because published inversion work shows exact or high-fidelity recovery of source text and sensitive attributes from embeddings, including attacks that do not require direct access to the victim embedding model.
3. [high]RAG systems can leak whether a document exists in the retrieval database through Membership Inference Attacks, so the vector store and retrieval corpus must be treated as sensitive assets rather than as harmless indexes.
4. [medium]Per-user token delegation or live source retrieval is the safest architecture for complex Microsoft 365 estates because it keeps authorization in the source-of-truth system and largely eliminates copied-permission propagation lag.
5. [medium]Copied ACL indexing over SharePoint is fragile when inheritance is frequently broken or when unsupported principal types are common, because the copied model only partially reproduces SharePoint's real permission semantics and can serve stale ACLs until explicit refresh occurs.
6. [medium]Per-security-boundary partitioning is appropriate only when security domains are coarse and stable, because it reduces within-index leakage risk but duplicates ingestion, embedding, synchronization, and operational control planes as boundary count increases.
7. [medium]AWS Bedrock Knowledge Bases currently implement secure retrieval through application-managed metadata filters rather than documented live source authorization at query time, so access correctness depends on external identity validation and timely metadata synchronization.
8. [high]Permission-change propagation is a first-order failure mode in copied-index architectures, because Azure copied ACLs require explicit reindex or resync after source permission changes and Bedrock copied metadata requires source updates plus knowledge-base synchronization before changed permissions can take effect.
9. [medium]In a regulated enterprise, the minimum preconditions for copied-index permission-safe RAG are stable group-based boundaries, complete metadata capture, explicit token validation, rapid permission-resync workflows, and independent evidence that unsupported sharing modes are either absent or excluded.

Assumptions

• Assumption: Managed search and knowledge-base services do not expose raw vectors directly to ordinary end users in the default product path. Justification: The reviewed platform documents emphasize managed service endpoints and service-role access rather than raw vector export APIs for end users, so the most realistic leakage path in ordinary deployments is via retrieval behavior or privileged backend access.
• [assumption] Assumption: Enterprise scale in this item means thousands of users, millions of documents, and regular permission changes. Justification: The item's own scope explicitly frames the scale question that way, so scale recommendations are evaluated against that operating assumption.

Analysis

• The core trade-off is between fidelity to the source permission model and the operational convenience of a copied retrieval corpus. Live delegated retrieval maximizes fidelity because authorization stays in the source system, but it reduces platform portability and inherits source-specific limits. Copied-index architectures maximize control over search behavior and latency, but they convert authorization into a data-synchronization problem that the institution must now operate correctly.

• The embedding literature and the RAG membership-inference literature shift the burden of proof. It is no longer enough to say that unauthorized chunks are filtered out at query time, because the retrieval corpus itself is a sensitive representation whose leakage properties matter to the architecture decision.

• The correct sequencing is therefore: rationalize permissions, collapse entitlements into stable group-based boundaries where possible, decide whether live retrieval is needed for full-fidelity estates, and only then build copied-index RAG where the permission model can actually be represented and refreshed reliably.

Risks, Gaps, and Uncertainties

• Azure's strongest copied-permission features are still public preview, so production-readiness evidence is weaker than the design logic.
• The literature proves embedding inversion and transfer leakage, but it does not yet publish a direct end-user enterprise attack showing unauthorized document recovery from a well-isolated managed vector service with no vector access.
• The reviewed AWS documentation does not describe a native live source-authorization model for Bedrock Knowledge Bases, so the comparison of Bedrock against delegated-retrieval architectures is limited to what the public docs state.
• SharePoint estates with heavy use of unsupported link types or unresolved SharePoint groups could be even harder to represent safely in copied-index RAG than the public preview limitations already suggest.

Open Questions

1. What empirical latency and recall trade-offs emerge when a Microsoft 365 estate moves from copied ACL indexing to live Copilot Retrieval API grounding for the same workload?
2. Can a regulated enterprise define a practical maximum stale-permission window for copied-index RAG, and what controls are needed to prove compliance with that window?
3. What attack results appear when modern enterprise vector services are tested for unauthorized document recovery without direct vector export, rather than for generic inversion under lab access?
4. At what boundary cardinality does per-security-boundary partitioning become more costly than live delegated retrieval in a large regulated enterprise?

sources

• [x] Microsoft Azure AI Search - security filtering for multi-tenant search — - Microsoft documentation on security trimming; primary source for the Access Control List (ACL) metadata filtering approach
• [x] Microsoft Azure AI Search - security and access controls overview — - overview of index-level and document-level security models in Azure AI Search
• [x] AWS Bedrock Knowledge Bases - security and access control — - AWS documentation for Bedrock Knowledge Bases permission model
• [x] SharePoint Online - permission inheritance and sharing model — - Microsoft documentation on the SharePoint Online permission model that underpins Microsoft 365 (M365) RAG data sources
• [x] seeded identifier reviewed during investigation; resolved to an unrelated Chain-of-Verification paper and excluded from the evidence set
• [x] seeded identifier reviewed during investigation; resolved to an unrelated deceptive-alignment paper and excluded from the evidence set
• [x] Azure AI Search - document-level access overview
• [x] Azure AI Search - query-time ACL and role-based access control enforcement
• [x] Azure AI Search - SharePoint ACL ingestion and synchronization
• [x] Azure AI Search - remote SharePoint knowledge source
• [x] Microsoft 365 Copilot Retrieval Application Programming Interface (API) overview
• [x] Amazon Bedrock Knowledge Bases - query configuration and metadata filtering
• [x] Amazon Bedrock Retrieve API
• [x] Amazon Bedrock RetrievalFilter API
• [x] Amazon Bedrock metadata filtering blog
• [x] Amazon Bedrock access control with metadata filtering blog
• [x] Text Embeddings Reveal (Almost) As Much As Text
• [x] Transferable Embedding Inversion Attack: Uncovering Privacy Risks in Text Embeddings without Model Queries
• [x] Mitigating Privacy Risks in Large Language Model (LLM) Embeddings from Embedding Inversion
• [x] Is My Data in Your Retrieval Database? Membership Inference Attacks Against Retrieval Augmented Generation
• [x] SoK: Privacy Risks and Mitigations in Retrieval-Augmented Generation Systems