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

A search result can be relevant to a question and still belong to another customer's private workspace. That is the authorization problem a RAG pipeline has to solve before returning content to the user or a model provider.

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

The anti-patterns below describe implementation failures. They do not depend on the model following a malicious instruction; ordinary questions can expose a broken retrieval boundary.

Why RAG Authorization Is Easy To Get Wrong

A typical RAG pipeline looks straightforward:

User query
  -> embed query
  -> search vector store
  -> retrieve similar chunks
  -> inject chunks into LLM context
  -> generate answer

The problem is that similarity search does not know what a user is authorized to see unless authorization metadata is enforced at retrieval time.

A chunk can be semantically relevant and still unauthorized. That is the core failure mode.

Anti-Pattern 1: Prompt-Based Authorization

Bad pattern:

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

Why this fails:

Better pattern:

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.

Anti-Pattern 2: Metadata Filters That Are Optional

Many RAG implementations rely on metadata filters such as:

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

That is fine only if the backend makes those filters mandatory.

Risky patterns include:

Authorization filters should be constructed by trusted server-side code, not by the user, model, browser, or prompt.

Anti-Pattern 3: Shared Vector Index With Weak Partitioning

A shared index can work, but it increases the cost of correctness.

A stronger design uses:

Anti-Pattern 4: Authorization Checked At Upload, Not Retrieval

A common mistake is assuming that if a document was valid when indexed, it remains valid forever.

Access changes. Documents are deleted, reclassified, reassigned, transferred, archived, superseded, or restricted.

RAG authorization must be evaluated at retrieval time, not only ingestion time.

Anti-Pattern 5: No Chunk Lineage

A chunk without lineage is a security liability.

Every retrieved chunk should preserve:

Without chunk lineage, you cannot confidently prove whether a response was generated from authorized, current, trusted content.

Anti-Pattern 6: Treating Embeddings As Non-Sensitive

Embeddings are sometimes treated as harmless because they are not the original text.

That assumption is weak.

Treat the vector store as a sensitive data system.

Anti-Pattern 7: No Negative Tests

Positive tests exercise permitted retrieval. Negative tests exercise the requests that must be denied. Passing a finite suite supports a scoped conclusion; it does not prove that no bypass exists.

A RAG system without negative tests is not production-ready.

Secure RAG Authorization Model

Use this design pattern:

User identity
  -> tenant / role / resource policy resolution
  -> server-side retrieval filter construction
  -> vector search over authorized scope only
  -> source attribution and chunk lineage
  -> LLM generation
  -> output policy check
  -> retrieval + generation audit log

Key rule:

The model should never see content the user is not authorized to retrieve.

RAG Authorization Checklist

What A RAG Authorization Review Should Leave Behind

The review should show where retrieval permissions are enforced and which denied paths were actually exercised before model context was assembled.

Test stale permissions, not only the first query

Run a permitted search, revoke the document ACL, and try to reuse the result through the context builder, citation renderer and any answer cache. The version that passes the first search but returns a stale citation after revocation still has a gap.

A trusted retrieval service may rank candidate IDs before a final authorization check, provided unauthorized content and metadata never escape its protected boundary. If an external reranker or model sees the chunks, authorization must already have happened. The local two-tenant walkthrough makes that distinction explicit.

Sources

• OWASP 2025 LLM Top 10
• OWASP AI Agent Security Cheat Sheet