Enterprise RAG Security and Authorization

The most dangerous RAG failure is not a hallucination. It is a correct answer from a document the caller was never allowed to read.

The model may quote the source accurately. Retrieval relevance may be excellent. Citations may resolve to real enterprise content. From a search perspective, the system worked. From a security perspective, it disclosed data across an authorization boundary.

This is why enterprise RAG is an authorization problem before it is a search problem.

Retrieval determines which information enters the model context. Once an unauthorized chunk has crossed that boundary, output filters and system prompts are late controls. The model has already received the data.

What is permission-aware enterprise RAG?

Permission-aware enterprise RAG is a retrieval architecture that preserves source-system authorization from ingestion through query execution, generation, citation and audit.

For every request, the system must establish:

who the caller is and on whose behalf it is acting;
which tenant, groups, roles and attributes apply;
which sources and individual records that identity may access;
whether the indexed permission state is current enough for the workload;
which authorized chunks were actually supplied to the model;
what evidence must remain after the answer is returned.

The defining property is not the vector database or embedding model. It is that relevance ranking operates only inside an authorized candidate set.

Retrieval is a disclosure event

RAG diagrams often present retrieval as a quality step: query a knowledge base, select relevant passages and add them to the prompt. In enterprise systems, retrieval is also a disclosure decision.

A retrieved passage can influence the answer even if it is not quoted. It can reveal names, prices, project codes, legal positions or the existence of a confidential record. An agent can use the passage to choose a tool or make a downstream decision. Suppressing the source citation does not undo the disclosure.

The authorization check therefore belongs before context assembly. Ideally it is enforced by the retrieval service or underlying data platform as part of the query, not applied as an informal post-processing step after a broad vector search.

Microsoft describes this pattern as document-level access control or security trimming: identity and permission metadata are preserved through indexing and applied when results are retrieved. Google and AWS expose similar ACL-aware retrieval patterns. The implementation differs; the trust boundary does not.

A system prompt is not an access-control mechanism

Instructions such as “only answer from documents the user may access” do not provide authorization. The model cannot reliably establish entitlement from prose, and it should never receive unauthorized documents in order to decide whether to ignore them.

The same applies to content guardrails. They can detect selected classes of sensitive output, but they do not know the complete access policy of every source record. A finance forecast may be safe for one executive and prohibited for another. The content itself does not reveal the entitlement.

Authorization must be deterministic and external to the model:

authenticate the caller;
resolve the applicable authorization context;
apply it to every retrieval request;
fail closed when the context or permission state cannot be evaluated;
send only authorized results into the model context.

The model can explain a denial produced by the platform. It must not make the denial decision.

Identity must survive the complete request path

Authentication at the user interface is not enough. The relevant identity has to survive application, orchestration, retrieval and agent boundaries.

A useful authorization context may include:

human or service identity;
tenant and environment;
group and role claims;
resource attributes and sensitivity clearance;
delegated user when an agent acts on behalf of a person;
agent or application identity;
purpose, workflow and approval state;
policy and identity-token version.

An agent introduces two identities, not zero. The platform must know which agent is executing and which user or service delegated the task. The effective authority should be the bounded intersection required for the operation—not the union of every permission available to the agent runtime and the user.

Do not replace this context with one shared service account at the retrieval layer. Shared technical credentials are useful for authenticating the application to the retrieval service, but the service must still receive and enforce the caller’s delegated authorization context.

Permission-bearing ingestion

Most RAG security failures are designed into the ingestion path long before a query arrives.

Every indexed object needs an authorization envelope:

source-system identifier and canonical resource ID;
tenant or security domain;
allowed and denied principals or groups;
classification and residency attributes;
source version and permission version;
ingestion and last-verified timestamps;
deletion or revocation state.

These properties must propagate to every derived chunk. Splitting a document must not detach its content from the document’s owner, permissions and lifecycle. The same rule applies to tables, OCR output, image descriptions, summaries and other derived representations.

If a chunk cannot be mapped back to an authoritative source record and permission state, it should not enter a governed enterprise index.

ACL synchronization is a security control

Enterprise permissions change continuously. Employees move teams. Contractors leave. Cases close. Documents are reclassified. Legal holds and information barriers are added. A RAG index that synchronizes content but not permissions creates a revocation gap.

The platform needs an explicit consistency contract:

How quickly must grants appear?
How quickly must revocations take effect?
Can high-risk sources tolerate scheduled synchronization?
Which queries require real-time validation against the source?
What happens when the identity provider or permission source is unavailable?

Grants and revocations are not symmetrical. A delayed grant reduces availability. A delayed revocation may disclose data. High-risk systems should optimize the latter boundary and fail closed when required permission evidence is stale or unavailable.

A practical design can combine indexed ACLs for efficient candidate filtering with real-time source verification before returning highly sensitive records. AWS documents this hybrid pattern for ACL-aware knowledge bases: synchronized permissions are enforced during retrieval, and supported connectors can verify access at the source when returning results.

Permission lag should be measured like replication lag. It is not an ingestion detail.

Filter before ranking, not after generation

The safest query path is:

resolve identity and policy context;
select the permitted source or tenant scope;
apply document-level authorization filters;
run lexical, vector or hybrid retrieval inside that scope;
rerank authorized candidates;
assemble bounded context with provenance;
generate and validate the answer.

Post-filtering a broad result set is fragile. If the most similar candidates are unauthorized and removed after retrieval, the remaining set may be empty or low quality even though relevant authorized documents exist below the original top-k boundary. Increasing top-k reduces that failure but expands cost and exposure inside the retrieval service.

Authorization-aware filtering should be pushed as close as possible to the data store. When the platform cannot enforce the complete rule natively, put a governed retrieval API in front of the store. Microsoft recommends this gatekeeper pattern for secure multitenant RAG: application code does not query backing vector stores directly; the API encapsulates tenant routing, identity propagation, security trimming and access logs.

Tenant isolation and document authorization are different controls

A store-per-tenant architecture can reduce the blast radius of a filtering error. It does not prove that every user inside the tenant may read every document.

Likewise, a shared store can be safe only if tenant and document filters are mandatory, validated and difficult to bypass. The decision between isolated stores and shared indexes is an operational trade-off involving scale, cost, lifecycle and failure isolation. It is not a substitute for an authorization model.

Use both scopes explicitly:

tenant or security-domain isolation selects the permitted storage boundary;
document-level authorization trims results for the specific caller inside that boundary.

Shared public or enterprise-wide knowledge should be represented as an intentional scope, not as documents with missing permission metadata.

Deny by default when permission metadata is incomplete

Every ingestion pipeline eventually encounters documents with missing owners, unresolved groups, connector errors or unsupported permission types.

The convenient behavior is to index the content without filters and repair metadata later. That converts a data-quality problem into an access-control vulnerability.

A governed index should quarantine records when:

the source identity cannot be mapped;
permissions cannot be represented by the target store;
a group expansion is incomplete;
the source version and ACL version disagree;
the connector cannot confirm whether the record was deleted;
a required classification is absent.

Some platforms enforce this structurally. AWS documentation for ACL-enabled S3 knowledge bases notes that documents without ACL entries are not ingested. The broader principle is correct: unclassified content should not silently become globally readable.

Retrieved content is untrusted data

Authorization answers whether the caller may read a document. It does not establish that the document is safe to treat as an instruction.

Enterprise repositories contain emails, tickets, webpages and uploaded files. Any of them can include hidden or explicit instructions intended to manipulate an AI system. OWASP identifies indirect prompt injection and poisoned vector content as distinct risks in LLM and RAG applications.

The retrieval boundary therefore needs two independent decisions:

May this caller access the content?
How may this content influence the system?

Preserve message roles and source metadata. Mark retrieved passages as evidence, not authority. Keep tool permissions outside retrieved text. Validate structured fields before they influence actions. Apply additional inspection or isolation to untrusted external sources.

Permission-aware retrieval prevents unauthorized disclosure. It does not by itself prevent authorized malicious content from steering an agent.

Provenance must survive generation

A citation is useful only when it refers to the exact authorized source used for the response.

For each context item, retain:

canonical source and record identifier;
source and index version;
chunk location;
retrieval and reranking scores;
authorization decision reference;
content hash where appropriate;
retrieval timestamp.

The user-facing citation should resolve through an authorized application route, not expose a storage URL that bypasses normal access control. When a user opens the source later, the application should re-evaluate current access.

This means a previously valid citation may later produce an access denial. That is preferable to treating historical retrieval authorization as a permanent sharing grant.

Audit the knowledge supplied to the model

Application logs that record only the final answer cannot reconstruct a RAG decision.

An audit-ready retrieval event should include:

operation, user, agent and tenant identifiers;
query fingerprint or appropriately protected query text;
identity and policy version;
selected knowledge base and index version;
filters and authorization decision;
authorized source and chunk identifiers;
denied or empty-result reason;
retrieval, reranking and context-assembly versions;
model request and resulting citation identifiers.

Do not record raw sensitive content merely to make the system auditable. Metadata and hashes may be sufficient for many investigations. Content capture should follow classification, redaction, sampling, access and retention rules.

The goal is to answer: which authorized evidence was supplied to this model for this operation under this policy?

Evaluate authorization, not only answer quality

A RAG evaluation set that measures only relevance and groundedness can reward an insecure system. Unauthorized documents may be highly relevant.

Security evaluation should include:

cross-tenant queries with semantically similar private content;
users with different roles inside the same tenant;
direct and nested group membership;
recent grants and revocations;
deleted, moved and reclassified documents;
missing or malformed ACL metadata;
identity-provider and permission-source outages;
agent retrieval under delegated authority;
indirect prompt injection inside authorized sources;
citations opened after access has changed.

Critical authorization requirements should be non-compensating release gates. Higher retrieval recall does not offset one cross-tenant disclosure.

The release discipline described in our guide to production AI operations and reliability applies directly here: permission datasets, policy versions and security scorers belong to the validated release configuration.

Operate permission-aware retrieval as a platform service

Several operational signals matter more than generic vector-store health:

percentage of indexed records with valid permission metadata;
ACL and group-synchronization lag;
quarantined records by source and reason;
retrieval denials and authorized zero-result rate;
real-time source-verification failures;
queries rejected for missing identity context;
permission-filter latency and candidate reduction;
revocation tests and canary results;
attempts to bypass the governed retrieval API.

These signals require ownership. Source teams own authoritative content and permissions. The identity team owns principal and group resolution. The AI platform team owns permission propagation, enforced retrieval and evidence. Application teams own the domain behavior and user experience around denials and incomplete knowledge.

This shared responsibility is one reason knowledge services belong in the enterprise AI platform. Rebuilding security trimming independently inside every chatbot produces inconsistent controls and invisible revocation gaps.

A practical implementation sequence

Stage 1: Establish the retrieval boundary

Put a governed API in front of vector and search stores. Require authenticated application identity and caller context. Remove direct store access from application code.

Stage 2: Carry provenance and permissions through ingestion

Define a canonical authorization envelope and propagate it to every chunk and derived asset. Quarantine content with incomplete or unsupported permission metadata.

Stage 3: Enforce security trimming at query time

Apply tenant and document filters before context assembly. Use platform-native row or document controls where possible. Fail closed when identity or policy cannot be evaluated.

Stage 4: Define the consistency contract

Set grant and revocation objectives by source risk. Measure ACL lag. Add real-time source verification for workloads that cannot tolerate indexed permission delay.

Stage 5: Add adversarial evaluation and audit

Test cross-tenant isolation, group changes, revoked documents, missing ACLs and poisoned authorized content. Record the evidence required to reconstruct every retrieval decision.

Stage 6: Federate onboarding without federating control

Allow domain teams to register sources and define business metadata through a standard contract. Keep identity propagation, authorization enforcement, quarantine and audit behavior consistent across the platform.

Secure RAG begins before similarity search

Relevance answers which document best matches a query. Authorization answers whether that document may participate in the operation at all.

The order cannot be reversed.

A production enterprise RAG system must carry identity to retrieval, permissions to every chunk, provenance to every answer and revocation into the operating model. It must treat retrieved content as untrusted data and preserve enough evidence to reconstruct what the model was allowed to see.

Only after those boundaries are enforced does search quality become the primary problem. Otherwise, better retrieval merely makes the system more efficient at finding information it may not be allowed to disclose.

Enterprise RAG Is an Authorization Problem Before It Is a Search Problem