The Question
When an enterprise deploys a RAG system over its internal document library — contracts, HR policies, technical documentation, customer records, financial reports — the implicit assumption is that the access controls governing the source documents carry over to the RAG system. An employee who cannot access the executive compensation policy in SharePoint should not be able to retrieve it through an AI assistant built on top of SharePoint.
That assumption is wrong by default. Most RAG implementations, deployed without explicit authorization-aware retrieval architecture, do not inherit the access controls of the source document system. The retrieval layer pulls semantically relevant documents regardless of whether the querying user is authorized to access them. The LLM then synthesizes those documents into a response. The user receives information they have no authorization to see — and neither the RAG system nor the document management system logged it as a violation, because neither system had visibility into the access control gap.
This is not a theoretical architecture concern. It is the default behavior of naively deployed RAG systems, and enterprises deploying RAG at scale without addressing it are operating with a document access control system where the access controls do not apply.
A RAG system built without authorization-aware retrieval is a document access control system where the access controls don't apply — and the enterprises deploying RAG without solving this have created a mechanism for users to access documents they couldn't access in the source system.
Why This Matters Now
The scale of enterprise RAG deployment accelerated sharply in 2024 and 2025, driven by Microsoft Copilot's integration into Microsoft 365 (which reaches the majority of Fortune 500 companies), Google's Gemini for Workspace, and Salesforce's Einstein Copilot. Each of these systems implements RAG over enterprise document stores — and each shipped with varying degrees of authorization-aware retrieval. Microsoft's Copilot for Microsoft 365 is integrated with Microsoft Entra ID permissions, which provides a meaningful access control layer. Many competing and custom RAG deployments are not.
In 2025, a documented internal incident at a European financial services firm became a reference case for the RAG access control gap: an analyst used an AI assistant to research internal acquisition targets and received, in the LLM's synthesized response, deal terms from documents that were restricted to the M&A team and above. The analyst had not queried for those documents specifically — they appeared as semantically relevant context for a general market research query. The incident required regulatory notification to the financial regulator under EU MAR (Market Abuse Regulation) insider information protocols, triggered an internal investigation, and resulted in a temporary suspension of the AI assistant while authorization controls were retrofitted.
The incident illustrates why the RAG access control gap is not an abstract security concern. The attack does not require a sophisticated adversary. It does not require knowledge of what documents are in the system. It requires only a query that happens to be semantically similar to restricted documents — and in a large enterprise document store, that condition can be satisfied by routine work queries.
Indirect prompt injection via RAG is a separate, compounding risk. If an attacker can place content into any document source that gets indexed into the RAG vector store — a publicly accessible webpage, a shared document, a monitored email thread — they can inject instructions into the LLM's context window. The LLM may follow those instructions rather than recognizing them as adversarial input.
What the CURVE™ Data Shows
The 2026 Stackcurve Data Security for AI CURVE™ Report evaluated the RAG security market across four dimensions: authorization-aware retrieval implementation (does the retrieval layer enforce document-level access controls?), multi-tenant isolation quality (are namespace boundaries enforced to prevent cross-tenant data leakage?), prompt injection detection applied to retrieved content, and integration breadth with enterprise vector database providers.
Knostic ranked in the Leader tier as the only vendor in the evaluation whose core product is specifically designed to solve the authorization-aware retrieval problem. Knostic's architecture enforces document-level authorization in the retrieval layer — users only retrieve documents they are authorized to access, verified against enterprise identity systems, before those documents ever enter the LLM's context window. This is the correct architectural intervention for the RAG access control gap, and Knostic is the most mature implementation of it.
Immuta ranked in the Leader tier for its data access control capabilities applied to AI workloads, including vector store access governance. Its attribute-based access control framework, originally developed for cloud data platforms, has been extended to support vector database authorization policies — enabling fine-grained access control that goes beyond the document-level to support row-level and column-level restrictions on embedded data.
Privacera ranked in the Challenger tier for its AI governance capabilities, with particular strength in hybrid and multi-cloud deployments where enterprise data spans multiple vector stores and document management systems. Its centralized policy management approach is differentiated in complex enterprise environments.
Lakera ranked in the Challenger tier for its Lakera Guard product, which addresses the prompt injection vector in RAG systems — detecting and filtering injected instructions in retrieved content before they reach the LLM. This addresses a complementary attack surface to the authorization gap.
The full vendor rankings are in the 2026 Stackcurve Data Security for AI CURVE™ Report — free to download.
The Gap Most Buyers Miss
The RAG security gap is consistently underestimated in enterprise AI deployments because it requires understanding the architecture well enough to recognize that two separate systems — the document management system with its access controls and the RAG retrieval layer — are not connected by default. Three specific gaps recur:
Gap 1: Metadata Filtering Is Not Authorization
The most common partial mitigation deployed in enterprise RAG systems is metadata filtering: each document in the vector store is tagged with a department, classification level, or access group, and queries filter on those tags. This is better than no access control, but it is not equivalent to document-level authorization against an identity provider. Metadata filters are only as accurate as the tagging, which is typically manual and inconsistent in large document stores. They do not reflect dynamic group membership changes (an employee who moves teams still sees documents tagged for their old team if the metadata was not updated). And they do not enforce the full access control matrix of the source system — they enforce a simplified approximation.
Gap 2: Vector Store Namespace Isolation Is Not Encryption
In multi-tenant RAG deployments — where a single vector store instance serves multiple business units, client environments, or tenant organizations — namespace isolation is the mechanism that prevents cross-tenant data leakage. Namespace isolation in most vector databases (Pinecone, Weaviate, Qdrant, Milvus) is a logical separation, not a cryptographic one. A misconfigured query that omits the namespace filter, or a namespace identifier that is predictable and can be guessed, can result in cross-tenant retrieval. For enterprises operating multi-tenant RAG deployments for client-facing use cases, this is a data breach exposure — one tenant's documents surfacing in another tenant's context window.
Gap 3: Indirect Prompt Injection via Retrieved Documents Is Unmonitored
Indirect prompt injection — where an attacker plants adversarial instructions in a document that gets indexed into the RAG store — is the highest-sophistication attack vector in RAG security, and the least monitored. The attacker does not need to compromise the RAG system directly. They need to influence what gets indexed. In an enterprise where the RAG system indexes external web pages, customer-submitted documents, public GitHub repositories, or any other externally sourced content, the injection surface is broad and largely unmonitored. Detection requires scanning retrieved content for instruction-pattern text before it enters the LLM's context window — a capability that only a subset of RAG security vendors currently offer.
Questions Your Buying Team Should Be Asking
1. Does your solution enforce document-level authorization in the retrieval layer — meaning that the identity of the querying user is verified against an authoritative access control system before documents are retrieved — and does this happen before or after documents enter the LLM's context window?
The critical distinction is where authorization is enforced. Authorization checked after retrieval (filtering the LLM's output for content the user should not see) is categorically weaker than authorization enforced at retrieval (never retrieving documents the user is not authorized to see). Ask explicitly: is this pre-retrieval or post-retrieval authorization, and what is the authoritative identity system it integrates with?
2. What is your architecture for multi-tenant RAG deployments — specifically, is tenant isolation cryptographic or logical, and what validation testing have you performed to confirm that cross-tenant retrieval is not possible through namespace manipulation?
Logical isolation is a legitimate architecture if correctly implemented, but it requires validation. Ask for the specific test methodology used to verify namespace isolation, whether penetration testing against cross-tenant retrieval has been performed, and what the remediation path is if a misconfigured query bypasses namespace filtering.
3. Does your solution detect and filter indirect prompt injection in retrieved documents — and what is the detection methodology for instruction-pattern content that is deliberately obfuscated to evade pattern-matching filters?
Naive prompt injection detection based on keyword matching is easily bypassed by encoding, whitespace manipulation, or paraphrasing. Ask for the specific detection methodology, whether it uses semantic analysis rather than pattern matching, what the false positive rate is on legitimate document content, and whether the vendor maintains a benchmark dataset for evaluating detection against novel injection techniques.
4. How does your solution handle dynamic access control changes — specifically, if a user's access permissions change in the enterprise identity system, how quickly does that change propagate to the RAG retrieval layer, and what happens to documents already retrieved in active sessions?
Access control systems are not static. Employees change roles, leave the organization, and have permissions revoked in real time. Ask how quickly identity system changes propagate to the retrieval authorization layer, whether there is a maximum propagation lag guarantee, and whether active sessions are re-evaluated when permissions change.
5. What audit logging does your solution provide for RAG retrieval events — specifically, does it log which documents were retrieved for each query, which user submitted the query, and whether any access control decisions were made (documents excluded from retrieval due to authorization)?
Audit logging for RAG systems is essential for post-incident investigation and regulatory compliance. Ask whether the solution logs retrieval events at the document level (not just query-level), whether access control decisions (inclusions and exclusions) are logged, how long logs are retained, and whether they integrate with the enterprise SIEM.
The Stackcurve Take
RAG security is the enterprise AI security problem with the shortest time-to-consequence of any category in this report series. Enterprises deploying RAG without authorization-aware retrieval are not running a theoretical risk of future attack — they are operating a system where information disclosure is occurring with every query that happens to surface restricted documents. The disclosure may not be noticed, logged, or investigated. But it is happening.
The remediation path is architectural, not cosmetic. Metadata filtering does not solve the authorization gap. Output filtering does not solve the authorization gap. The solution is pre-retrieval authorization enforcement against an authoritative identity system — and in 2026, Knostic is the only purpose-built vendor for this specific problem, with Immuta and Privacera offering complementary access governance capabilities for enterprises with complex multi-platform data environments.
The 2026 Stackcurve Data Security for AI CURVE™ Report covers the full RAG security vendor landscape, including detailed assessments of authorization-aware retrieval implementations, vector store access control, and prompt injection defense in RAG architectures. Download it free →
Stackcurve Advisory Briefs are independent research. No vendor pays for placement, tier assignment, or editorial influence. The CURVE™ methodology is disclosed in full at stackcurve.net/research/methodology.