Permission-Aware RAG for Customer Data

Retrieval-augmented generation can make an AI system useful with customer-specific knowledge. It can also make an existing permission mistake easier to exploit. If a user cannot open a source document, the system must not retrieve its chunks, quote its text, summarize it, or reveal that it exists.

That requirement changes RAG from a search feature into an authorization system. Access control must be preserved from ingestion through retrieval, generation, citation, deletion, caching, and support operations.

Build a secure ingestion pipeline

Connect to a source using an identity with the narrowest practical access. A broad administrative connector may be convenient, but it imports content and permissions the application may not be able to interpret safely. Record which customer, connector, source, and source version produced every document.

Treat documents as untrusted input. Validate type and size, isolate risky parsers, normalize text, and scan attachments where appropriate. Content can contain instructions aimed at the model, but text inside a document is data, not authority to change system behavior or call tools.

A durable ingestion sequence is:

receive a source change with tenant and connector context;
fetch the document and authoritative access-control information;
normalize and classify the content;
create stable document and version identifiers;
chunk the content while retaining source offsets;
attach tenant, document, version, and permission metadata to every chunk;
embed and index it; and
record an auditable completion or failure state.

Make each stage idempotent. Replaying a source event should update the same document version or create a deliberate new version, not silently duplicate chunks.

Preserve access control per document

Represent the principals allowed to read a document: users, groups, roles, or attributes. The model is not a principal that gets independent access. It acts on behalf of the authenticated user and tenant for the current request.

Permission data changes independently from document text. A user can leave a team without the file changing. Support permission-only updates, record their source version, and set a maximum acceptable staleness. For high-risk content, fail closed if current permissions cannot be established.

Attribute-based access control can help express rules involving tenant, department, region, classification, or project membership. Keep the policy understandable and testable. A complicated policy copied into several services will eventually diverge.

Filter before content reaches the model

Construct the retrieval filter on the server from authenticated tenant and principal context. Do not accept a client-provided filter as proof of authorization. Apply the filter inside the search operation, before selecting chunks or assembling a prompt.

Post-filtering an unauthorized result after vector search can be both unsafe and ineffective. It may leak metadata, affect ranking, reduce the authorized result set below expectations, or expose content through traces. Use a store that can enforce the required filter during retrieval, and test its semantics under joins, groups, missing attributes, and policy changes.

Managed RAG features may offer ACL-aware filters, but read their guarantees carefully. AWS, for example, warns that managed ACL filtering is not a replacement for authorization and authentication in the surrounding application. Your service remains responsible for deciding who the caller is and which policy applies.

Caches need the same discipline. Include tenant, principal or permission-set version, query, model configuration, and corpus version in a cache key when caching is permitted. A global semantic-answer cache can turn one user's authorized answer into another user's disclosure.

Make citations traceable

Each answer citation should resolve to a stable document ID, version, chunk or source range, source title, and an authorized link. Store which retrieved chunks contributed to a response, along with the policy version used for the decision.

A citation is provenance, not proof of correctness. The cited passage may be outdated, ambiguous, or insufficient for the generated claim. Evaluate whether citations actually support the nearby statement and whether the user can still open the source.

Deletion must propagate through raw files, normalized text, embeddings, caches, generated previews, and derived metadata. Marking the source row deleted while leaving searchable chunks behind is not deletion.

The resulting pipeline should feed the traces and quality signals described in AI observability.

Common failure modes

Indexing with an administrator account and dropping source permissions.
Filtering by tenant but ignoring document-, group-, or user-level rules.
Applying permission checks after retrieval or after prompt construction.
Letting a document's embedded instructions override system policy or tool controls.
Caching answers without tenant and permission context.
Showing a citation link that reveals an unauthorized document title or existence.
Updating content but not permissions, or deleting records without deleting embeddings.

Implementation checklist

Map source identities, tenant ownership, and permission semantics before ingestion.
Preserve stable document, version, chunk, and source-range identifiers.
Attach enforceable permission metadata to every searchable unit.
Build retrieval filters only from trusted server-side identity context.
Fail closed when required permission data is missing or stale.
Test direct, group, inherited, revoked, and cross-tenant access cases.
Track citation provenance and verify that cited text supports the answer.
Propagate permission changes and deletion to every derived store.
Redact sensitive content from prompts, traces, and evaluation datasets.

Measurable signals

Monitor ingestion lag, permission-sync lag, documents or chunks missing access metadata, denied retrieval attempts, cross-tenant negative tests, deletion propagation time, duplicate chunks, citation coverage, citation-support accuracy from sampled evaluations, retrieval relevance, and answers withheld because authorization state was unavailable. Security tests should use adversarial identities, not only happy-path users.