Access control in a RAG: the architecture choices to document

An enterprise RAG must not turn a vague access right into conversational search at scale. Before ingestion, the team must be able to explain how it identifies the user, decides access to a document, enforces that decision during retrieval and proves the result afterwards.

In short

Access control starts with an explicit business rule, not with a filter added to the vector database.
Document these choices: identity, protected object, authorisation rule, propagation to the index, refusals, revocation and audit.
Test denied access as much as useful answers. A relevant result obtained from an unauthorised source is still a failure.

This method is a design framework. It does not replace a security, data protection or compliance analysis tailored to your organisation.

Why document access before indexing?

Indexing splits, enriches and makes documents findable. If the team does not know which permissions must follow each document, it does not know which metadata to keep or which refusal scenarios to test.

The principle is consistent with NIST's Zero Trust Architecture, published in August 2020: no implicit trust follows from network location alone, and access to a resource must be authenticated and authorised before a session is established. For a RAG, this means treating a user's query as a request to access specific passages, not as a mere semantic search.

The useful document is therefore a decision sheet that business, security and the build team can all read. It avoids two shortcuts: replicating groups without knowing what they mean, or using a single technical identity that reads more than the end user.

Which identity does the RAG really use?

Start by tracing the path between the person and the query. You need to distinguish:

Element	Question to document	Expected evidence
User	Who is asking the question?	Stable identifier and authentication method
Context	In which organisation, team or role are they acting?	Attributes and groups used
RAG service	With which identity does it call the sources and the index?	Identity flow and technical scopes
Document source	Where is the access rule authoritative?	Owning system and business owner

This distinction is essential when a service queries a connector with a service identity. That identity may be technically necessary. It must not become a silent substitute for the rights of the person asking the question.

The AI Act documentation method for a GenAI system helps link this identity decision to a use case, a connector version, a test and operational evidence. The file does not replace the access rule, but it must let you find out why the rule was designed and changed.

In its LLM06:2025 Excessive Agency entry, OWASP recommends tracking the user's authorisation and security scope so that actions on downstream systems run in their context, with the minimum privileges needed. This recommendation also applies to read connectors: the scope passed on must be explicit and testable.

Which object does the corpus protect?

The word "document" hides several levels. A policy may be authorised as a whole while an appendix or a working version is not. Conversely, the same document may legitimately be visible to several groups.

Before choosing the index schema, define the object that carries the rule:

the whole source document;
a section or passage, if splitting changes the scope;
an attachment or a version, if it has a distinct life cycle;
a document set, when a partitioning rule applies to a whole space.

For each object, keep a source identifier, an owner, a publication state and the applicable access rule. The vector chunk must not be the only memory of this decision. It must be traceable to the original document and to the rule that authorises it.

Before propagating this rule to the index, also formalise the data scope of the RAG: admitted categories, exclusions, authorised transformations, outputs and withdrawal. Reliable access control does not make a source relevant or usable by default.

How do you write a verifiable authorisation rule?

A usable rule answers a simple sentence: "this user may read this document in this context because…". Avoid vague labels such as "internal documents" or "finance team" without a source of truth.

A rule sheet can take this form:

Decision	Example wording to adapt	Associated test
Subject	The user is authenticated by the organisation's directory.	A query without a session is refused.
Attribute	Access depends on the business group and organisational scope.	Two users from different groups receive distinct sets.
Resource	The document inherits the rule defined in its source.	The indexed rule matches the source rule.
Effect	Only passages from an authorised document can be offered to the model.	A forbidden passage appears neither in the context nor in the answer.
Exception	A waiver has an owner and an end date.	After the deadline, access is refused.

This rule must also cover empty results. An absence of passages can come from missing content or from a denied access. The system does not have to reveal which is true if that information itself creates a leak.

Where should the access decision be enforced in the architecture?

A robust architecture applies the same intent at several stages. The exact mechanisms depend on the source, the IAM and the storage chosen. What matters is documenting each layer's responsibility.

At sign-in, establish the identity and usable attributes.
At ingestion, link the indexed content to its original document and to the access rule to propagate.
At retrieval, pass a verifiable authorisation scope to the retrieval mechanism.
Before generation, give the model only authorised, traceable passages.
In the answer, show only citations the user is authorised to view.
In the traces, record what is needed to investigate without turning logs into a copy of the sensitive corpus.

The guide on RAG access control architectures presents several possible mechanisms, such as metadata filtering, index isolation or database policies. Here, the selection criterion is different: for each mechanism, the team must be able to show where a mapping error would be detected.

How do you handle changes and revocations?

An access right is not fixed. A user changes team, a document is reclassified, a source is deleted or a waiver expires. The architecture file must describe what triggers the update and how the team checks its effect.

Document at least:

the source of truth for rights and for content;
the synchronisation trigger, periodic or event-driven;
the behaviour when synchronisation fails;
the owner who handles the gap;
a revocation test run on a representative corpus.

Do not turn a cache duration into a universal promise. The acceptable freshness depends on the type of data, the risk and the organisation's ability to detect a gap. This choice must be accepted by the relevant owners and put through a realistic test.

What evidence should you keep for audit and operations?

Traceability does not mean keeping every exchange without limit. It means keeping proportionate evidence that answers an operational question: which identity asked for what, which scope was computed, which sources were used and which mechanism produced the answer?

For each sensitive scenario, define in advance:

the events to log;
the fields to minimise or mask;
the people authorised to view these traces;
the retention period applicable in your context;
the procedure when an unexpected access is reported.

This discipline extends the scoping of a RAG project: a prototype does not demonstrate production capability if it cannot explain its sources, refusals and limits. When a system can also act through business tools, controlling sources is no longer enough: our guide on human approvals for an AI agent connected to business tools helps define which operations must be subject to an explicit decision.

Which tests make the rule credible?

A RAG evaluation set must contain positive and negative tests. Positive tests check that a person finds an authorised and useful source. Negative tests check that the system provides no passage, no citation and no usable clue about a forbidden source.

Prepare at least the following scenarios:

two users with different rights on the same topic;
an authorised document and a forbidden document that are semantically very close;
a revocation or a group change;
a deleted or reclassified source;
a request that tries to obtain the list or content of out-of-scope documents;
a failure of the identity connector or of rights synchronisation.

For each test, keep the simulated identity, the authorised sources, the forbidden sources, the expected result and the actual observation. The guide Evaluating a RAG in production explains how to attach these cases to the overall test set, rather than leaving them in an isolated security acceptance test.

What should you decide before starting the build?

Before the first sprint, gather these six pieces of evidence on a decision page:

the user identity and the attributes actually available;
the protected object and the source of truth for rights;
the authorisation rule, written and testable;
the propagation path to the index and to generation;
the revocation mechanism and the behaviour on failure;
the denied-access scenarios, the traces and their owners.

If any of this evidence is missing, a prototype can still be used to explore an integration. It must not be presented as proof that the system protects production data.

FAQ

Should you copy all ACLs into a vector database?

Not necessarily. The choice depends on the source of truth, the retrieval mechanism and freshness requirements. However, the team must always be able to link the retrieved passage to a valid access rule and test rights changes.

Is a metadata filter enough to secure a RAG?

A filter can be part of the mechanism. It replaces neither the user identity, nor the quality of the metadata propagated at ingestion, nor refusal and revocation tests. Security depends on the full path between the source and the answer.

What should the RAG answer when no document is authorised?

The answer must be defined in the service contract. It must stay useful without confirming that a sensitive document exists. Avoid needlessly distinguishing "no result" from "forbidden result" if that distinction reveals information.

Who validates a RAG's access rules?

Validation should involve the business owner of the data, the team that manages identity and access, and the team responsible for the system. Depending on the context, the security, legal or data protection functions may also need to be involved.

Methodology and sources

NIST SP 800-207, Zero Trust Architecture, published in August 2020, consulted on 11 September 2026. This publication describes the principles of a zero trust architecture, including the absence of implicit trust based on network location, and authentication and authorisation before access to a resource.
OWASP, LLM06:2025 Excessive Agency, consulted on 11 September 2026. Among other measures, the entry recommends tracking the user's authorisation and security scope, with the minimum privileges needed for downstream systems.

The method presented is a documentation grid for an enterprise RAG. It contains no client data, no mission statistics and no promise of security or compliance. Architecture choices and retention rules must be validated in the context of each organisation.

Do you need to determine how a RAG can respect existing access rights before the build? Describe your context to IgnitionAI. A first conversation can help clarify the sources, architecture decisions and test scenarios to document.