Vector Database Security for RAG: Isolation, Access and Poisoning
A practical guide to securing vector databases used by RAG systems, including tenant isolation, ingestion controls, authorization, poisoning tests and evidence.
Vector databases sit on a deceptively important boundary in retrieval-augmented generation. They do not merely store embeddings. They influence which enterprise records reach a model, which tenant's data appears in a response, and which source an agent trusts before it calls a tool. A conventional database review is necessary, but it does not answer the complete security question: can an attacker manipulate retrieval so that an AI system sees, reveals or acts on information it should not?
This guide explains how to assess vector database security as part of the complete RAG implementation. It covers architecture, identity, tenant isolation, ingestion, poisoning, deletion, evidence and realistic adversarial testing. The goal is not to treat a particular database product as inherently safe or unsafe. It is to verify the security properties of the deployment around it.
Start with the retrieval architecture
Draw the path from source to answer. Include document stores, connectors, queues, parsers, chunking, embedding services, indexes, namespaces, metadata filters, rerankers, caches, prompt assembly and the user-facing application. Record every identity used along the path and the point at which user and tenant authorization is enforced.
This map often reveals that the vector store is only one enforcement point. A connector may copy documents with broader permissions than the original source. A service identity may query every tenant namespace. A cache may return results after access has been revoked. A reranker may receive text that the caller was never entitled to read.
Document the control plane separately from the data plane. Administrators who create indexes, change filters or rotate credentials may have a different risk profile from applications that run similarity searches. Backup, analytics and observability systems also receive sensitive material and belong in the model.
Enforce authorization before retrieval
The safest pattern is to decide what the caller may access before candidate content reaches the model. Post-retrieval filtering is fragile because unauthorized text may already have entered logs, caches, ranking services or prompt construction.
Bind the request to an authenticated user, workload and tenant. Derive access filters from trusted server-side identity, not model output or user-controlled metadata. If namespaces represent tenants, verify that the application cannot choose an arbitrary namespace. If metadata filters represent document permissions, confirm that absent, malformed or unsupported filters fail closed.
Test authorization at every access path: normal semantic search, keyword fallback, hybrid search, autocomplete, recommendation, administration, export and debugging endpoints. A strong filter on the primary query path does not compensate for an unrestricted support endpoint.
The AI agent tenant-isolation guide expands this into a complete cross-tenant test strategy.
Separate tenants and sensitivity levels
Logical filters can work, but their correctness must be demonstrated under failure. Separate indexes or accounts reduce some blast radius at the cost of operational complexity. The right choice depends on sensitivity, scale and the consequences of an isolation failure.
Do not mix public knowledge, internal guidance, regulated records and security secrets without explicit policy. Retrieval ranking optimizes relevance, not confidentiality. A highly relevant secret can outrank a safe public document if both are searchable.
Use synthetic canary records for each tenant and sensitivity class. Query from other tenants using exact phrases, semantic paraphrases, partial identifiers and adversarial instructions. Test missing tenant context, duplicate tenant IDs, Unicode variants, malformed filters and service-to-service calls that lack an end-user identity.
Secure the ingestion pipeline
Ingestion determines what the system will later consider knowledge. Authenticate publishers and connectors. Preserve source ownership, timestamps, permissions and version history. Validate file types and extracted content, and quarantine new or materially changed sources when the downstream agent can take consequential action.
Inspect the text after parsing rather than assuming the visible document is the indexed document. PDFs, HTML, office files and images can carry hidden layers, metadata or OCR text. A benign-looking file can produce malicious chunks.
Limit each connector to the minimum sources required. Separate credentials by source and environment. Detect unusual bulk additions, sudden permission expansion and repeated documents designed to dominate search. The RAG poisoning guide covers these content attacks in depth.
Protect metadata and filters
Metadata often becomes an authorization mechanism even when it was designed for search. Fields such as tenant, owner, classification and allowed groups require stronger integrity than tags such as topic or language.
Define who can write each security-relevant field. Reject client-supplied ownership unless independently verified. Normalize identifiers and use allowlisted filter operators. Confirm that null, empty arrays and unknown fields cannot widen a query.
When documents are re-chunked or copied, propagate permissions correctly. A derived summary should not lose the classification of its sources. If a document has mixed permissions, split it at a boundary that preserves access rules rather than applying the broadest permission to every chunk.
Treat embeddings as sensitive derived data
Embeddings are not readable documents, but they are derived from sensitive content and should not be treated as anonymous by default. Their exposure may reveal relationships, membership or information about the underlying corpus. Risk varies with the model, attacker access and surrounding metadata.
Apply the same inventory, retention, encryption and access-governance discipline used for the source data. Do not place production embeddings in public buckets or broadly shared analytics systems. Restrict raw vector export and bulk nearest-neighbor probing.
Avoid absolute claims that encryption alone prevents disclosure. Encryption protects storage and transport; it does not stop an authorized-but-overprivileged application from retrieving the wrong content.
Defend against retrieval poisoning
An attacker may craft content to rank for sensitive questions, imitate an authoritative policy or inject instructions into the model context. Defenses need to span publisher trust, source provenance, ranking, prompt construction and tool authorization.
Mark trusted policy collections and do not let unreviewed uploads silently outrank them. Limit the influence of duplicate sources. Provide the model with source provenance, but remember that labels are context, not an enforcement boundary.
Most importantly, prevent retrieved text from granting itself authority. A document must not be able to select credentials, widen permissions or approve a tool action. The action layer should validate identity, parameters and consequence independently.
Control credentials and network paths
Use workload identities or short-lived credentials where supported. Avoid one static key shared by development, production and analytics. Scope identities to required indexes and operations; an application that only queries should not administer collections or export all vectors.
Restrict network reachability and authenticate every service connection. Private networking can reduce exposure, but it does not replace application authorization. Rotate credentials without breaking active workloads, and test revocation rather than assuming expiry behaves as expected.
Keep secrets out of prompts and retrieved metadata. The AI agent secrets-management guide explains how to prevent credentials from becoming model context.
Handle deletion and permission changes correctly
Deletion is a distributed workflow. Removing a source document may leave chunks, embeddings, caches, summaries, traces, backups and agent memory. Permission revocation can have the same problem: the current source is protected while a derived artifact remains available.
Maintain lineage from source to chunk and index entry. Define deletion objectives and verify them with unique canaries. Invalidate query caches and derived summaries. Backups need documented retention and access controls, not an unrealistic promise of instant erasure.
Test re-indexing and partial failure. If deletion succeeds in one region and fails in another, operators need a visible status and a safe retry path. Preserve audit evidence without retaining unnecessary content.
Log enough to investigate without leaking content
Security teams need to connect an answer to the identity, authorization decision, query, index, filter, retrieved chunk IDs, scores, reranking and final action. That evidence supports both incident response and regression testing.
Avoid placing complete sensitive documents in routine logs. Use stable identifiers, classifications and hashes where possible, with tightly controlled access to content required for investigation. Log access to bulk export and administrative changes separately.
Monitor cross-tenant canary hits, filter failures, large result sets, unusual query volume, ranking spikes, repeated content and retrieval followed by sensitive tool use. Detection should lead to investigation; similarity scores alone do not prove an attack.
Build a realistic vector database test plan
A useful assessment includes normal authorization tests and adversarial AI behavior:
- Query each tenant's synthetic canaries from every other tenant.
- Remove tenant context and test fail-closed behavior.
- Manipulate metadata, namespaces and filter operators.
- Exercise hybrid, fallback, export and debugging paths.
- Upload documents containing direct and indirect instructions.
- Attempt ranking manipulation with duplicates and keyword stuffing.
- Revoke source access and test caches and derived artifacts.
- Delete a canary and trace it through chunks, backups and memory.
- Rotate and revoke the application credential during active sessions.
- Attempt bulk enumeration through nearest-neighbor queries.
- Test privileged administration with a query-only identity.
- Correlate retrieved chunks with tool selection and downstream effects.
Run tests with synthetic records and mocked consequential tools. Define success criteria in advance: unauthorized content retrieved, exposed to the model, disclosed to the user, stored in memory, or used in an action. Those are different severity levels.
Evidence that a review should produce
A defensible finding includes the authenticated identity and tenant, exact index and filter, source and chunk IDs, model-visible context, response, subsequent tool calls and timestamped outcome. Record deployment, embedding and prompt versions so the result can be reproduced.
Screenshots alone rarely establish the boundary failure. Preserve structured traces and the authorization decision. Redact customer data in reports and use synthetic canaries whenever possible.
After remediation, replay the original request and meaningful variants. Verify that the fix did not merely suppress one phrase while leaving the access path open. Keep the test as a regression when it represents an important boundary.
Procurement questions for vector database deployments
Ask vendors and platform owners how tenant filters are enforced, how namespaces are authorized, which identities can export data, and how permission changes propagate. Request details about encryption, backup access, regional replication, deletion and audit logs.
For managed services, clarify the shared-responsibility boundary. A provider may secure infrastructure while the customer remains responsible for index design, metadata integrity and application authorization. For self-hosted systems, ask who patches the service and monitors exposed endpoints.
Do not accept “enterprise ready” as evidence. Request a demonstration using your identity model and a negative cross-tenant test.
Vector database security checklist
- Map sources, connectors, parsers, indexes, rerankers and caches.
- Bind every query to authenticated user, workload and tenant context.
- Enforce access before unauthorized content reaches the model.
- Protect security-relevant metadata from untrusted writes.
- Separate tenants or sensitivity classes according to consequence.
- Authenticate publishers and preserve source provenance.
- Restrict query, administration and export permissions independently.
- Encrypt and govern embeddings as sensitive derived data.
- Detect poisoning, duplication and unusual ranking changes.
- Maintain lineage for deletion and permission revocation.
- Correlate retrieval with model output and downstream actions.
- Retest boundaries with synthetic canaries after every meaningful change.
Frequently asked questions
Is a vector database less secure than a relational database?
Not inherently. The risk comes from deployment choices and from using retrieval to construct model context. Similarity search, metadata filtering and agent actions create failure modes that a conventional database review may not exercise.
Should every tenant have a separate index?
Separate indexes can reduce blast radius but add operational cost. Strong logical isolation may be appropriate when it is correctly enforced and thoroughly tested. Base the decision on consequence and evidence, not convention.
Can a model enforce document permissions?
No. Authorization belongs in trusted application and data services. The model can help explain a denial, but it should not decide whether the caller may retrieve a protected record.
Are embeddings personal or regulated data?
That depends on the source, jurisdiction and use. Treat embeddings as sensitive derived data until privacy, legal and security owners establish a justified classification.
How often should retrieval security be retested?
Retest after changes to connectors, permissions, chunking, embedding models, indexes, filters, prompts, tools or caching. High-impact systems also need periodic regression because source content and access relationships change continuously.
Vector database security is ultimately RAG system security. Strong infrastructure controls matter, but the decisive test is whether identity, data and action boundaries hold through the complete retrieval path. Continue with RAG data-leakage testing, RAG poisoning security and indirect prompt-injection testing.