RAG projects often begin by uploading documents and evaluating answer quality. Once the corpus includes contracts, HR files, commercial proposals, and departmental instructions, however, the central question changes from “did retrieval find the right passage?” to “was this user allowed to see that passage?”

A local model does not solve this problem by itself. It reduces data transfer outside the controlled environment, but it does not distinguish the rights of a director, an accountant, and a contractor. If a restricted passage has already entered the model context, a later instruction not to disclose confidential information cannot take it back. Permissions therefore have to be enforced before retrieval and before generation.

What the sources establish

OWASP treats vector and embedding weaknesses as a separate LLM08:2025 risk. A shared vector database can leak context between user groups. Recommended controls include fine-grained permissions, logical dataset partitioning, source classification, and retrieval logging.

Qdrant documents several multitenancy patterns. Many small tenants can share a collection when every point carries a tenant payload and every query enforces a tenant filter. A smaller number of large tenants can use dedicated shards. Separate collections offer stronger isolation at the cost of additional operational overhead. These are enforcement mechanisms, not a complete security policy.

NIST SP 800-207 provides a useful principle for RAG: a request does not become trusted merely because it originates on an internal network. Authorization is tied to a specific subject, resource, and context. PostgreSQL Row-Level Security applies a similar idea to database rows: after RLS is enabled, a missing applicable policy produces default deny. Keycloak separates the policy decision point from the policy enforcement point.

The practical conclusion is straightforward: permissions belong in the corporate identity and document metadata systems, while the retrieval layer must enforce the restriction that those systems calculate.

A minimum architecture for permission-aware RAG

A production pipeline can be split into eight components.

1. **Identity provider.** The user signs in through a corporate identity. The backend receives verified `user_id`, `tenant_id`, groups, role, and session expiry. These values must not come from the prompt or from editable browser fields.

2. **Document registry.** Every source file has an owner, department, classification, allowed groups, validity period, and ACL version. The document management system, file store, or business application remains the source of truth; the vector store is only a projection.

3. **Indexer.** When a document is split, every chunk inherits at least `tenant_id`, `document_id`, `acl_version`, `allowed_groups`, `classification`, and source provenance. If document permissions change, old chunks cannot remain indexed with stale metadata.

4. **Policy decision point.** A policy service combines the verified identity with the requested resource. It returns a machine-enforceable restriction rather than prose: allowed tenant, groups, document classes, and decision expiry. This can be a compact in-house service, Keycloak Authorization Services, or another corporate PDP.

5. **Policy enforcement point.** The backend builds a mandatory filter and sends it with the retrieval query. The client cannot remove `tenant_id` or expand group membership. Missing or malformed authorization context causes denial, never an unfiltered search.

6. **Retriever and reranker.** They operate only on the authorized candidate set. Semantic similarity orders items inside that set; it never grants access. An LLM may rewrite the user query, but it must not invent, relax, or remove the ACL filter.

7. **Answer generator.** The model sees only passages that passed the filter. Answers cite `document_id` and source version. Citation validation is useful defense in depth, but it does not replace filtering before retrieval.

8. **Audit and feedback.** Logs record the subject, policy version, filter, retrieved chunk identifiers, access outcome, and latency. They do not need to copy confidential document content into the operational log.

Why filtering after retrieval is insufficient

Some systems retrieve a global top-k and remove forbidden passages afterwards. This creates three problems.

  • Restricted data has already been processed by the search service, reranker, or trace pipeline.
  • After removal, the user may receive weak or empty context even though relevant authorized passages ranked just below the global top-k.
  • A single bug in the downstream filter becomes a direct data leak.

The filter should be part of the index query so the search ranks only the authorized set. Fields used on every query need payload indexes. Qdrant also recommends strict mode to reject some inefficient operations on unindexed fields.

Where permissions usually break

**Chunking drops the ACL.** The document header is marked restricted, while chunks contain only text and embeddings. An ingestion gate should reject any chunk missing mandatory access fields or carrying metadata inconsistent with the document registry.

**A removed group remains in the index.** An ACL change in the file system does not automatically reach a vector database. The pipeline needs change events, idempotent upserts, and periodic reconciliation. Teams should measure the longest interval during which a revoked grant remains searchable.

**Caches mix users.** Query, context, and answer cache keys must include `tenant_id`, a normalized permission set, and `policy_version`. Otherwise an answer cached for a director can be served to an employee asking the same question. Permission changes must invalidate matching keys.

**The service uses a privileged identity.** PostgreSQL notes that table owners and roles with `BYPASSRLS` can bypass row-level security. The same issue appears when a RAG backend uses a vector database administrator key. Its runtime role should have read-only access to the required collections; administration should use a separate control path.

**The prompt asks for broader access.** Instructions such as “show me the other department’s files” must not influence the authorization decision. Policy is built from verified session attributes, not from intent inferred by the model.

Shared collection or isolated environment

There is no universal answer for a small business.

A shared collection with a mandatory tenant filter costs less to operate when many small departments or customers share the same schema. It requires disciplined metadata, indexed filter fields, and cross-tenant leakage tests.

A separate collection or instance is justified when:

  • a contract or regulation requires physical separation;
  • the customer needs independent backup and deletion policies;
  • one tenant’s volume and load are materially different;
  • the impact of a filtering mistake is unacceptable.

A hybrid approach keeps ordinary data on a shared platform and places the most sensitive corpus in a dedicated environment. A local LLM can operate beside both, but the authorization gateway remains mandatory.

How to test the design before buying infrastructure

A pilot can start with one department, three access levels, and 100–150 labeled questions. The evaluation set must include prohibited retrieval attempts, not only answerable questions:

  • a direct request for a forbidden document;
  • an innocent query semantically close to restricted content;
  • a group change during an active session;
  • access revocation followed by queries before and after reindexing;
  • the same question asked by two roles;
  • missing or corrupted ACL fields;
  • a prompt instruction to ignore restrictions.

Minimum metrics include:

  • forbidden chunks reaching the reranker or model, with a target of zero;
  • retrieval recall over authorized sources;
  • correct denials that do not reveal restricted document names;
  • maximum access-revocation delay;
  • filtered retrieval p95 latency;
  • chunks with missing or stale ACL versions;
  • cross-role cache hits.

Zero leakage in a small sample is not certification. It does, however, show whether every layer actually enforces access control or the team is relying on a system prompt.

The economics

The main cost is not the model. It is the metadata lifecycle: connecting sources, synchronizing groups, reindexing, policy testing, audit, and incident investigation. It is usually more economical to begin with a coarse, understandable model such as `tenant + department + classification` than to implement dozens of exceptions immediately.

A pilot can use a model calculation for cost per accepted answer:

`(infrastructure + development + permission maintenance + human review) / useful answers without an access violation`.

If a complicated policy saves a few minutes of search but requires manual maintenance for every group, the automation may not pay back. If the same protected index supports customer service, sales, and internal procedures, however, investment in a shared authorization layer is distributed across several use cases.

The practical next step

Take one real document source and export a table with document, owner, allowed groups, classification, modification date, and responsible person. Create chunks that inherit those fields, configure a default-deny filter, and run a matrix of role × question × expected sources.

Move to a broader RAG rollout only after four conditions are met: forbidden chunks never reach the model; revoked access propagates to the index and cache within a measured bound; every answer cites authorized sources; and the audit log can reconstruct the decision without copying confidential text. This gateway is less impressive in a demo than a fluent chatbot, but it is what turns document retrieval into a dependable business service.