Guides › Secure RAG › Vector database security

Vector Database Security

Hunter Moore, Founder and CTO · Updated August 4, 2026

Securing a vector database means controlling who can query it, what each query is allowed to return, how tenants are separated, and what the stored vectors themselves reveal. Encryption at rest addresses none of those. It protects against someone stealing the disk, which is not how vector stores leak.

At a glance
  • Encryption is not the control. Leakage happens through authorized queries against an index that is already decrypted.
  • Four things need securing. Direct access to the index, query-scoped authorization, tenant isolation, and what the vectors themselves disclose.
  • Embeddings are not one-way. They can be inverted back to source text, so a vector export behaves like a text export.

Why is encryption not the answer?

Because leakage happens through authorized queries against a decrypted index. The data is decrypted precisely when it is being used, which is when it gets returned to the wrong person. Encryption never engages in that path.

Encrypt anyway. It covers backup theft, disk disposal and a class of compliance questions you do not want to argue about. Just do not record it as the control that addresses retrieval exposure, because it is not related to it.

ENCRYPTION AT REST, SCOPED HONESTLY Covered Not covered the data is at rest and the key is elsewhere the data is decrypted and in use A stolen disk or volume snapshot physical and infrastructure compromise A backup file leaving the estate exports, replicas, disaster recovery copies A misconfigured storage bucket the object is unreadable without the key A query from a caller with no entitlement check the store decrypts and returns, as designed An over-broad service credential one credential, the whole index Embedding inversion the vector reconstructs much of the text Copies held outside the store caches, chat history, evaluation sets Encryption answers who holds the bytes. Retrieval leakage is a question about who gets the answer. Both matter. Only one of them is closed by a checkbox in the console.
Encryption at rest is necessary and answers a narrow question. Every route by which retrieval returns content to the wrong person runs through decrypted data.

What actually needs securing?

Four things. Who can reach the database at all. What any given query is permitted to return. Whether tenants are genuinely isolated. And what the embeddings themselves disclose if someone obtains them.

Direct access to the index

Vector stores are frequently deployed with weaker controls than the systems whose content they now hold. A database that started as a prototype often keeps its prototype network posture and its shared credential long after it became the retrieval backbone for an internal assistant.

What to do

Treat the index as a production data store holding a copy of your most-requested content, because that is what it is. Authentication per service, no shared keys, network reachable only from the retrieval service, and audit logging on queries.

Query-scoped authorization

The application, not the database, usually decides what a user may see, and the database will faithfully return whatever the application asks for. If the retrieval service holds one credential with full read scope and applies filtering afterward, a bug in the application is a full index disclosure.

Metadata filtering applied before similarity search is the control that matters here. The mechanics are in RAG permissions.

Multi-tenant isolation

The 2025 OWASP Top 10 for LLM Applications lists LLM08, Vector and Embedding Weaknesses, and calls out multi-tenant context leakage specifically. How you implement separation decides whether a failure is loud or silent.

Namespace or collection separation

separation is structural

  • Each tenant is queried through its own namespace or collection.
  • A wiring mistake surfaces as a visible error rather than a silent read.
  • Correctness does not depend on a field being set on every write.

A shared collection with a tenant attribute

separation depends on every write being correct

  • One missing metadata field puts one tenant's content in another tenant's results.
  • The failure is silent. The query succeeds and returns.
  • Separation is one write path away from failing at any time.

What the vectors themselves reveal

An embedding is not a one-way hash. Morris, Kuleshov, Shmatikov and Rush demonstrated in Text Embeddings Reveal (Almost) As Much As Text at EMNLP 2023 that embeddings can be inverted back to source text, recovering 92 percent of 32-token inputs exactly and reconstructing full names from a clinical notes dataset.

92%of 32-token inputs recovered exactly from their embeddings
LLM08OWASP's 2025 entry for vector and embedding weaknesses

The practical consequence is that a vector export is closer to a text export than most governance frameworks assume. Covered further under embedding inversion.

What about the copies nobody governs?

Vector databases are rarely the only copy. Caches, conversation history, agent memory, evaluation datasets and debug logs all inherit content from the index and almost never inherit its permissions. OWASP moved Sensitive Information Disclosure up to LLM02 in the 2025 list.

Inventory the derived copies before hardening the primary store. Securing the database while an evaluation set of retrieved chunks sits in a shared bucket is not a meaningful improvement.

ONE RESTRICTED DOCUMENT, SIX COPIES OF ITS CONTENT Source document restricted to four people reviewed quarterly a deletion request names this CREATED BY INDEXING CREATED BY USE Chunks the text, split up content: inherited permissions: no Embeddings invertible, see below content: inherited permissions: no Retrieval cache recent answers, verbatim content: inherited permissions: no Conversation history stored per user, often forever content: inherited permissions: no Evaluation sets copied into a test fixture content: inherited permissions: no Backups and snapshots outlive every policy content: inherited permissions: no A deletion request names the document on the left. It does not, on its own, reach the six on the right. That is the practical test of whether a vector store is governed: delete one document and count how many copies survive.
Indexing a document creates copies of its content in places that were never designed to carry its restrictions. Governance has to follow the content, not the original file.

Where does the durable fix sit?

Upstream. Every control above governs a copy; content decisions made at ingestion govern the original, and every copy inherits them. Transformation before embedding means the chunk, the vector, the cache entry and the summary all carry the same reduced exposure without five separate policies.

That is the layer Hardshell works on, inside the customer's environment and upstream of the index.

Transformation upstream does not replace database access control. It changes what an access control failure costs.

Frequently asked questions

Is a managed vector database more secure than self-hosted?

On infrastructure hardening, usually yes. On retrieval leakage, it makes no difference, because that failure happens inside an authorized query either way. Choose on operational grounds and treat the entitlement question as yours regardless of hosting.

Should we encrypt embeddings themselves?

You cannot meaningfully, and still search them. Similarity search requires comparable vectors. Approaches that operate on encrypted vectors exist in research but are not practical at production latency. Reduce what the vectors encode instead.

Does deleting a document remove it from the index?

Only if your pipeline propagates deletions, and many do not. Deletion in the source system frequently leaves orphaned chunks that remain retrievable. Test this explicitly, because it is a common and awkward finding during a data subject request.

What should we log?

Which chunks were returned, for which query, to which identity, at what time. That record is the prerequisite for auditing, for investigating an incident, and for running a leakage self-test. Without it you cannot answer what a given user was shown last week.

Sources

Morris, Kuleshov, Shmatikov and Rush, Text Embeddings Reveal (Almost) As Much As Text, EMNLP 2023. · OWASP, Top 10 for LLM Applications, 2025.