RAG Permissions Require Real-Time Authorization

RAG permissions become stale faster than vectors. A new AWS architecture article therefore presents a two-stage approach: the index quickly filters candidates using stored access metadata, but before content reaches the language model, the system verifies authorization again at the source.

An index is not an authorization system

During ingestion, ACLs, groups, and owners can be stored as metadata on documents or chunks. This accelerates retrieval, but it preserves only a point-in-time view. Between synchronization runs, an employee may change teams, a project folder may become restricted, or a document may be deleted.

For Google Drive, AWS therefore describes pre-filtering in the vector index followed by a real-time check of the retrieved candidates through the source API. Only documents that the requesting user can still access may enter the model context.

Microsoft applies the same core principle to the Microsoft 365 Copilot APIs: requests operate in the context of the signed-in identity and should return only content that identity is authorized to access. Existing controls in the source system remain part of the response path.

What the architecture also needs

A current check does not solve the entire problem. Enterprises must design the control path explicitly:

• Identity: Every request must map to a real person or a tightly scoped process identity.
• Failure behavior: If the source check is unavailable or inconclusive, the system must not fall back to stale permissions.
• Latency: Candidate counts, batch checks, and short-lived caches must prevent performance pressure from bypassing security.
• Revocation: Permission changes and deletions must propagate to the index, caches, and stored responses.
• Evidence: User, source, checked resource, and authorization decision need traceable logs.

OWASP likewise recommends access control during retrieval, permission metadata for each chunk, audit logging, and cascading deletion of dependent vectors.

The operational consequence

A broadly privileged service account is especially risky because it can bypass source-system protections and expose content that users could never open directly. Authorization and query logs may themselves contain personal or confidential data, so purpose, retention, and access must be defined.

Treat the vector index as a search accelerator, not the final authority. The decisive control question is: Would the source system still allow this access right now?