Enterprise retrieval systems fail trust quickly. A single document from the wrong customer, department, jurisdiction, or case can make an otherwise accurate answer unacceptable. The risk is not limited to the final prompt. Source files, chunks, embeddings, metadata, indexes, caches, logs, backups, and evaluation datasets all carry tenant context.
Isolation is therefore an end-to-end property. The diagram above places identity and policy before retrieval, then adds a second context gate before any text reaches the model. That double boundary matters because a vector database filter is useful, but it is not a complete authorization system.
Write the threat model in retrieval terms
Start with concrete failure cases: a user guesses another tenant’s document identifier; an application forgets a metadata filter; a stale group membership grants access after transfer; an administrator exports an index snapshot; an evaluation job mixes production samples; or a cache returns context created under a different policy. Include support staff, background jobs, model tools, and analytics pipelines—not only end users.
Map each case to prevention, detection, and recovery. Prevention may be a physical index boundary or server-generated filter. Detection may be a canary document or an audit query. Recovery includes revoking access, invalidating cached results, deleting derived embeddings, and identifying every response that used the exposed content.
Choose an isolation model deliberately
A dedicated database or index per tenant provides the clearest boundary and straightforward deletion, but increases provisioning and operational overhead. A shared index with tenant namespaces reduces that overhead while relying on the platform and application to preserve the namespace on every operation. A pooled index with metadata filtering is efficient at scale, but a missing or malformed filter can become a direct cross-tenant exposure.
There is no universal winner. Use stronger physical separation for regulated, high-value, or contractually isolated tenants. Use pooled designs where scale and cost justify them, but compensate with row-level enforcement, server-side query construction, negative tests, and evidence that administrators cannot bypass policy casually. Document the trade-off so future optimization does not weaken the boundary by accident.
Bind identity to retrieval on the server
The client should submit the question, not its own authorization filter. Resolve the authenticated principal to trusted tenant, role, group, document grants, purpose, region, and data-classification claims. A policy decision point turns those claims into a retrieval scope. The application then constructs the database query from that decision and rejects requests that do not produce an explicit allow.
Record the principal, policy version, decision, and resulting scope. For long-running conversations, re-evaluate authorization instead of assuming the permissions from the first turn remain valid. Short-lived tokens limit exposure, but they do not replace policy checks when a user’s role or a document’s classification changes.
RBAC is necessary but often not sufficient
Roles express broad capability: employee, analyst, clinician, support engineer. Retrieval usually needs attributes as well: tenant, department, project, geography, case assignment, confidentiality level, and purpose of use. Combine role-based and attribute-based policy so “may search documents” does not become “may search every document in the tenant.”
Document-level access should travel with every derived chunk. When a source is reclassified, moved, or revoked, update or remove its vectors and invalidate caches. Keep source document identifiers in retrieval results so the context gate can re-check access before assembling the prompt. This protects against stale metadata and index-processing defects.
Control sensitive data before embedding
Embeddings are derived data, not anonymous data by definition. Minimize first: exclude fields the use case does not need. Mask or tokenize direct identifiers before chunking when they are not required for retrieval. Preserve the mapping in a more strongly controlled system if authorized users need to see the original value later.
Encrypt source content, vectors, metadata, caches, and backups according to the same data classification. Separate keys where the threat model requires it. Retention and deletion workflows must cover derived objects, not only the original file. A verified deletion process should locate chunks, embeddings, cached answers, exports, and evaluation copies tied to the source.
Add a context gate after retrieval
Similarity search can return surprising neighbors, and metadata can be stale. Before retrieved text reaches the model, verify each source against the active policy decision. Remove disallowed chunks, apply output-specific masking, enforce a maximum classification level, and fail closed if provenance is missing. The model should never be asked to ignore information it was not authorized to receive.
Apply the same discipline to citations and follow-up links. A response that hides restricted text but exposes a confidential document title or signed download URL still leaks information. Generate links through an authorization-aware service and keep their lifetime short.
Test denial paths continuously
Positive tests prove that permitted retrieval works. Isolation depends on negative tests: tenant A cannot retrieve tenant B; a revoked user loses access; an injected tenant filter is ignored; a background job cannot exceed its service role; cached context does not survive a policy change; and an index restore preserves the intended boundary. Run these tests against every query path, including autocomplete, summaries, exports, and administrative tools.
Seed non-sensitive canary records with recognizable tenant markers and alert if they appear outside their authorized scope. Review audit logs for unusually broad retrieval, repeated denied queries, and administrative exports. Keep logs useful for investigation without copying full prompts and retrieved passages into a second, less-controlled data store.
Produce evidence, not a compliance shortcut
GDPR, HIPAA, and contractual controls cannot be satisfied by selecting a vector database feature. The system needs documented data flows, lawful or permitted use, retention, access review, incident response, vendor assessment, and evidence that technical controls operate as designed. Architecture supports those obligations; it does not replace governance or legal review.
A credible rollout starts with one data class and a small tenant cohort. Validate ingestion permissions, retrieval denial, revocation, deletion, backup handling, cache isolation, and audit evidence before expanding. Enterprise adoption follows when teams can explain—and demonstrate—why data from one boundary cannot cross into another.