Document-Level Access Control in RAG: Preventing Data Leaks in Vector Databases

A vector database will happily hand a salary spreadsheet to someone who has no business seeing it, as long as the spreadsheet is semantically close enough to the question. Nothing breaks. No error fires. The retrieval call succeeds, the model writes a fluent paragraph, and the wrong person reads it. That’s the failure mode you’re building against, and it’s quieter than almost any other security bug you’ll ship this year.

Most teams reach for RAG as a relevance problem: turn a question into a vector, pull back the nearest chunks, drop them into the context window. That part works well.

What it skips is a second question that has nothing to do with semantics, is this specific person, right now, allowed to see this specific document? A HNSW index has no concept of an org chart, a revoked share, a legal hold, or a tenant boundary. It only knows distance. If nobody enforces the permission decision before the chunk reaches the prompt, similarity search becomes an access-control bypass with a chat interface bolted on.

OWASP formalized this in its 2025 Top 10 for LLM Applications as LLM08:2025 — Vector and Embedding Weaknesses, which explicitly flags unauthorized access and cross-context leakage in shared, multi-tenant vector stores as a named risk category, and recommends permission-aware vector stores and logical partitioning as mitigations. If you’re shipping RAG against anything more sensitive than public documentation, this isn’t an edge case to note in a backlog ticket, it’s a design constraint from day one.

The line to hold: semantic retrieval answers “what’s relevant?” Authorization answers “what may this principal see?” A production RAG system has to answer both, separately, and it cannot let the first one stand in for the second.

Telling the model “don’t reveal confidential information” doesn’t fix this. By the time the model is reading a chunk, the chunk has already crossed the boundary that mattered. Prompting is a content-generation control. Access control is a retrieval-boundary control. They operate at different points in the pipeline, and only one of them can actually stop a leak before it happens.

What "document-level access control" actually means

Document-level access control means every retrievable document, and every chunk cut from it, carries an authorization identity, and that identity gets checked against the authenticated caller before the chunk is allowed into the model's context window. The thing being protected is the source document, not the chunk in isolation.

A chunk is a derivative; it inherits its permission state from the document it came from, the same way a cached copy of a file inherits the permissions of the original rather than getting its own independent set of rules.

That inheritance relationship is where most of the operational pain in this problem actually lives, so it's worth writing down as a small data model before touching any specific vector database's filter syntax:

Two of those rows do most of the damage when they're missing. If a chunk doesn't carry a stable document_id pointing back to its resource, you can't reliably find every chunk that needs to disappear when the source document is deleted or its permissions change, you end up grepping metadata and hoping.

And if the Decision isn't recorded separately from the request, you can prove what your application asked for, but not what actually got enforced. Those are different facts, and conflating them is how "we logged the query" turns into "we have no idea what that user could see last Tuesday" during an incident review.

How to Implement Document-Level Authorization in RAG (To Prevent Data Leakage)?

To prevent sensitive data leakage in Retrieval-Augmented Generation (RAG), developers must enforce pre-retrieval access control rather than post-generation filtering:

1. Attach ACL Metadata to Embeddings: Store user IDs, tenant identifiers, and permission tags directly alongside document chunks in your vector database.
2. Authenticate User Identity (JWT/OAuth): Extract verified permission claims and security groups from the user's active session token.
3. Execute Pre-Filtered Vector Queries: Apply strict metadata filters at the query layer (e.g., WHERE tenant_id = 'acme' AND role IN ('engineering')) so unauthorized chunks are never fetched.
4. Context Window Boundary Checks: Double-verify retrieved chunks against the authorization service before assembling the final context injected into the LLM prompt.

ACL, RBAC, ABAC, ReBAC: four ways to answer the same question

"ACL" gets used as a catch-all in casual conversation, but it's really one of four distinct ways to model who can read what. Picking among them is a modeling decision about your organization's actual permission shape, it has nothing to do with which vector database you chose.

Real systems rarely pick exactly one. A document might belong to a tenant (hard boundary), inherit visibility from a workspace (ReBAC-shaped), and carry a classification: restricted attribute that further narrows who can read it even inside that workspace (ABAC-shaped). That's fine, what actually matters is that there's one authoritative decision path for "can this principal read this document," not four slightly different boolean checks scattered across four different features because four different engineers each solved the problem locally.

Three ways to enforce it at retrieval time

Once you know what model you're using, you still have to decide where the check happens relative to the vector search itself. In practice, teams converge on one of three patterns, and they're not mutually exclusive.

Pinecone's own walkthrough of RAG with access control and Databricks' write-up on ACL and metadata filtering for a RAG chatbot are both worth reading end-to-end as concrete, platform-specific implementations of the first pattern below, useful for seeing the mechanics, though the design principles underneath travel across vector stores.

1. Authorization-aware query filtering

The application authenticates the caller, resolves what they're allowed to see, and attaches that as a metadata filter on the vector query itself, so the search only ever considers records the caller is entitled to.

Pinecone's current documentation on filtering by metadata, for example, supports filter operators including $eq, $ne, $gt, $gte, $lt, $lte, $in, and $nin, combinable with Boolean logic, so a query can be scoped to tenant_id, allowed_groups, or a classification field in a single call.

That's solid infrastructure, but notice what it doesn't give you for free: the filter is exactly as trustworthy as the code that builds it. If the client is allowed to send its own tenant_id value, you don't have access control, you have a suggestion box.

request
  -> authenticate principal
  -> resolve authorization (server-side, from trusted identity claims)
  -> construct the metadata filter
  -> query only within that scope
  -> re-verify resource identity on the way back
  -> generate response

The filter has to be built from identity claims and a policy decision the server controls, never from anything the client submitted directly. Trusting a client-supplied tenant_id=customer-17 field is the single most common way this pattern quietly turns into a vulnerability.

Here's what that looks like as actual code, the filter is built entirely from a verified token, and the request never gets a chance to supply its own scope:

Python:

# The filter comes from the verified token, never from the request body.
# A tenant_id or role sent by the client is never trusted here.
user_claims = auth_service.verify_token(request.headers["Authorization"])

query_response = index.query(
    vector=query_embedding,
    top_k=5,
    filter={
        "tenant_id": {"$eq": user_claims["tenant_id"]},
        "allowed_groups": {"$in": user_claims["roles"]},
    },
    include_metadata=True,
)

If the vector store sits inside PostgreSQL, pgvector is a common choice, the same principle can be pushed down to the data layer itself, so the filter is enforced by the database and not just by application code that a future developer might forget to call. This uses the syntax and default-deny behavior documented in PostgreSQL's row security policies:

SQL: 

-- Vectors live in an ordinary table; RLS applies to it like any other table.
ALTER TABLE document_chunks ENABLE ROW LEVEL SECURITY;

-- The app sets this once per connection/session, from a verified identity,
-- never from a value read directly out of the request.
-- SET app.current_tenant_id = 'acme-corp';

CREATE POLICY tenant_isolation ON document_chunks
    USING (tenant_id = current_setting('app.current_tenant_id', true)::uuid);

Neither snippet is a complete authorization system on its own, they're the enforcement point, not the policy engine deciding what user_claims["roles"] or app.current_tenant_id should be. Where that decision comes from is a separate question, covered below.

2. Namespace or partition isolation

A dedicated namespace, collection, or index creates a stronger boundary than a shared index with an optional filter, because there's no shared search space to filter out of in the first place. Pinecone's own guidance on implementing multitenancy recommends one namespace per tenant as a standard pattern for isolating tenant data in a serverless index.

This works well when tenant data is naturally siloed and cross-tenant search is never needed. It simplifies offboarding, delete the namespace, the tenant's data is gone, and it removes an entire class of "the filter had a bug" incidents. What it does not do is solve document-level authorization inside a tenant.

A namespace answers "is this Acme Corp's data," not "can this specific Acme Corp employee read the Legal team's contracts." Those are different boundaries protecting against different threats: tenant isolation keeps customers apart from each other; document authorization keeps people apart within the same tenant. Conflating the two is a recurring design mistake, a system can get the namespace exactly right and still leak internally.

Namespace isolation also has a cost curve: if the same document needs to be visible to many differently-scoped user groups, you can end up replicating it into multiple namespaces just to make the boundary work, which adds storage and sync overhead you wouldn't have with a shared index and a filter.

3. Policy decision plus post-retrieval verification

A separate policy service evaluates relationships or attributes that the vector store's metadata can't easily express, and candidates are checked against that decision before anything reaches the model. This earns its complexity when the permission model is genuinely relational, nested groups, delegated ownership, time-bound access, and doesn't compress cleanly into a metadata filter.

Paragon's comparison of permission protocols for production RAG apps lays out this trade-off well: tool-calling with user credentials, dedicated namespaces, an ACL database, and a full ReBAC graph each show up as a distinct point on the same spectrum, not competing "correct" answers.

This is also the pattern where it's worth knowing the standing tooling landscape rather than hand-rolling a policy engine from scratch. Two lineages dominate:

• Relationship-based engines, modeled on Google's internal Zanzibar system: OpenFGA (a CNCF Incubating project maintained by Okta and Grafana engineers) and SpiceDB express permissions as relationship tuples, "user:alice is a reader of document:123, which is inside org:acme", and answer both "can this user read this document" and the reverse "which documents can this user read" queries efficiently. OpenFGA's own documentation for agent and RAG patterns frames securing retrieval-augmented generation and restricting agent access to tools as a named use case, not an afterthought.
• Policy-as-code engines: Open Policy Agent (OPA) evaluates declarative Rego policies against request context and is commonly run as a sidecar decision service; Oso and Cerbos take a similar policy-as-code approach with different tradeoffs on embedding versus running as a standalone service. These fit ABAC-style rules, clearance level, geography, time-of-day, better than deep relationship graphs.

None of these tools understands vector search. They answer "is this allowed," full stop, your retrieval layer still has to call them, get a set of authorized resource IDs (or a yes/no per candidate), and apply that before generation. The value they add over hand-written if statements is centralizing the policy, making it independently testable, and giving you an audit trail of the decision logic itself, separate from the retrieval code that consumes it.

The part teams get wrong here is treating "post-retrieval" as "post-response." If a candidate chunk is retrieved, logged, cached, or handed to a reranker before the policy check runs, you've already let unauthorized content cross a trust boundary, even if it never makes it into the final answer the user sees. In a high-sensitivity system, "post-filter" has to mean the record is rejected before any untrusted or generative component touches it, not merely trimmed from the output at the last step.

None of these three patterns is universally "more secure", the trade-off is conditional on your vector store's actual execution semantics, which you have to verify per provider rather than assume.

Strict filters can break the search algorithm, not just slow it down

There's a mechanical problem hiding underneath all three patterns that's easy to miss until it shows up in production: an authorization filter that excludes most of the index doesn't just narrow the result set,  it can degrade the ANN algorithm itself.

HNSW, the graph-based index most vector databases build on, navigates by traversing edges between nearby points. When a filter removes the majority of a query's candidate neighbors, the graph traversal can hit long stretches with nothing left to move to.

Milvus's own engineering documentation describes this plainly: HNSW graph traversal cannot directly incorporate filtering conditions, and once the filtering ratio gets high enough, its docs cite roughly 90%+, the remaining graph fragments into isolated pockets, and search degrades toward something worse than a brute-force scan.

This matters directly for document-level ACLs, because a tenant- or department-scoped filter is exactly the shape of filter that tends to be strict: if a user can see 2% of a large shared index, that's a high-selectivity filter working against the graph, not a gentle narrowing of results.

Engines take different approaches to this, and it's worth knowing the vocabulary even if you're not choosing between them today:

1. Qdrant builds its HNSW graph with extra filter-aware edges, a "filterable HNSW",  so that a subgraph of points matching a given payload value stays connected even after the rest of the graph is excluded. Its query planner picks between full HNSW traversal, a payload-index-only scan, or a hybrid depending on measured filter selectivity, and Qdrant's own indexing documentation notes that when two or more strict filters combine, the extra edges may still be insufficient, at which point it falls back to the ACORN algorithm, which explores second-hop neighbors when direct neighbors are filtered out.
2. Milvus defaults to pre-filtering: it evaluates the scalar (metadata) expression first, builds a bitmask of matching entries, and restricts the ANN search to that bitmask. For unusually complex filter expressions, it offers an iterative-filtering mode that processes candidates one at a time rather than filtering the whole set up front, trading throughput for lower per-query filtering cost.
3. Pinecone avoids the pre-filter/post-filter split entirely for its serverless architecture by integrating the metadata index directly into the retrieval path rather than running it as a separate step, described in Pinecone's own research on its serverless metadata filtering design as a way to get pre-filtering's accuracy without pre-filtering's brute-force cost.
4. pgvector (as of 0.8.0) added an iterative index scan, which behaves like a post-filtering approach at the database level: it keeps requesting more candidates from the index until enough survive the WHERE clause.

The practical takeaway: if your authorization model produces highly selective filters,  a small tenant on a large shared index, a narrow department scope, don't assume default HNSW settings will hold up. Check whether your vector store exposes a filter-aware index mode, benchmark recall and latency at your actual filter selectivity (not at 10% filtered, if your real filters exclude 90%+), and revisit namespace-per-tenant (Pattern 2 above) as an alternative when a shared index's filtered search degrades past what's acceptable, sidestepping the graph-fragmentation problem is one of the underappreciated reasons namespace isolation exists, beyond the security boundary it also provides.

A logical filter is not a hard boundary — don't let the two get confused

This is the distinction that causes the most expensive mistakes, so it deserves its own section instead of a footnote. AWS's architecture guidance on securing multi-tenant RAG with Amazon Bedrock and Verified Permissions draws a sharp line: metadata filtering gives you granular access control within a shared knowledge base, but a shared index with a filter is a different security posture from separate infrastructure per tenant, and the two shouldn't be described interchangeably.

A tenant-boundary pattern documented in AWS's guide to access control for vector stores using metadata filtering even states this plainly in its own architecture notes: isolation enforced purely through a metadata tag is logical, not physical, because every tenant's vectors still live in the same index and the same underlying store.

Don't market a shared index with a good filter as "physically isolated" unless your provider's current documentation defines exactly that guarantee for your deployment shape. And don't assume a separate namespace has automatically solved authorization, it solved one boundary. A namespace can be perfectly correct and a document inside it can still be visible to someone who shouldn't see it.

Permission freshness is a security property, not a sync nicety

Here's a scenario every team building enterprise RAG eventually hits: a document gets shared with a project group on Monday. It gets removed from that group on Tuesday. If the vector record still carries Monday's permission metadata, the system keeps exposing the document after the access was revoked, and nothing about the retrieval call looks wrong, because as far as the filter is concerned, the metadata says it's still allowed.

A production ingestion pipeline needs an explicit permission lifecycle, not just a parser and an embedding call:

1. Identify the source resource and its current permission state at ingestion time.
2. Attach a stable resource identifier to every chunk derived from it.
3. Resolve the permissions actually needed to make a retrieval decision, don't just copy a snapshot and forget it.
4. Detect source-side changes: moves, deletions, revocations, group membership changes.
5. Propagate those changes to affected chunks and any caches downstream.
6. Record which policy or permission revision was used for each retrieval decision.
7. Test the actual window between a source change and the index reflecting it.

This isn't a theoretical gap, AWS's own reference architecture for multi-tenant Bedrock RAG explicitly calls out a residual ingestion race window between document upload and the creation of the metadata used to filter it, and recommends pipeline-level safeguards rather than assuming the metadata is present the instant the document lands.

The numbers behind that gap are worth internalizing even outside AWS: the reference architecture's event queue uses a 30-second batching window before metadata gets written, and its API-layer authorization cache defaults to a 300-second TTL, meaning a revoked permission can keep working for up to five minutes unless that cache is explicitly shortened or invalidated on revocation.

Those are two independently tunable knobs, and treating either default as "good enough" without checking it against your own revocation SLA is exactly how a freshness gap turns into an incident. The safest default while metadata is missing, malformed, or stale past your defined threshold is to exclude the record. That costs you some recall temporarily. Returning a document nobody authorized costs you a great deal more.

A newer, more concrete example of freshness being treated as a first-class requirement: Microsoft's current documentation on document-level access control in Azure AI Search is explicit that permission changes made in the source system, a Microsoft Entra group membership change, an ADLS Gen2 ACL update, a Purview sensitivity-label reassignment, only take effect in search results once that metadata is re-synchronized into the index, and it documents the actual sync mechanism per source type.

For SharePoint specifically, changes to permissions set directly on an item are picked up incrementally on each indexer run as of the 2026-05-01-preview API, while permissions inherited from a parent site, library, or folder require an explicit refresh rather than being picked up automatically.

That's a useful pattern to study even if you're not on Azure: it names the exact propagation mechanism per source type instead of a blanket "permissions sync eventually" statement, and it's a fair model for what your own freshness documentation should look like, this feature is a preview API as of this writing, so treat the specific mechanics as version-sensitive if you build against it.

Fail closed, every time the pipeline is uncertain

A fail-closed design denies retrieval, returns nothing rather than everything, whenever the authorization service is unreachable, the principal isn't authenticated, tenant context is missing, resource metadata can't be trusted, or the filter can't be safely constructed. An empty result set is an inconvenience. Silently falling back to an unfiltered search across the whole index is a breach.

This has to be built into the enforcement point itself, not documented as a runbook step someone follows during an incident. Concretely, test each of these:

Database-native controls illustrate why the enforcement location matters more than the label you give it. PostgreSQL's own documentation on row security policies states plainly that when row-level security is enabled on a table and no policy applies, a default-deny policy takes effect, no rows are visible or modifiable, with documented exceptions for table owners and roles carrying the BYPASSRLS attribute.

That doesn't make RLS a drop-in fix for every pgvector deployment. It means a policy attached at the data layer fails differently, and generally more safely, than an optional filter parameter that every single call site has to remember to include correctly.

Blocking the content isn't enough — the denial itself can leak

Stopping an unauthorized chunk from reaching the model is necessary but not sufficient. A system can enforce every authorization check correctly and still hand an attacker useful information through how it refuses.

The clearest version of this: a user asks about a manager's salary, has no access to salary_2025.xlsx, and the system replies "you don't have permission to view salary_2025.xlsx." The content was protected. The existence of the file, its name, and the fact that it's salary-related were not, and for a lot of threat models, that's already the sensitive fact.

OWASP's RAG Security Cheat Sheet makes a related point directly in its guidance on query injection via retrieval: it explicitly advises against returning similarity scores to the user or agent, because scores can be used to map the corpus structure through differential analysis, an attacker who can't read a document can still learn a great deal from how close their queries land to it, probed systematically over many requests. The same cheat sheet's guidance on rate limiting and query-pattern monitoring exists largely to catch exactly this kind of systematic corpus probing.

A few concrete defenses, roughly in order of how cheaply they retrofit into an existing system:

1. Uniform denial responses. "I don't have information to answer that" should look identical whether the underlying reason is "no relevant document exists" or "a relevant document exists and you can't see it." Don't let the error path be more specific than the success path.
2. Don't expose similarity scores or ranks to the caller unless there's a specific product reason to, per the OWASP guidance above, they're a measurable side channel, not just a UX nicety.
3. Rate-limit and monitor for probing patterns, not just raw request volume, many small variations on a query, converging on a topic, is a reconnaissance signature worth alerting on.
4. Treat timing as a real, if minor, channel. A retrieval path that does noticeably more work when a match exists behind a permission boundary than when no match exists at all is a timing side channel in miniature. It's rarely worth the engineering cost of full constant-time retrieval, but it's worth knowing the theoretical gap exists rather than assuming a correct filter is a complete defense.

None of this replaces the access-control layer discussed above, it's the layer around it. A perfectly enforced filter that leaks through error messages, scores, or timing has still leaked; it's just leaked more slowly and required more effort from whoever's on the other end of it.

What to log: the decision, not just the request

An audit trail that only records the user's query and the filter your application intended to send is missing the fact that actually matters during an investigation: what got enforced. "What did we ask for" and "what did we actually authorize and return" are two separate facts, and treating them as one is exactly the gap that turns a routine incident review into a shrug.

A useful retrieval audit record answers both questions:

Design this with retention and privacy in mind, you're not trying to build a second copy of every sensitive document in your logs. Stable IDs, decision metadata, and a controlled replay path get you auditability without turning your log store into a second attack surface.

Test it like an attacker, not like a happy path

A system that answers correctly for an authorized user has proven nothing about how it behaves for an unauthorized one. Authorization testing has to be adversarial by default, or it isn't really testing the thing that matters.

Build a test corpus with near-identical documents split across tenants, departments, and access levels, same topic, different sensitive numbers, different customer names, different classification labels, and run the same questions through different principals. Semantic similarity should never be allowed to paper over an authorization boundary.

Track authorization correctness, unauthorized-retrieval rate, policy freshness, and how much your filtering actually costs legitimate retrieval recall. Resist the urge to promise a fixed latency or recall number in a doc, that number depends entirely on your vector engine, filter selectivity, index design, and workload, and a hard-coded claim will be wrong for someone else's deployment.

Building a decision, not just picking a database

Use the simplest design that actually satisfies your threat model, but don't simplify away the parts of the threat model that are inconvenient.

Reach for a separate namespace or dedicated resource when the requirement is a hard tenant boundary, cross-tenant search is genuinely never needed, and your provider documents the exact isolation guarantee you're relying on.

Reach for metadata or policy-derived filters when users inside the same tenant need different visibility and your vector store can enforce that filter reliably at query time.

Reach for an external authorization service when permissions are relational, inherited, or change often enough that hand-maintained metadata will drift. Reach for live source-system API retrieval when preserving the source system's own authorization semantics matters more than the latency cost of a live call on every request.

Most mature enterprise systems end up layering these: hard tenant routing first, policy-derived document filtering second, a final resource-level verification before anything is admitted to the model's context. The more layers you stack, the more critical it becomes that there's one authoritative source of truth behind them, and that every layer is tested to fail closed rather than silently defer to the layer next to it.

Since the choice of engine shapes which of these patterns is cheapest to implement well, here's a starting-point comparison of how four commonly used stores approach the problem. Treat this as a starting point for your own evaluation, not a final answer, verify current behavior against each provider's documentation before committing, since filtering internals are an active area of development across all four:

This isn't an exhaustive list, Milvus, Weaviate, Chroma, and others make similar trade-offs with their own specifics, and it isn't a ranking. The right row depends on what you're already running, how your permission model is shaped, and how selective your filters actually are, which is a question the earlier section on ANN filtering performance can help you answer for your own data.

Before you call it done: a production checklist

And write down what your design does not guarantee, on purpose. A metadata filter is not automatically physical isolation. A namespace is not automatically a complete enterprise authorization model. A policy engine does not automatically stay in sync with source-system permission changes on its own. And a system prompt telling the model to behave is not a substitute for stopping the wrong chunk before it ever reaches the model.

The architecture that actually holds up in production isn't "an LLM that's been told to be careful with confidential information." It's an identity-aware retrieval layer that never hands the model anything the requester wasn't already entitled to see. Everything else, prompting, output filtering, content moderation, is a second layer worth having, but it's not the layer doing the actual work.

About The Author

A Gadallh

Ahmed Gadallah is the Founder and Editor of Vertex Frontier, where he publishes research-driven articles on AI, data science, cloud computing, cybersecurity, software engineering, and emerging technologies, with a focus on technical accuracy, clarity, and practical insights.

View all articles by A Gadallh →