Skip to content
Back to insights
RAG SecurityTechnical guide

RAG Authorization Anti-Patterns: When Vector Search Bypasses Access Control

Common RAG authorization failures, tenant-isolation gaps, vector-store access-control mistakes, source attribution issues, and safer retrieval design.

By Kevin O'Connor

Published Last reviewed 5 min read

A search result can be relevant to a question and still belong to another customer's private workspace. A RAG pipeline must resolve that authorization question before returning content to a user, model provider or external reranker.

Trace one document's permissions through ingestion, retrieval, context assembly, citations and caches. Each copy creates a place where the access rule can drift. OWASP's vector and embedding risk guidance identifies inadequate access controls and cross-context leakage as RAG concerns.

The failures below do not require a successful prompt injection. An ordinary question can expose a broken retrieval boundary.

Asking the model to enforce a document ACL

This design crosses the disclosure boundary before it checks permission:

Retrieve all relevant chunks.
Insert chunks into prompt.
Tell model: "Only answer using information this user is allowed to see."

The provider has already received the chunks. A refusal in the final answer cannot undo that transfer, and the model has no reliable way to reconstruct the application's current authorization state.

Resolve identity and permissions in trusted code. A simple retrieval design is:

Authenticate user.
Resolve tenant, role, resource, and document permissions.
Apply authorization filter server-side.
Retrieve only authorized chunks.
Generate answer with source attribution.
Log retrieval decision.

A protected retrieval service can rank candidate IDs before a final authorization check. The requirement is that unauthorized content and metadata do not escape that protected service. If a separate reranker receives the chunks, authorization must happen before that call.

Making filters optional

A record might carry this metadata:

{
  "tenant_id": "tenant_123",
  "classification": "internal",
  "allowed_roles": ["support_admin"]
}

Those fields only help if trusted server code supplies and enforces them. A browser-supplied tenant, a model-selected filter or a missing-filter fallback to broad search creates a bypass. User-editable ACL metadata creates another.

Check every retrieval entry point: chat, direct search, export, citations, background summaries and administrative tools. Reusing one policy function reduces drift, but still test each caller. A helper that applies tenant scope is ineffective when one endpoint does not call it.

Reject missing or inconsistent authorization metadata, or quarantine the document until it can be resolved. Do not silently treat an unclassified document as public.

Treating index separation as the whole control

Separate indexes can limit accidental cross-tenant retrieval when routing and credentials enforce the separation. A shared index can also enforce a defined policy. Neither layout excuses missing document-level checks.

Review who can query each index, choose its namespace, edit metadata or export embeddings. Test the credential and routing code together. A tenant-specific index name is weak protection if one service credential can query every index and accepts the target from the caller.

Public and private material also differ in trust. Even an authorized private document can contain untrusted quoted text. Keep access permission separate from the authority to influence an action.

Freezing authorization at ingestion

A document's permissions change after it is indexed. An employee leaves a matter, a source is reclassified, a customer is offboarded or a file is deleted. The copied chunks must follow the relevant policy.

Define what happens on each change and how long propagation may take. If the system uses a permission snapshot, record its version and maximum permitted age. Decide what retrieval does when the source policy cannot be reached. A silent fallback to stale permissions can defeat an otherwise careful revocation process.

Deletion, legal hold and retention are separate decisions. A retained copy may need to remain inaccessible to ordinary retrieval even when policy requires keeping it. Work with the responsible data owner on those rules rather than treating physical deletion as the only possible control.

Losing the relationship between a chunk and its source

Retain the chunk ID, source document and version, tenant, permission version and ingestion time. Add ownership, classification and trust information where the policy uses them. Preserve that relationship through reranking and context assembly.

A citation should resolve to the same authorized source used in the answer. Recheck access when it is opened; a citation URL or cached preview can become a separate disclosure path after the original query succeeds.

Without this lineage, a reviewer may see an answer but be unable to determine which source version or permission decision produced it. It also becomes harder to remove derived content when a source changes.

Treating the vector store as non-sensitive

Embeddings, document identifiers and metadata can disclose information about the source collection. Treat the index as a sensitive data system even when it does not store plain text.

Restrict query and export access, protect stored data and account for derived records during deletion. Consider what repeated queries or a broad export could reveal. Encryption at rest does not fix an overbroad application credential.

Testing only the permitted search

Use a small set of named identities and documents with deliberately different permissions. Test both the allowed query and the query that must fail:

Change or requestObservation to verify
Tenant A requests Tenant B's documentNo protected content or metadata reaches context, citations, output or an external reranker.
A low-privilege user requests an admin-only documentThe retrieval path enforces the document ACL.
A caller omits or changes the tenant filterTrusted code rejects the request or supplies the required scope.
A permitted document is revokedNew retrieval, cached answers and citation access obey the defined revocation policy.
A document is deleted or reclassifiedDerived copies follow the updated access and retention rules.
A source contains hostile instructionsThe source cannot grant a tool permission; any resulting request receives independent authorization.

Record the actual observation and tested configuration. Passing a finite suite supports a bounded conclusion, not proof that no bypass exists.

Reuse the result after revocation

The most useful next test is often the second query. Run a permitted search, revoke the document ACL, then reuse the result through the context builder, citation renderer and answer cache. A system that blocks new search but returns the cached text still has an access-control gap.

The review should identify where permission is enforced, the paths exercised, and any propagation delay or untested copy. Keep the findings tied to the retrieval policy and source versions. The local two-tenant walkthrough includes a small example of these checks and explains what it does not test.

Sources

For occasional technical updates, get Field Notes by email.