Authorization-Aware RAG: Enforce Access Control Before Retrieval

Retrieval-augmented generation can disclose protected information even when the final answer looks harmless. Search results may enter prompts, traces, caches, evaluation datasets, or citations before a model decides what to say. Authorization must therefore constrain retrieval itself—not merely filter generated text.

The core rule is simple: determine what the caller may access using an authoritative policy, then search only within that boundary.

Carry Identity and Context Into Retrieval

A RAG request needs more than a query string. It should carry a verified principal, tenant, roles or attributes, purpose when relevant, and request context such as device or network posture.

Do not trust tenant IDs or document filters supplied only by the model. The application should derive them from authenticated session state and pass a signed or server-side authorization context to the retrieval layer.

const scope = await policy.allowedScope({
  principal: session.userId,
  tenant: session.tenantId,
  action: "document.read",
  context: requestContext
});

const hits = await index.search(query, { filter: scope.filter });

The model may suggest a query, but it never expands scope.filter.

Enforce Permissions Before Ranking

Post-filtering the top results is both unsafe and ineffective. If the vector database retrieves unauthorized documents first, their content may already be exposed to logs or middleware, and removing them can leave too few useful results.

Apply access filters inside the search operation when supported. For highly sensitive systems, separate indexes or namespaces can reduce cross-tenant risk. Replicate permission changes promptly and fail closed when the authorization service is unavailable.

Metadata is security-critical. A document with a missing tenant or classification field should not default to public. Ingestion must validate ownership and access labels before indexing chunks.

Recheck at Use Time

Permissions can change after indexing or between retrieval and action. Re-authorize documents before adding them to the prompt when the cost is acceptable, especially for long-lived sessions or high-risk data.

Treat citations and source previews as disclosures too. A link title, snippet, or filename can reveal confidential facts. The UI should render only sources the current viewer can still access.

Agents that act on retrieved data need a separate authorization decision for the action. Permission to read an invoice does not imply permission to refund it.

Partition Caches and Observability

Cache keys must include every authorization dimension that changes results: tenant, principal or permission fingerprint, policy version, and relevant context. A global cache keyed only by normalized question can return one user’s answer to another.

Prompt traces, retrieved chunks, and model outputs inherit the sensitivity of their inputs. Redact where possible, encrypt storage, restrict operator access, and use short retention. Evaluation exports must preserve access boundaries instead of creating a shadow corpus.

Invalidate cached results when permissions change. If immediate invalidation is difficult, use short time-to-live values and verify access again before display.

Test the Boundary, Not Just Answer Quality

Build adversarial tests with two tenants, overlapping terminology, revoked permissions, malformed metadata, cache hits, and policy-service outages. Assert that unauthorized document identifiers never reach prompts, traces, citations, or responses.

Test horizontal access between peer users and vertical access between roles. Include indirect prompt injection that asks the model to remove filters or call retrieval tools with a different tenant.

Log authorization decisions with policy version and resource identifiers, but avoid logging sensitive content. Monitor denied retrieval attempts, missing labels, cross-tenant cache keys, and stale-policy errors.

Authorization-aware RAG is an architecture property, not a prompt instruction. When identity, policy, retrieval, caching, and observability share the same boundary, the model can be useful without becoming an alternate path around the permissions the rest of the product already enforces.